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

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

rectangletangle 11y

Python 3 removed this feature unfortunately.

tdicola 11y

Unfortunately? I'd love to know when changing false to mean true and vice-versa would make sense in any codebase.

rectangletangle 11y

>> (False, True) = (True, False)

>> 1 if False else 0

>> bool(0) == False

False

janzer 11y

Not entirely sure of your point but...

Python 3.4.0 (default, Apr 11 2014, 13:05:11)

[GCC 4.8.2] on linux

Type "help", "copyright", "credits" or "license" for more information.

>> (True, False) = (False, True)

  File "<stdin>", line 1

SyntaxError: can't assign to keyword

exogen 11y

But, like the parent said, in Python 3:

    >>> (False, True) = (True, False)
      File "<stdin>", line 1
    SyntaxError: can't assign to keyword

thaumasiotes 11y

    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-confusingly-named behavior. Suddenly False sometimes means one thing and sometimes means something else.

masklinn 11y

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())
    <class '__main__.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)

Comments