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)
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.
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()
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).
Undefined behaviour, i.e. the JIT generates code to 3D print a clay golem on your desktop that sets your village ablaze.
- 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
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.
$ 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
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.
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.