Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WTF Python: Exploring and understanding Python through surprising snippets

github.com

Post reply on HN
Print view View original

41–50 of 169 posts

Re: WTF Python: Exploring and understanding Python through surprising snippets

#41

Post by pansa2 »

kzrdude wrote: post #27
pansa2 wrote: post #14

>>> another_tuple ([1, 2], [3, 4], [5, 6, 1000]) >>> another_tuple[2] += [99, 999] TypeError: 'tuple' object does not support item assignment >>> another_tuple ([1, 2], [3, 4], [5, 6, 1000, 99, 999]) This one's my favorite. Although it's a rare issue that you're unlikely to come across, it's a side-effect of a much bigger design flaw in Python - the decision to make `a += b` behave differently from `a = a + b`.

That's a wart and a half. It puzzles me to no end that this would be an error - `another_tuple[0].append(3)` is not an error.

It’s because `another_tuple[2] += [99, 999]` is equivalent to something similar to `another_tuple[2] = another_tuple[2].__iadd__([99, 999])`. The list is modified in __iadd__ but then the assignment fails.

The assignment is necessary in case __iadd__ doesn’t want to modify in-place and instead return a new value. It’s this “sometimes modify in-place, sometimes don’t” which causes the issue.

Re: WTF Python: Exploring and understanding Python through surprising snippets

#43

Post by [deleted] »

Doxin wrote: post #12

I feel like WTFs caused by doing something deeply weird hardly counts against the language. Yes doing the walrus operator inside brackets works. Yes of course it's going to be doing weird things. Is this really surprising to anyone? It's not what that operator is for . Yes comparing strings with "is" works sometimes . It's not checking equality and it isn't supposed to. In another implementation using "is" might work…

[deleted]

Re: WTF Python: Exploring and understanding Python through surprising snippets

#44

Post by pansa2 »

yongjik wrote: post #35
maweki wrote: post #20

Earlier quoted context omitted.

It's a design decision to allow it to behave differently, as you can implement += with a more efficient in-place version, instead of a copying one where the lvalue might be different/new and you have to keep the old a. I even think this is good design, as by convention + does not mutate its arguments but += can be a fast mutating version.

I'd say it's even deeper - the += operator is fundamentally tied with Python's semantics. Consider: >>> a = [1, 2] >>> b = a >>> a = a + [3] >>> b [1, 2] It has to be [1, 2] because the third line creates a new object. If a + operation changes its operand, then the concept of object identity breaks down - at least, it will be a very different language.

You’re right - I’m not suggesting that `+` should work in-place, but that `a += b` should do the same thing as `a = a + b` and not work in-place.

Re: WTF Python: Exploring and understanding Python through surprising snippets

#45

Post by tarsinge »

Doxin wrote: post #12

I feel like WTFs caused by doing something deeply weird hardly counts against the language. Yes doing the walrus operator inside brackets works. Yes of course it's going to be doing weird things. Is this really surprising to anyone? It's not what that operator is for . Yes comparing strings with "is" works sometimes . It's not checking equality and it isn't supposed to. In another implementation using "is" might work…

> I've been seeing a growing anti-python sentiment lately

Not speaking for the quality of the article, but on that sentiment: maybe it's just that the pro-python sentiment is eroding. I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable (at its core, not the 2 -> 3 migration). At least that's my sentiment as someone who really doesn't like it (but I'm a professional, I still use it when it's a best tool for the job, it's just a pain). I'm sure just saying that is still suspicious, and saying that I prefer JS (modern) to Python will still get me more than raised eyebrows for at least a few more years.

Re: WTF Python: Exploring and understanding Python through surprising snippets

#46

Post by fire7000 »

TeMPOraL wrote: post #38
tgbugs wrote: post #28

While this repo is great for education, it doesn't cover the deep problems with Python that you only discover when you try to do something "unapproved" or slightly off the happy path. Depending on the domain you are working in you may never encounter such a situation, but if you do, be prepared to lose your sanity one omnipresent design flaw at a time. Over the years I've been collecting a series of cases that are so…

That's the flip side of "There should be one— and preferably only one —obvious way to do it." Engineering is the art of trade-offs. Same problem with different requirements needs a different solution.

There is, its called C /s

Re: WTF Python: Exploring and understanding Python through surprising snippets

#47

Post by tgbugs »

einpoklum wrote: post #32
tgbugs wrote: post #28

While this repo is great for education, it doesn't cover the deep problems with Python that you only discover when you try to do something "unapproved" or slightly off the happy path. Depending on the domain you are working in you may never encounter such a situation, but if you do, be prepared to lose your sanity one omnipresent design flaw at a time. Over the years I've been collecting a series of cases that are so…

I think you forgot the link to your collection?

There are some that you can find in [0], but they are often de-contextualized (and sometimes aren't really Python's problem, because there was a trade off that had to be made, and the LOL is just frustration as a result of the bad ergonomics that it creates), those and some others will eventually go in an longer post when I finally get that set up.

To give one concrete example of an LOL PYTHON consider the @property decorator. While it seems like a really cool and handy idea that could let you save some typing in some cases, it is actually a trap that you should almost never use because when you inevitably discover that there is some parametrization that you need to pass to the ... attribute, you are suddenly faced with a massive refactoring. Also if you ever make the mistake of having boolean properties such as isDir or isUrl and somewhere else you have a predicate that is a function instead of a property then isFile will always return True when you meant isFile(). The only safe solution is to never use properties/attributes as predicates. These are nasty footguns that seem obscure and unlikely to affect you until you have the misfortune to already be in the briar patch.

0. https://github.com/search?q=%22LOL+PYTHON%22+user%3Atgbugs&t...

Re: WTF Python: Exploring and understanding Python through surprising snippets

#48

Post by watt »

PartiallyTyped wrote: post #33
serial_dev wrote: post #17

Earlier quoted context omitted.

I agree with most of your points, because in most cases, people try something very weird, and they are surprised that the result is something even weirder (or they just didn't think through the example logically). Except the string comparison with "is". It's confusing, because there are no errors, and when I try them in the Python REPL, it "works". The code is logical, I tested the example and it works... ...except w…

In python, strings are mostly unique, meaning that a string can be bound on many variables, and all the variables point to the same string. This is where the 'is' operator comes in, 'is' checks for reference equality, that is, the object that is bound onto the two variables is the same. If they are not the same, 'is' fails. In other words: x = "foo" y = "foo" x == y and x is y Both strings point to the same exact mem…

Checking for reference equality (comparing pointers) is such a niche requirement it should be hidden behind stronger syntactic vinegar. The greatest mistake Java made maybe is having == for testing pointers, and .equals() function for actually comparing.

Every JVM language that came after Java reverses this. Here, "is" simply is too nice. Should've named it something nobody will accidentally use.

Re: WTF Python: Exploring and understanding Python through surprising snippets

#50

Post by pansa2 »

j0057 wrote: post #31

Python should just remove the `is` operator. If you really need to compare object identities, which is already a rare scenario to begin with, you can explicitly compare the object IDs. Checking if something is or is not True/False/None can just be treating the thing as True-ish or False-ish. Making the language bigger is not nearly as impressive as making it smaller!

Yeah, IME `is None` is by far the most common use of `is`. I don’t think many people would miss `is` if it were removed and an `is_none` function introduced.
Post reply on HN