Live data from Hacker News

WTFPython – Understanding Python through surprising snippets

github.com

91–100 of 199 posts

Re: WTFPython – Understanding Python through surprising snippets

#91
post #8

My biggest complaint about Python is that it somehow doesn’t get flak for having the same (if not worse) scoping as JS, which gets endless hate for its function-scoped variables. (So much so that block scoped variables are the new normal in JS, but not in Py!) Take for instance: >>> powers_of_x = [lambda x: x^i for i in range(10)] >>> [f(2) for f in powers_of_x] [512, 512, 512, 512, 512, 512, 512, 512, 512, 512] To m…

I don't find this at all unexpected. In an imperative language I expect a loop to be implemented by mutating a common variable.

[deleted]

Re: WTFPython – Understanding Python through surprising snippets

#92
post #8

My biggest complaint about Python is that it somehow doesn’t get flak for having the same (if not worse) scoping as JS, which gets endless hate for its function-scoped variables. (So much so that block scoped variables are the new normal in JS, but not in Py!) Take for instance: >>> powers_of_x = [lambda x: x^i for i in range(10)] >>> [f(2) for f in powers_of_x] [512, 512, 512, 512, 512, 512, 512, 512, 512, 512] To m…

[deleted]

Re: WTFPython – Understanding Python through surprising snippets

#93
post #71

Earlier quoted context omitted.

Yeah, current versions of Python feel like Guido and the rest changed their minds about what they wanted.

Python is a very old language. First version in 1991! This is no surprise Guido evolved with it, and changed his mind about a few things. People are never happy. On the other side of the fence, you have others crying the language is not moving fast enough.

I understand why people are willing to defend it or make apologies for it, but there really are some lessons to be learned from the mistakes it made, and dismissing legitimate criticism just ignores the opportunity.

Re: WTFPython – Understanding Python through surprising snippets

#94
post #87

It's a good repo, but remember a lot of those are "A Good Thing™". The first snippet is a very good example: a := "wtf_walrus" doesn't work while: (a := "wtf_walrus") works. It's a fantastic design decision. Python took a long time before getting this operator, because it's a language that favors being readable, easy to use, and above all, to learn. But in many other languages, the very same operator is often misused…

Why should people only use it when necessary? Why not say “the walrus operator is the exact same as the assignment operator, but it can be used in expressions and thus is spelled a bit differently in order to better distinguish it from the equality operator. Feel free to use it in all places you’d previously use the assignment operator.”. Simple, easy to understand, easy to learn, and most importantly (though python…

> Why should people only use it when necessary?

Because we have experience with things such as easy of learning, cognitive load, writing simple to read code, making it hard to introduce bugs...

This comment show how little experience one can have with it, and yet make a quick judgment to offer to "fix" things. E.G:

> eel free to use it in all places you’d previously use the assignment operator.”. Simple, easy to understand, easy to learn, and most importantly (though python folks might disagree, given 2 => 3), easy to adopt.

Well because in many languages, people do this:

    while (foo = bar):
While they mean this:

    while (foo == bar):
Even experienced devs do this by mistake from time to time. It's hard for tooling to find out if you are doing something stupid or smart. Beside, you don't use tooling when you learn the language or do a quick script.

Designing a language is not a 15 days job in a rush. Usually.

Re: WTFPython – Understanding Python through surprising snippets

#95
post #93

Earlier quoted context omitted.

Python is a very old language. First version in 1991! This is no surprise Guido evolved with it, and changed his mind about a few things. People are never happy. On the other side of the fence, you have others crying the language is not moving fast enough.

I understand why people are willing to defend it or make apologies for it, but there really are some lessons to be learned from the mistakes it made, and dismissing legitimate criticism just ignores the opportunity.

I agree, there is a long list of things I would change in Python. And believe me when I say people involved in the community listen to this very carefully.

This is why we had Python 3 in the first place. Because text handling was such a cause of pain.

This is why we have type hints in the first place. Because big projects using Python felt let down.

And Python 3 and type hints are also a huge source of criticism (I was the first one to do so).

It's never ending. People will complain. People will be unhappy. Things, also, will be imperfect, as we are limited in resources and are submitted to many constraints. Not to mention taste and opinion, that are used to request changes.

But I'm not answering to dismiss valid concerns. I'm answering because as a very experienced Python dev, I now have a good grasp of what is due to culture, lack of experience, or a real deal.

E.G:

- := forcing parenthesis. Has not been a real problem in my experience, at least as of today.

- Packaging still more complicated that necessary. A real problem in the field (although 50% of it is a teaching problem: https://twitter.com/bitecode_dev/status/1188130895653416966).

Re: WTFPython – Understanding Python through surprising snippets

#96

Python 3 supports typing. The integration with VSCode is also nice. The following is valid typed code and my personal favorite WTF: def func() -> int: return True Because: https://github.com/satwikkansal/wtfpython/blob/master/README... I understand the decision that was made in the python 2 era. Nowadays Boolean shouldn't be a subtype of `int`. It goes against the zen of python: - Explicit is better than implicit. It…

Yeah, typing KINDA works until you try to use a library that has no annotations and uses reflections, such as - say - plumbum, boto3 or some other pre-typing shit. It's a bit like with async code - once you decide to use it, you can keep the language but basically need a whole new ecosystem. I tried to write an actual company project with `mypy --strict` passing as a requirement and you quickly end up having abstractions only to bypass mypy, as well as surpress comments as uses of Any. And this is where it pays off to just switch to a statically typedk, compiled language.

Re: WTFPython – Understanding Python through surprising snippets

#97

It's a good repo, but remember a lot of those are "A Good Thing™". The first snippet is a very good example: a := "wtf_walrus" doesn't work while: (a := "wtf_walrus") works. It's a fantastic design decision. Python took a long time before getting this operator, because it's a language that favors being readable, easy to use, and above all, to learn. But in many other languages, the very same operator is often misused…

I thought this walrus thing looked esoteric and ridiculous. Two words which also describe Python. I think it's prime time for the scripting languages to be disrupted. Twould be nice to have one as well designed and consistent as Rust.

Re: WTFPython – Understanding Python through surprising snippets

#98
post #93

Earlier quoted context omitted.

I understand why people are willing to defend it or make apologies for it, but there really are some lessons to be learned from the mistakes it made, and dismissing legitimate criticism just ignores the opportunity.

I agree, there is a long list of things I would change in Python. And believe me when I say people involved in the community listen to this very carefully. This is why we had Python 3 in the first place. Because text handling was such a cause of pain. This is why we have type hints in the first place. Because big projects using Python felt let down. And Python 3 and type hints are also a huge source of criticism (I w…

> Because big projects using Python felt let down.

Why big projects started using Python in the first place is a very good question, given that this language had not been designed for them...

Re: WTFPython – Understanding Python through surprising snippets

#99
post #8

My biggest complaint about Python is that it somehow doesn’t get flak for having the same (if not worse) scoping as JS, which gets endless hate for its function-scoped variables. (So much so that block scoped variables are the new normal in JS, but not in Py!) Take for instance: >>> powers_of_x = [lambda x: x^i for i in range(10)] >>> [f(2) for f in powers_of_x] [512, 512, 512, 512, 512, 512, 512, 512, 512, 512] To m…

You forgot the i=i in your lambda definition. Then there exists a local variable i and everything works as you wanted.

Re: WTFPython – Understanding Python through surprising snippets

#100
post #87

Earlier quoted context omitted.

Why should people only use it when necessary? Why not say “the walrus operator is the exact same as the assignment operator, but it can be used in expressions and thus is spelled a bit differently in order to better distinguish it from the equality operator. Feel free to use it in all places you’d previously use the assignment operator.”. Simple, easy to understand, easy to learn, and most importantly (though python…

> Why should people only use it when necessary? Because we have experience with things such as easy of learning, cognitive load, writing simple to read code, making it hard to introduce bugs... This comment show how little experience one can have with it, and yet make a quick judgment to offer to "fix" things. E.G: > eel free to use it in all places you’d previously use the assignment operator.”. Simple, easy to unde…

I don’t think you’ve actually understood my proposal, and the snide remarks about completely unrelated languages don’t help your argument.

To reiterate, my proposal is that the walrus operator has the exact same semantics as the assignment operator, but creates an expression rather than a statement. A linter rule could then be added prohibits the assignment operator, and converts all instances of it to the walrus operator. The codebase now has only the two operators. Language reference books need only explain the two operators, and simply note that the legacy assignment operator behaves the same as the walrus operator but cannot be used in expressions. This is easy to learn.

What the language creators have done instead is add a whole new operator with all new semantics, leading to all new sources of confusion. (See TFA). This is not easy to learn.

Side note: It’s funny that you appeal to the authority of the language creators with phrases like: Python is easy because “the language is a collections of thousands of such decisions”, yet ignore the fact that the actual creator of the language was so against the addition of this operator that he saw the community’s insistence on it as reason to step down as BDFL.

Post reply on HN