Why does a = a[0] = [0] create a self-referential list in Python?

https://susam.in/blog/peculiar-self-references.html

by susam • 5 years ago

64 21 5 years ago

anitil• 5 years ago

I'm amazed at how long I've been working in python and never known that assignment works in this way. I suppose I just avoid parts of the language that I don't understand.

Looking through the archives, it's a really interesting blog in general

klyrs• 5 years ago

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

londons_explore• 5 years ago

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

    print(a=5)

orf• 5 years ago

It’s possible now with the walrus operator though:

    print(a:=5)

heavyset_go• 5 years ago

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.

SOLAR_FIELDS• 5 years ago

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.

Loranubi• 5 years ago

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.

masak• 5 years ago

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.

saghm• 5 years ago

`==` 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.

lilyball2• 5 years ago

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

and have both a and b end up with the value of expr. And by defining it in the fashion that it does, it only requires the target list expressions to be evaluated once as an lvalue (or whatever python's equivalent is).

lilyball2• 5 years ago

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.

wheelerof4te4• 5 years ago

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.

kadoban• 5 years ago

At this point, fixing the issue would break all kinds of software that's depending on it working that way.

w0m• 5 years ago

This. It's known behavior that you can leverage.

dharmab2• 5 years ago

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.

wheelerof4te4• 5 years ago

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.

Why does a = a[0] = [0] create a self-referential list in Python?

Related Stories