Hacker News Reader

Comment by Waterluvian | Hacker News Reader

At one job I had we got "help" from a local college professor on how to design our database. A lot of what he said made sense. And we were super green and databases were not our expertise or focus. Short on time, high on cash, we asked if he'd implement it for us.

I will never forget my gut wrenching feeling when I opened up one of the main provisioning scripts (in Python) to read the first two lines:

  True = 0
  False = -1

The rest of it was an unmaintainable disaster that may have worked. I learned so much that summer, having been forced to learn it all myself.

View on HN

https://thedailywtf.com/articles/What_Is_Truth_0x3f_

>>I will never forget my gut wrenching feeling when I opened up one of the main provisioning scripts (in Python) to read the first two lines:

  True = 0
  False = -1

Could you please explain what is so egregious about those two lines for those people that may not see it? Asking for a friend.

True is normally 1, while False is 0. This seems like specific variable declarations as well, which you generally don't need as they are built into all languages e.g. "variable = false;"

However maybe the professor needed 'true/false' to represent something to be used in his formulas so this made sense to him. But who knows.

In most programming languages, including python, true is represented by 1 and false is represented by 0.

This script is changing it to be backwards, and python is flexible enough to allow that. But I would expect this would break most python libraries, because it's such a core language feature that's being completely restructured.

https://en.wikipedia.org/wiki/Boolean_data_type

When doing comparison checking, in most programming languages false is 0 and true is any other value.

python is flexible enough to allow that

Is there a valid use case for changing the numeric values of True and False?

No.

It’s, IMHO, a terrible idea but the one use I could imagine is if you are doing a lot of stuff with Unix exit codes, where exit code 0 is success. That would cover setting True = 0 ...maybe but not failure which is usually a positive exit code.

No! Actually I take it back this _is_ definitely still a terrible idea and will lead to certain madness for all involved. :)

True != Success

True = (True != Success)

No, it's legacy behavior and the community took the opportunity to fix it in Python 3, where it raises a SyntaxError.

Python 2 has _many_ quirks like this one. Python 3 was not just "it's unicode".

Actually Python 2 allows that, in Python 3 True, False, and None are reserved words [1].

[1] https://docs.python.org/3/whatsnew/3.0.html#changed-syntax

Luckily, assigning to True and False affects only the current module. If he had changed __builtins__.True and __builtins__.False, on the other hand...

(Python has a search path: it looks first on the current module, then on the built-in __builtins__ module, which is where the built-in constants and functions reside.)

    >>> True = 0
    >>> False = -1
    >>> if False: print('oh no')

False is now truthy and True is falsey. Note this only works in python2.

I literally almost choked on my drink reading this.

That's a nice story, but True and False are keywords in python. Such assignment attempts are a syntax error.

This was not true in Python 2, and redefining True to False used to be a jokey way to break the interpreter in a bunch of fun ways.

In fact, there's still lots of code in the wild that assigns to True/False, presumably for compatibility with very old Python versions:

https://codesearch.debian.net/search?q=%28%3Fm%29%5E%5Cs%2AT...

Reply on news.ycombinator.com