I’m not a Python fan and these examples reinforce my dislike for its design.<p>1. Caused by confusing reference semantics and value semantics, which is pretty much inevitable when a fundamental data type is mutable.<p>2. Boolean is a subclass of Integer, because... why?<p>3. Same problem as #1.<p>4. Once again, beginners have no understanding of reference vs. value semantics, and why should they?<p>5. Default arguments of a function are evaluated just once, because... why? This one just seems crazy to me. It turns default arguments into stateful globals, so an innocent-looking function suddenly exhibits unpredictable behavior.
Allow me to play devil's advocate for a bit:<p>1. I don't really think this is that confusing. It's just passing by reference, which is something you can't get around learning if you're using a language that works that way.<p>2. I don't really see why True == 1 should hold either, but I think this example is really contrived; you wouldn't make a dictionary with both integer and boolean keys.<p>3. These are just destructive methods. You could get around this particular example by making these methods return the object itself, but then the user would just continue to operate under the misunderstanding that these methods are non-destructive, which would come back to bite them later.<p>4. This is an implementation detail leaking, but I can't think of a scenario where this shows up in the real world. To begin with, I rarely use "is" anyways.<p>5. This one is indeed just very confusing and I can't really defend it. This is the only one that I think has a real chance of being a problem in the real world. I know I've been bitten by this one before.<p>I think most of these just boil down to "mutability is confusing". Sure, but that's not really something you can fix unless you want to do away with mutability altogether, and then you have to eat the performance cost.
This python program is amazing:<p>exec(''.join(chr(int(''.join(str(ord(i)-8203)for i in c),2))for c in ' '.split(' ')))