Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python bug: Can assign [] = (), but not () = []

bugs.python.org

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Python bug: Can assign [] = (), but not () = []

#31

Post by IsTom »

teddyh wrote: post #27
Jach wrote: post #26

Earlier quoted context omitted.

Only constant for certain values of "constant". ;) ( https://gist.github.com/Jach/1208215 works in Python 3 too.)

After “import ctypes”, all bets are off.

There are ways to mark memory pages as read-only. It's not even difficult.

Re: Python bug: Can assign [] = (), but not () = []

#32

Post by netheril96 »

teddyh wrote: post #13
ronbeltran wrote: post #10

I can also do this, which is harmful. >>> True = False >>> False = True

Only in Python 2, since that is a backward-compatibility feature. (“False” and “True” used to be variables containing 0 and 1 before Python had true booleans, many ages ago.) Python 3 makes “True” and “False” be constant values, like “1” or “2”, like they should be.

Are there any codes dependent on True and False being assignable? Don't those codes deserve to die?

Re: Python bug: Can assign [] = (), but not () = []

#33

Post by masklinn »

thaumasiotes wrote: post #30
rectangletangle wrote: post #15

Earlier quoted context omitted.

>>> (False, True) = (True, False) >>> 1 if False else 0 1 >>> bool(0) == False False

In[2]: (True, False) = (False, True) In[3]: True Out[3]: False In[4]: 1 if False else 0 Out[4]: 1 In[5]: 'yes' if bool(0) == False else 'no' Out[5]: 'no' In[6]: bool(0) == False Out[6]: False What bothers me here is that when the interpreter says "False", it clearly means the opposite of (the new) False. So by reassigning True and False, I've actually caused inconsistent behavior in python, not just really-confusingl…

There's no inconsistency, the "False" printed in your console is just the repr of the object, you can give that repr to your own object if you have nothing better to do with your life:

    >>> A()
    False
    >>> bool(A())
    True
    >>> type(A())
A repr is just a representation in development context, nothing more and nothing less, there is no requirement that it be sensible or of any use, though that's certainly recommended (contrary to __str__/__unicode__ which should be silly):

    >>> B()
    A gray parrot
The only "inconsistency" you've created is that False in the console's local namespace does not match __builtins__.False or the interpreter's internal False object. You can still access the former by the way:

    >>> False
    True
    >>> __builtins__.False
    False
unless you also override it:

    >>> __builtins__.False = True
    >>> __builtins__.False
    True
the interpreter still does not care though, you've just broken any Python code relying on the builtin (you can actually alter the "true" False object via ctypes)

Re: Python bug: Can assign [] = (), but not () = []

#34

Post by rjaco31 »

IsTom wrote: post #31
teddyh wrote: post #27

Earlier quoted context omitted.

After “import ctypes”, all bets are off.

There are ways to mark memory pages as read-only. It's not even difficult.

Why would you do that? That code is working perfectly as intended, the user is allowed to do that

Re: Python bug: Can assign [] = (), but not () = []

#37

Post by echeese »

iaw wrote: post #5

I was very impressed with the collective thought process shown in the bug thread. It was quite constructive and I think demonstrative of why python has been such a successful project.

If it was PHP they'd just write it down and claim it's documented behaviour.

Re: Python bug: Can assign [] = (), but not () = []

#38

Post by netmare »

rectangletangle wrote: post #22
rzimmerman wrote: post #21

Earlier quoted context omitted.

That could be because sets aren't ordered (even though it looks odd in this context).

I thought that at first too, but even then the exception seems spurious. It would be more inline with existing Python behavior to evaluate it as undefined/indeterminate assignment order (though this would be pretty useless). >>> a, b, c, d = {1, 2, 3, 'a'} >>> a 'a' Regardless, it shouldn't be surprising when writing insane code, that the language starts acting insane. Python as a whole is pretty decent when it comes…

The tricky part is that the [a,b] and (a,b) in your original examples are not list/tuple literals, but a target_list according to Python's grammar [0], which can be optionally enclosed in parentheses or brackets. To be honest, I didn't know the latter were allowed, even though I've been using Python for years. IMHO, they should have just allowed parentheses. It's like the parentheses in function calls--not really a tuple, but syntactic grouping. Why have more that one way to do the same thing?

[0]: https://docs.python.org/3/reference/simple_stmts.html#assign...

Re: Python bug: Can assign [] = (), but not () = []

#40

Post by coldtea »

echeese wrote: post #37
iaw wrote: post #5

I was very impressed with the collective thought process shown in the bug thread. It was quite constructive and I think demonstrative of why python has been such a successful project.

If it was PHP they'd just write it down and claim it's documented behaviour.

Not consistent with my recollection of PHP since version 5, where they have fixed tons of old inconsistencies from the parser to the API level.

Perhaps based on older versions of PHP or merely uninformed snark?

Post reply on HN