3 ms·

the self argument for methods/method calls is stressful (having to define self for methods and having to call a method via self); also the fact that you need to

the self argument for methods/method calls is stressful (having to define self for methods and having to call a method via self); also the fact that you need to check if dictionary key exists, else you get an exception when trying to get the keys value. Also ':' at the end of each line. I always forget at least one of these. You didn't have any of these goodies in good old perl (sob, sob) (wow, this one got flagged pretty quickly, wonder why)

dagw 8y ago
you need to check if dictionary key exists, else you get an exception when trying to get the keys value. What should be the correct behavior when accessing a key that doesn't exists? If you want a specific default value when a key doesn't exist you can use the get() method. Also ':' at the end of each line. What do you mean? You don't need ':' at the end of each line, only at the start of a block (basically anywhere you'd use a '{' in other languages).
- blattimwind 8y ago
  > What should be the correct behavior when accessing a key that doesn't exists? Undefined behaviour, i.e. the JIT generates code to 3D print a clay golem on your desktop that sets your village ablaze.
gwillz 8y ago
Idk, maybe because your arguments are bit shallow? I like 'self'. There's a lot to complain about magical 'this' of every other language - especially in Javascript. Specifying self makes it really clear if it's a member method or a standalone function. Python really likes the idea of 'seek forgiveness, not permission', aka. abusing try/except. But it's kind of nice: # seek permission if 'key' in map: fn(map['key']) else: whatever() # seek forgiveness try: fn(map['key']) except KeyError: whatever() Just pray that 'fn()' doesn't also throw a KeyError.
Felz 8y ago
It's been a while since I touched Python (thankfully), but there's also: - The hideous __method__ and _private conventions - A friend of mine was complaining about the implicit string concatenation: ["foo" "bar", "baz"] whoops forgot a comma and now there's a very hard to find bug - pyc and pyo files littering the filesystem after running (yes, only a minor nuisance) - import anywhere, the ugly __name__ = "main" hack - GIL, reference counting GC, abysmal performance in general - Dynamic typing, which is probably my most major complaint but I realize opinions differ
- teddyh 8y ago
  > implicit string concatenation C and many other languages had that before Python, and it’s very useful to be able to split a single string over many lines in your source code. Python very wisely also implemented this feature. > - pyc and pyo files littering the filesystem after running Fixed in Python 3.
jbarberu 8y ago
"also the fact that you need to check if dictionary key exists, else you get an exception when trying to get the keys value." dictionary.get(...) is specifically for avoiding the exception, you should just get None if the key doesn't exist. Unless I'm misunderstanding you and your complaint lies elsewhere. Don't get me wrong, there are plenty of things that are stupid/annoying with python, this comment however reads more like "python is bad because I can't write perl in it". I think that's why people are flagging it.
KMag 8y ago
Seeing your invitation for critique.. I didn't downvote you, but you present complaints without support or putting forward alternatives other than everyone should ditch Python in favor of Perl. 2 of your 3 complaints come across as shallow syntactic bikeshedding presented without support. It would be interesting to read your take on the engineering problems involved, the design tradeoffs involved, and why you think Perl's decisions are more appropriate than Python's decisions, even for Python's main use cases. Python rubbed me the wrong way when I first encountered it, then I really loved it for a few years. Now, I feel it's pretty good at what it does, but I find other languages more interesting. Maybe you have some good reasoning behind your gripes, but you don't provide any evidence that you've thought much about them or put any effort into understanding the design decisions. For your first complaint, I do agree that the explicit self parameter vs just making it a keyword is hard to justify in retrospect, but is it really raising your blood pressure, causing you to lose sleep, etc? Your use of hyperbole doesn't help your case. I presume that making all method calls explicit is to keep scoping sane in the case where a subclass defines a method that happens to accidentally conflict with the name of a function called in some superclass's method. An alternative would be to use static name resolution to resolve the ambiguity, but then you'd have to be statically invoking metaclasses to figure out which methods were in scope, or you'd have to get rid of metaclasses and generally get rid of a bunch of the effort Python goes through to be very late-binding and generally dynamic in behavior. For your second complaint, if you don't want the dict to throw, use the get method instead of the brackets operator. For your third complaint, I'm not sure exactly what you're complaining about. Clearly not every line literally ends with a colon, and you're again making poor use of hyperbole. Guido has commented in at least one interview that most of the colon's aren't necessary to disambiguate the grammar, but they really do help beginners in particular read the code. Showing more effort toward educating and/or convincing people would help avoid the downvotes.
- MichaelMoser123 8y ago
  > It would be interesting to read your take on the engineering problems involved, the design tradeoffs self - the reason is that I forget to type it and causes me to go back and fix the method signature or method call (there are usually lots of them in the code, so lots of opportunities to forget self - hence lots of instances where it can be omitted so that it must be fixed, at least for me; the remark is a gripe about ergonomics of syntax) The alternative: do a different keyword for method definitions other than def; (well, still you need something to differentiate between method invocation and global function call in an untyped language) : at the end of function definition or a block - same thing. KeyError if dict entry not found; most other languages I know would return None, so that's counter intuitive to me (I know about get, but [ ] is the default syntax for accessing dictionaries in most languages) I know it will cause an undefined method call to bomb, which is a good thing in my book; but I don't like it for data structure access - I also don't like exception handling in particular and prefer explicit checking of results (again matter of taste and habit + frequent cause to go back and fix it) I think python is making several tradeoffs in favor of making the resulting script more robust (like going for exception handling) but it makes the experience of writing said script a bit more tricky.
peterwwillis 8y ago
You don't have to define 'self' in Perl code, but you should. You don't have to check if a key in a dict exists, but you should. Not doing these things, and the crappy code that results, are part of why people make fun of Perl. $ cat > foo.pl <<EOF use strict; use warnings; { package Foo; sub new { my $class = shift; bless {}, $class } sub method { my $self = shift; $self->{"hash"} = { "thng1" => shift }; my $key = $self->{"hash"}->{"thing1"}; $self->increment($key); } sub increment { $_[1] + 1 } } my $count = Foo->new()->method(33); print "count: $count\n"; EOF $ perl foo.pl && echo "Program succeeded" Use of uninitialized value $_[1] in addition (+) at foo.pl line 12. count: 1 Program succeeded The debugger is telling us about an uninitialized variable in Foo::increment(), but the bug is really a missing dict key in Foo::method() due to a typo. We never checked if it existed, Perl didn't care either way, and the program didn't even fail. In code that's more than a page long, good luck spotting that...

dagw 8y ago

you need to check if dictionary key exists, else you get an exception when trying to get the keys value. What should be the correct behavior when accessing a key that doesn't exists? If you want a specific default value when a key doesn't exist you can use the get() method. Also ':' at the end of each line. What do you mean? You don't need ':' at the end of each line, only at the start of a block (basically anywhere you'd use a '{' in other languages).

blattimwind 8y ago
> What should be the correct behavior when accessing a key that doesn't exists? Undefined behaviour, i.e. the JIT generates code to 3D print a clay golem on your desktop that sets your village ablaze.

gwillz 8y ago

Idk, maybe because your arguments are bit shallow? I like 'self'. There's a lot to complain about magical 'this' of every other language - especially in Javascript. Specifying self makes it really clear if it's a member method or a standalone function. Python really likes the idea of 'seek forgiveness, not permission', aka. abusing try/except. But it's kind of nice: # seek permission if 'key' in map: fn(map['key']) else: whatever() # seek forgiveness try: fn(map['key']) except KeyError: whatever() Just pray that 'fn()' doesn't also throw a KeyError.

Felz 8y ago

It's been a while since I touched Python (thankfully), but there's also: - The hideous __method__ and _private conventions - A friend of mine was complaining about the implicit string concatenation: ["foo" "bar", "baz"] whoops forgot a comma and now there's a very hard to find bug - pyc and pyo files littering the filesystem after running (yes, only a minor nuisance) - import anywhere, the ugly __name__ = "main" hack - GIL, reference counting GC, abysmal performance in general - Dynamic typing, which is probably my most major complaint but I realize opinions differ

teddyh 8y ago
> implicit string concatenation C and many other languages had that before Python, and it’s very useful to be able to split a single string over many lines in your source code. Python very wisely also implemented this feature. > - pyc and pyo files littering the filesystem after running Fixed in Python 3.

jbarberu 8y ago

"also the fact that you need to check if dictionary key exists, else you get an exception when trying to get the keys value." dictionary.get(...) is specifically for avoiding the exception, you should just get None if the key doesn't exist. Unless I'm misunderstanding you and your complaint lies elsewhere. Don't get me wrong, there are plenty of things that are stupid/annoying with python, this comment however reads more like "python is bad because I can't write perl in it". I think that's why people are flagging it.

KMag 8y ago

Seeing your invitation for critique.. I didn't downvote you, but you present complaints without support or putting forward alternatives other than everyone should ditch Python in favor of Perl. 2 of your 3 complaints come across as shallow syntactic bikeshedding presented without support. It would be interesting to read your take on the engineering problems involved, the design tradeoffs involved, and why you think Perl's decisions are more appropriate than Python's decisions, even for Python's main use cases. Python rubbed me the wrong way when I first encountered it, then I really loved it for a few years. Now, I feel it's pretty good at what it does, but I find other languages more interesting. Maybe you have some good reasoning behind your gripes, but you don't provide any evidence that you've thought much about them or put any effort into understanding the design decisions. For your first complaint, I do agree that the explicit self parameter vs just making it a keyword is hard to justify in retrospect, but is it really raising your blood pressure, causing you to lose sleep, etc? Your use of hyperbole doesn't help your case. I presume that making all method calls explicit is to keep scoping sane in the case where a subclass defines a method that happens to accidentally conflict with the name of a function called in some superclass's method. An alternative would be to use static name resolution to resolve the ambiguity, but then you'd have to be statically invoking metaclasses to figure out which methods were in scope, or you'd have to get rid of metaclasses and generally get rid of a bunch of the effort Python goes through to be very late-binding and generally dynamic in behavior. For your second complaint, if you don't want the dict to throw, use the get method instead of the brackets operator. For your third complaint, I'm not sure exactly what you're complaining about. Clearly not every line literally ends with a colon, and you're again making poor use of hyperbole. Guido has commented in at least one interview that most of the colon's aren't necessary to disambiguate the grammar, but they really do help beginners in particular read the code. Showing more effort toward educating and/or convincing people would help avoid the downvotes.

MichaelMoser123 8y ago
> It would be interesting to read your take on the engineering problems involved, the design tradeoffs self - the reason is that I forget to type it and causes me to go back and fix the method signature or method call (there are usually lots of them in the code, so lots of opportunities to forget self - hence lots of instances where it can be omitted so that it must be fixed, at least for me; the remark is a gripe about ergonomics of syntax) The alternative: do a different keyword for method definitions other than def; (well, still you need something to differentiate between method invocation and global function call in an untyped language) : at the end of function definition or a block - same thing. KeyError if dict entry not found; most other languages I know would return None, so that's counter intuitive to me (I know about get, but [ ] is the default syntax for accessing dictionaries in most languages) I know it will cause an undefined method call to bomb, which is a good thing in my book; but I don't like it for data structure access - I also don't like exception handling in particular and prefer explicit checking of results (again matter of taste and habit + frequent cause to go back and fix it) I think python is making several tradeoffs in favor of making the resulting script more robust (like going for exception handling) but it makes the experience of writing said script a bit more tricky.

peterwwillis 8y ago

You don't have to define 'self' in Perl code, but you should. You don't have to check if a key in a dict exists, but you should. Not doing these things, and the crappy code that results, are part of why people make fun of Perl. $ cat > foo.pl <<EOF use strict; use warnings; { package Foo; sub new { my $class = shift; bless {}, $class } sub method { my $self = shift; $self->{"hash"} = { "thng1" => shift }; my $key = $self->{"hash"}->{"thing1"}; $self->increment($key); } sub increment { $_[1] + 1 } } my $count = Foo->new()->method(33); print "count: $count\n"; EOF $ perl foo.pl && echo "Program succeeded" Use of uninitialized value $_[1] in addition (+) at foo.pl line 12. count: 1 Program succeeded The debugger is telling us about an uninitialized variable in Foo::increment(), but the bug is really a missing dict key in Foo::method() due to a typo. We never checked if it existed, Perl didn't care either way, and the program didn't even fail. In code that's more than a page long, good luck spotting that...