8 ms·
I can also do this, which is harmful. >>> True = False >>> False = True
by ronbeltran 11y ago
I can also do this, which is harmful.
>>> True = False
>>> False = True
- rectangletangle 11y agoPython 3 removed this feature unfortunately.
- tdicola 11y agoUnfortunately? I'd love to know when changing false to mean true and vice-versa would make sense in any codebase.
- rectangletangle 11y ago>>> (False, True) = (True, False) >>> 1 if False else 0 1 >>> bool(0) == False False
- janzer 11y agoNot 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 agoBut, like the parent said, in Python 3: >>> (False, True) = (True, False) File "<stdin>", line 1 SyntaxError: can't assign to keyword
- thaumasiotes 11y agoIn[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 agoThere'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)
- masklinn 11y agoThe second line doesn't do anything though, since you already reassigned True to False it's like assigning False to False. You could write (False, True) = (True, False) though.
- teddyh 11y agoOnly 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.
- Jach 11y agoOnly constant for certain values of "constant". ;) (https://gist.github.com/Jach/1208215 https://gist.github.com/Jach/1208215 works in Python 3 too.)
- netheril96 11y agoAre there any codes dependent on True and False being assignable? Don't those codes deserve to die?
- dalke 11y agoYes. There are codes written with backwards compatibility to versions of Python pre-2.3, which did not have True/False. They typically looked like this: try: True except NameError: True = 1==1 False = not True Such code would likely be at least 10 years old. Given the transition to Python 3, it seems the general answer is "yes, they deserve to die."
- arjn 11y agoWaaa! ... I just did that using 2.7 idle and it worked. This is new for me. I got stuck for a while trying to back out. Finally figured the way to reverse is to use del(): del(True) del(False).
- adregan 11y agoYou could also do True = True == True. It's like Dorothy clicking her heels together three times.