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

81–90 of 169 posts

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

#81

Post by edflsafoiewq »

singularity2001 wrote: post #69
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…

>> none of the code on this page is something anyone would actually write in production code on purpose. I mostly agree, but there is one example where I thought it is important to know and remember: for x in range(7): def some_func(): return x Here x binds to the (outside) symbol x, not the value of x at creation time of the inner function.

That's how I expect it to behave. But anyway, the alternative (x in a new lexical environment each time the loop body is entered) only makes sense in a language where variables are scoped to a lexical block, not in Python where variables are scoped to the whole function.

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

#82

Post by [deleted] »

watt wrote: post #48
PartiallyTyped wrote: post #33

Earlier quoted context omitted.

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.

[deleted]

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

#83

Post by matsemann »

Tips on learning python as a seasoned dev?

I will start a new job where everything is done in Python in a few weeks. Learning the syntax of the language is easy, but what about "everything else" using a language entails? Like how is stuff written in practice (pythonic / idiomatic), build tools, libs everyone use, workflow, etc

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

#84

Post by dunefox »

PartiallyTyped wrote: post #75
FridgeSeal wrote: post #68

Earlier quoted context omitted.

Python: where relying on “lol magic” is acceptable thing to have in production code. At least “magic” in languages like Haskell has the dignity to be backed up by a type system with more consistency than a wet noodle. Python can’t seem to decide whether it wants to be a production grade language or easy-for-beginners and keeps implementing pointless features (looking at you walrus operator and weird version or patter…

> But Python has never been about performance I have been burnt by this. As much as I like python's "expressiveness" so to speak, it is too slow for my needs; the ML community gravitated towards that because it is simple to implement and test large models because C++/C/Cuda are doing the lifting. However, in my flavour/field of ML, python is often the bottleneck because the sampling/simulations are glued with it and…

You might take a look at Julia with PyCall and RCall, if you haven't already. I find it solves a lot of headaches I have with Python while allowing me to leverage the ecosystem.

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

#85

Post by masklinn »

watt wrote: post #48
PartiallyTyped wrote: post #33

Earlier quoted context omitted.

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.

> Checking for reference equality (comparing pointers) is such a niche requirement it should be hidden behind stronger syntactic vinegar.

In python it’s common due to `None`, which you really want to check by identity. Other placeholders as well. This is such a major use case that in 3.9 `is` was moved out of the generic `compare_op` instruction and into its own.

And because __eq__ can be overridden, aside from being noticeably slower `x == None` is not truly reliable.

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

#86

Post by eirki »

pansa2 wrote: post #54
shoo wrote: post #52

Earlier quoted context omitted.

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

It is also marginally faster, I think.

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

#87

Post by pjc50 »

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…

Critiquing X, or even warning people about surprises in X, is not "anti-X". Have people picked up this weird idea from fandom culture or something? This article is not saying that people should not use python. It's not criticizing the maintainers for making stupid decisions, as far as I can see. It's just saying "if you do this, you'll get a surprising result", and in the process teaching people more about how it actually works.

One of the most informative books I read early in my career was "C traps and pitfalls". I've written a lot of C in the subsequent 20 years or so. It has some particularly nasty traps. Acknowledging that does not make me anti-C.

Pointing out that a saw is sharp does not make you anti-saw.

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

#88

Post by olau »

sorokod wrote: post #73
Doxin wrote: post #51

Earlier quoted context omitted.

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.

Not a python dev, but what is deeply weird about the examples in "Strings can be tricky..." section?

Both "id()" and its companion "is" are almost never used in practice - I don't think the tutorial mentions them. At least when it comes to id(), you'd have to find that in the reference where it will explain how it works.

If you're familiar with C, id() returns the memory address of the thing given to it, and "x is y" is like "id(x) == id(y)". So "x" is "x" is asking whether the Python runtime happened to put the two strings in the same place in memory, not whether the two strings are equal.

("is" is commonly used for one thing - testing against None. So you might write "a is None". I think that's just because someone once got bitten by a badly overloaded == operator. Just like some people will write === in all their Javascript, in case an incorrect type sneaks in.)

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

#89

Post by trfarmer »

My biggest issue with Python that is not related to syntax is that it isolates you from the Unix machine in a bad way.

I get that they try to support Windows with the same abstractions, but they are all leaky and subtly broken (like shutil). If you use Python too much, you lose the understanding of Unix.

Other languages aren't like that, for example Perl and Go.

Whenever I stop using Python for 2 weeks and focus on C or Go, my understanding of the machine and what is actually going on increases dramatically. I've even considered learning Perl, but haven't done it yet due to lack of time.

Post reply on HN