Live data from Hacker News

WTF Python: Exploring and understanding Python through surprising snippets

github.com

51–60 of 169 posts

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

#51
post #39
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…

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.

And it'd be unfair to that new language too. Basically all of the WTFs in the OP are things you don't run into, unless you're writing deeply deeply weird code, at which point it's hardly the languages fault that it does weird things.

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

#52
post #37
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!

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.

I agree about explicit None checks. It is often useful to distinguish None from the zero value of a type such as a numeric zero, empty string or empty collection. I also write "is None" & "is not None" everywhere when doing these explicit checks.

Yet the same be benefits of explicit None checks can be attained by writing "== None" i.e. doing value based comparisons against a None value. So this argument does not explain why "is" is necessary.

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

#53
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.

True, but the problem is that in pursuit of that mantra the language has wound up disempowering engineers and has forced even more decisions about trade-offs onto them: do you want readability, performance, or maintainability? You usually can't have all of them because of some lurking performance tar pit.

An example here is the conflict between needing top level imports for sanity and static analysis (there was an instagram blog on this a while ago) while also wanting fast startup time. If you import requests at the top level then you cannot have fast startup time, so you wind up importing it outside the top level so that code paths that don't use requests don't have to pay the time cost of loading it, but then you have imports that aren't at the top level!

edit: oh, and don't even get me started on pkg_resources [0], which isn't just a tarpit, it is a full blown blackhole beartrap waiting for the unsuspecting.

0. https://github.com/pypa/setuptools/issues/510

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

#54
post #52
post #37

Earlier quoted context omitted.

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.

I agree about explicit None checks. It is often useful to distinguish None from the zero value of a type such as a numeric zero, empty string or empty collection. I also write "is None" & "is not None" everywhere when doing these explicit checks. Yet the same be benefits of explicit None checks can be attained by writing "== None" i.e. doing value based comparisons against a None value. So this argument does not expl…

I think the reason not to write `== None` is that classes can override `==`:

    class C:
        def __eq__(self, other): return True
    C() == None  # True
    C() is None  # False

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

#55
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!

> Checking if something is or is not True/False/None can just be treating the thing as True-ish or False-ish.

No, it can't. Especially obviously not something whose type is Optional[bool]. Or, more subtly, Optional[Number] or Optional[Sequence[T]].

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

#56
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 sti…

> JS (modern)

LOL. JS is what, 25 years old, versus Python at 30.

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

#57
post #52
post #37

Earlier quoted context omitted.

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.

I agree about explicit None checks. It is often useful to distinguish None from the zero value of a type such as a numeric zero, empty string or empty collection. I also write "is None" & "is not None" everywhere when doing these explicit checks. Yet the same be benefits of explicit None checks can be attained by writing "== None" i.e. doing value based comparisons against a None value. So this argument does not expl…

> Yet the same be benefits of explicit None checks can be attained by writing "== None"

If you are going to do that's you should probably do a backwards comparison (`None==x`), otherwise you are calling x.__eq__(None), which probably won't be surprising in result if you have constrained things with sane typing, but still could be more expensive than `x is None`.

`x is None` reads a lot better though.

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

#58
The Python/NumPy gotcha that has caused me the most pain by far is

  def foo(x, y):
       return x+y
where the intention is for x and y to be NumPy arrays, but the caller accidentally passes lists (or vice versa). This is especially common because a lot of NumPy functions are agnostic as to whether they operate on arrays or other iterables.

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

#59
To be frank I think the python community lacks self-awareness.

There's this ritual you have to do when learning python: blindly accept status-quo design choices as "universally good" (but call it "pythonic"), and crap on other languages. Never admit python or the ecosystem has issues or shortcomings, and if another language has something better than yours (eg, Yarn, or Composer is way better than anything in Python (poetry is a good step but not a competitor)), or offer really good IoC tools: just double-down on the status-quo and say something like "looks over engineered, I see no reason why I would need that".

Pythonic is putting a decorator everywhere, coupling the system together into a ball of mud where you can't decouple it. Pythonic is having annoying mixed naming conventions. Why do I need methods to have underscores in 2021, but classes to use camel case? Why do my lines of code need to fit on a punched card invented decades before the language was invented? Why does the idiomatic "one true way" need to be what some other engineer thinks is "the one true" way?

Python is a fractal of closed-mindedness and single-use code. There's a reason it took a decade to get projects onto python 3, but PHP can swiftly move the entire ecosystem from v5 to v7 in a year. FastAPI is getting a lot of praise recently, but frameworks of this style are a dime-a-dozen in other languages and have been around for a decade.

Pythonic is a meaningless word that just gives firepower to the most confident-sounding engineer in a company to shoot down anyone who doesn't code like them. It's not an objective concept, it's innovation poison.

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

#60

Earlier quoted context omitted.

> 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 sti…

> JS (modern) LOL. JS is what, 25 years old, versus Python at 30.

I think the reference is to modern JS as in ES6 or TypeScript
Post reply on HN