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!
WTF Python: Exploring and understanding Python through surprising snippets
31–40 of 169 posts
Re: WTF Python: Exploring and understanding Python through surprising snippets
#32While 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?
Re: WTF Python: Exploring and understanding Python through surprising snippets
#33I 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 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
x = "foo"
y = f"{x} "[:-1] # get everything but the space
x == y # True
y is x # FalseRe: WTF Python: Exploring and understanding Python through surprising snippets
#34Earlier 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 guess reference counting makes copying a list in Python a much more expensive operation than it would be in other languages. Although perhaps it could also be used to avoid copying in cases where the list's own reference count is exactly 1? Anyway, there's nothing wrong with offering an operator to change a list in-place, but IMO `+=` is the wrong way to spell it.
> but IMO `+=` is the wrong way to spell it.
Again, operator overloading. __iadd__ just calls append. Many a library might do something much better. But as it looks like the in-place version of +, even for lists it seems fine (although I've been missing a concat-operator in python for years - seems we're stuck with +).
Re: WTF Python: Exploring and understanding Python through surprising snippets
#35>>> 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`.
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]
Re: WTF Python: Exploring and understanding Python through surprising snippets
#36While 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 would be so keen to read this if you ever document them somewhere!
Re: WTF Python: Exploring and understanding Python through surprising snippets
#37Python 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!
I find checking for "is None" very useful, but that is also the only time I use 'is'. I try to avoid checking for True-ish and False-ish whenever possible, preferring to be more explicit.
Re: WTF Python: Exploring and understanding Python through surprising snippets
#38While 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.
Re: WTF Python: Exploring and understanding Python through surprising snippets
#39I 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…
Can you imagine same "yes - ..." comments made about some new, straight out of the oven language? Most people would not touch it with a ten foot pole.
Re: WTF Python: Exploring and understanding Python through surprising snippets
#40Ah yes, the one about mutable default arguments was a real surprise for me once in a debugging session. Python only initialising them once during the whole script runtime is not exactly the behaviour anyone would expect.
I wasted recently plenty of time debugging that one - and I ended it by removing default arguments.
And I was sure that it was cause by a bug in my code, thanks for pointing this out - now I know what caused this
https://github.com/satwikkansal/wtfpython#-beware-of-default...