Why does a = a[0] = [0] create a self-referential list in Python?(susam.in)
susam.in
Why does a = a[0] = [0] create a self-referential list in Python?
https://susam.in/blog/peculiar-self-references.html
22 comments
Some languages wear the things that make you go WTF on their sleeves. In contrast, Python's surprises pop up slowly over time, and in places where you'd least expect them.
I wonder if it’s because of their subtlety. I assume you are referencing JavaScript, where the warts are impossible to ignore because you can’t write an everyday program as a beginner without running into them. This sort of thing from the article is just not something I would typically be trying to do in the normal course of shuffling data around.
I mean, it generally looks like a terrible idea, so absent of malice to the reader (or code golf shenanigans) nobody would do this. Not a surprise that the behavior is surprising...
It's fallout of the fact that assignment must be a statement, and cannot be an expression.
Eg. This is wrong in python, while it would be allowed in c-like languages
Eg. This is wrong in python, while it would be allowed in c-like languages
print(a=5)It’s possible now with the walrus operator though:
print(a:=5)Usually this op chain feature is used to allow `if a == b == c:`. This is resolved as (a==b) and (a==c). Following this logic the assignment statement is extended the same way as far as I understand. It's just more surprising.
I don't think so. The assignment behavior here is explicit, not some emergent fact of operator chaining in general. I think it's meant to allow you to say
a = b = expr
Thinking about it some more, the surprising behavior here is pretty much just that it does the assignments in left-to-right order instead of right-to-left order. If you try and break down `a = b = expr` into a series of binary assignment operators, the natural answer is `a = (b = expr)` (b doesn't exist yet so you can't write `(a = b) = expr`) where `(b = expr)` behaves as though it returns the value again. And I believe this is in fact how it works in Ruby (as Ruby assignments return the value). But Python assignments don't actually return the value, as they are statements and not expressions.
Presumably Python does the assignments in left-to-right order because any observable side-effects in the evaluations of a and b would be expected to be in left-to-right order. It just results in counterintuitive behavior like this.
Presumably Python does the assignments in left-to-right order because any observable side-effects in the evaluations of a and b would be expected to be in left-to-right order. It just results in counterintuitive behavior like this.
The two behaviors don't seem very related.
In `if a == b == c`, the value of `b` is evaluated only once, even if `b` is in fact a bigger/side-effecting expression, and `c` might not be evaluated at all.
In `a = b = c`, the `c` is evaluated first, and then `a` and `b` are assigned to, left-to-right.
In `if a == b == c`, the value of `b` is evaluated only once, even if `b` is in fact a bigger/side-effecting expression, and `c` might not be evaluated at all.
In `a = b = c`, the `c` is evaluated first, and then `a` and `b` are assigned to, left-to-right.
`==` doesn't have side effects though, so you don't have to worry about the order of uses of a variable that appears twice; it will have the same value both Tony's l times. It seems like a bad idea to me to have operators with side effects use the same rules as ones that don't just because they happen to have similar syntactic representations, but I've never written a non-toy programming language, so I guess there could be something I'm missing.
[deleted]
Something like this should not be possible. Instead of adding new "features" left and right, Python must deal with problems like these.
Fix the bugs, improve performance, sort out packaging. Leave the language as it is, improve the implementation. It is already possible to write any kind of software using existing features.
Let's avoid making this language harder than it has to be. It was a truly simple language, now it is turning into Frankenstein's monster and you have to google for new added syntax every time you need to use it.
Fix the bugs, improve performance, sort out packaging. Leave the language as it is, improve the implementation. It is already possible to write any kind of software using existing features.
Let's avoid making this language harder than it has to be. It was a truly simple language, now it is turning into Frankenstein's monster and you have to google for new added syntax every time you need to use it.
There are efforts to improve these things.
I converted some projects to pyproject.toml (the new standard for defining a project) and between it and the Poetry build/packaging tool it's pretty much solved the packaging nightmare.
There is now a branch of CPython that removes the GIL with significantly better performance in some benchmarks. There is active discussion on the mailing lists about how to get it into mainline.
I converted some projects to pyproject.toml (the new standard for defining a project) and between it and the Poetry build/packaging tool it's pretty much solved the packaging nightmare.
There is now a branch of CPython that removes the GIL with significantly better performance in some benchmarks. There is active discussion on the mailing lists about how to get it into mainline.
How heavy is Poetry tool? What's it's selling point when compared with setuptools?
With setuptools, I just make setup.py and run pip install inside the root directory. If I have wheel, pip builds a wheel for my package.
Sorry, but I don't want to learn yet another packaging meta-language when plain Python worked fine for decades. Python already tried with setup.cfg ini files and people rejected it. Why would pyproject.toml be any better?
Why not improve setuptools instead? That is what sorting out packaging means. Stop copying other languages and focus on Python. Core devs took typing syntax, pattern matching and packaging from Rust and bolted it all on Python like it fits.
Well, it does not fit. Stick to your own.
With setuptools, I just make setup.py and run pip install inside the root directory. If I have wheel, pip builds a wheel for my package.
Sorry, but I don't want to learn yet another packaging meta-language when plain Python worked fine for decades. Python already tried with setup.cfg ini files and people rejected it. Why would pyproject.toml be any better?
Why not improve setuptools instead? That is what sorting out packaging means. Stop copying other languages and focus on Python. Core devs took typing syntax, pattern matching and packaging from Rust and bolted it all on Python like it fits.
Well, it does not fit. Stick to your own.
Poetry still uses setuptools! It makes it a lot easier for mortals. This is the blog post that convinced me to switch away from my old build system: https://blog.ganssle.io/articles/2021/10/setup-py-deprecated...
I just tried Poetry on Windows.
Installation is a mess, and official recommendation of "copying a powershell line" was already a red flag. Now I can't remove it.
Poetry is a convoluted, insecure mess. Please avoid it and use official PyPi recommendations.
Installation is a mess, and official recommendation of "copying a powershell line" was already a red flag. Now I can't remove it.
Poetry is a convoluted, insecure mess. Please avoid it and use official PyPi recommendations.
The blog post recommends build, not Poetry. But I guess the Python devs finally started taking this seriously.
Since build is semi-official Python project, I will use it instead of Poetry. We can no longer rely on setup.py, it seems.
Thanks.
Since build is semi-official Python project, I will use it instead of Poetry. We can no longer rely on setup.py, it seems.
Thanks.
Python has a long history of adopting good ideas from other languages.
None of the things you mentioned were invented by Rust.
None of the things you mentioned were invented by Rust.
setuptools design is a mess. pip will likely support it forever though so you are fine.
Looking through the archives, it's a really interesting blog in general