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

Please reconsider the Boolean evaluation of midnight

mail.python.org

Post reply on HN
Print view View original

191–200 of 218 posts

Re: Please reconsider the Boolean evaluation of midnight

#191

Post by mooism2 »

bjourne wrote: post #190
clarkevans wrote: post #113

INADA Naoki's argument [1] is succinct and insightful. I feel zero value of non abelian group should not mean False in bool context. () + () == () "" + "" == "" 0 + 0 == 0 timedelta() + timedelta() == timedelta() time() + time() => TypeError [1] https://mail.python.org/pipermail/python-ideas/2014-March/02...

But you can make an equally succinct argument in the opposite direction, namely to treat time values as polar coordinates. Then they indeed form an abelian group: a + 0:00 = a 15:00 + 13:00 = 02:00 12:00 + 12:00 = 00:00 The examples are for hours only, but you can extend it for minutes too. Showing that time values on a clock forms an abelian group under addition is a textbook example everyone uses when introducing g…

But it's wrong.

I'll assume the times you gave were in the UK's timezone. Here they are rewritten to use Germany's timezone.

    a + 1:00 = a
    16:00 + 14:00 = 03:00
    13:00 + 13:00 = 01:00
Still think this makes sense?

Time deltas? Then you don't have the timezone or epoch problem. Works fine.

But time stamps? You can't add two time stamps and get a sensible answer.

Time stamps form a torsor, not a group: http://math.ucr.edu/home/baez/torsors.html

Re: Please reconsider the Boolean evaluation of midnight

#192

Post by Robadob »

I came across a similar issue when using rails the other day, where I gave my model a boolean field that had presence validation. The presence validation of the boolean field fails if the bool is set to false, had me confused for a while, but It wasn't a big enough issue for me to research/report.

Re: Please reconsider the Boolean evaluation of midnight

#193

Post by username223 »

Grue3 wrote: post #177
tomchristie wrote: post #73

So ignoring the hype, here's the outcome-to-date... The ticket was reconsidered, reopened and classified as a bug. http://bugs.python.org/msg212771 Nick Coghlan's dissection of the issue here: https://mail.python.org/pipermail/python-ideas/2014-March/02... is pretty much perfect - wonderful piece of technical writing! Donald Stufft has expressed an interest in making the patch for this happen, and assuming all goes a…

Will it be resolved in 2.x though? That's what most people care about.

My guess is that eventually someone with enough money on the line will be sufficiently harmed by the Python 3 nonsense to maintain 2.x, at which point obvious bugfixes like this will be "ported" (it's probably a 2-line change).

Re: Please reconsider the Boolean evaluation of midnight

#195

Post by bjourne »

mooism2 wrote: post #191
bjourne wrote: post #190

Earlier quoted context omitted.

But you can make an equally succinct argument in the opposite direction, namely to treat time values as polar coordinates. Then they indeed form an abelian group: a + 0:00 = a 15:00 + 13:00 = 02:00 12:00 + 12:00 = 00:00 The examples are for hours only, but you can extend it for minutes too. Showing that time values on a clock forms an abelian group under addition is a textbook example everyone uses when introducing g…

But it's wrong. I'll assume the times you gave were in the UK's timezone. Here they are rewritten to use Germany's timezone. a + 1:00 = a 16:00 + 14:00 = 03:00 13:00 + 13:00 = 01:00 Still think this makes sense? Time deltas? Then you don't have the timezone or epoch problem. Works fine. But time stamps? You can't add two time stamps and get a sensible answer. Time stamps form a torsor, not a group: http://math.ucr.ed…

You're right, but time values with timezones are completely different types from time values without. They follow different rules and need to be treated differently.

Re: Please reconsider the Boolean evaluation of midnight

#196

Post by dalke »

dalke wrote: post #189
sesqu wrote: post #188

Earlier quoted context omitted.

{1:"AB"} That's how it usually works with functions.

If you want that, try the Counter class: >>> from collections import Counter >>> Counter({1: "a"}) + Counter({1: "b"}) Counter({1: 'ab'}) But Python dictionaries won't support '+' because of the ambiguity. This goes back to 1994: http://ftp.ntua.gr/mirror/python/search/hypermail/python-199... Lance Ellinghouse: why can't I add dictionaries like I can other objects? ... if a and b both had the same keys, then I think…

This is neat:

    >>> a = Counter()
    >>> a[1] = a
    >>> b = Counter()
    >>> b[1] = b
    >>> a + b
    Traceback (most recent call last):
      File "", line 1, in 
      File "...../collections.py", line 536, in __add__
        newcount = self[elem] + other[elem]
      File "...../collections.py", line 534, in __add__
        result = Counter()
    RuntimeError: maximum recursion depth exceeded
If dict() implemented add as you propose then it would be subject to the same errors. This observation doesn't make your proposal wrong. I mean it to point out the subtle complexities which might come up if a large number of people don't know what it's supposed (and even documented) to do.

Re: Please reconsider the Boolean evaluation of midnight

#197

Post by aninhumer »

TheZenPsycho wrote: post #141
nbouscal wrote: post #39

Earlier quoted context omitted.

Would you intentionally introduce language features that break functionality for people who don't follow style guidelines? I certainly hope not. The real problem with your argument is that the poorly-styled code of people who haven't learned better yet is in production . This isn't a theoretical exercise. This is a tool used in industry, and "teaching people to style their code better" is not a valid excuse for costi…

>Would you intentionally introduce language features that break functionality for people who don't follow style guidelines? Uhm maybe I'm confused but isn't that the whole design philosophy behind python? It makes bad indentation a syntax error!

>It makes bad indentation a syntax error!

No, its syntax for determining block structure is indentation. The designers didn't say "Hey lets complain about bad indentation" they said "Hey, people should be indenting their code properly anyway, so why not make that the syntax?"

Also, they didn't introduce it to an existing project, it was there from the beginning (AFAIK).

Re: Please reconsider the Boolean evaluation of midnight

#198

Post by frou_dh »

icarus127 wrote: post #129
throwaway7808 wrote: post #112

Earlier quoted context omitted.

Type-safe format strings should never be mixed with plain strings, constant strings, byte strings, unicode strings, batteries strings, byte array strings, char array strings, string buffers or any other type of string supported by ocaml. Keep your types pure and never mix them with any other types. Never . And you will never have any problem. And these python developers are lunatics. It is preposterous to use 'if' co…

Indeed, the first thing that came into my mind when reading this was "You wouldn't have this problem if the only valid type in a conditional was boolean."

It's against the grain to think this way in dynamic languages because variables don't have types, only individual values do. Ill-thought truthiness rules are the real problem. IMO every value except boolean false (and, if you insist, nil/null) should be truthy in a dynamic language.

Re: Please reconsider the Boolean evaluation of midnight

#199

Post by Perseids »

Grue3 wrote: post #177
tomchristie wrote: post #73

So ignoring the hype, here's the outcome-to-date... The ticket was reconsidered, reopened and classified as a bug. http://bugs.python.org/msg212771 Nick Coghlan's dissection of the issue here: https://mail.python.org/pipermail/python-ideas/2014-March/02... is pretty much perfect - wonderful piece of technical writing! Donald Stufft has expressed an interest in making the patch for this happen, and assuming all goes a…

Will it be resolved in 2.x though? That's what most people care about.

> That's what most people care about.

I'll make an equally aggressive counter point: Dammit guys and gals, stop using 2.x. Python 3 came out more than 6 years ago. You are holding back and splitting the community. And if you tell me 3.x has no perceived value then this is the value that is slowly stacking up.

Re: Please reconsider the Boolean evaluation of midnight

#200

Post by barakm »

dalke wrote: post #150
clarkevans wrote: post #113

INADA Naoki's argument [1] is succinct and insightful. I feel zero value of non abelian group should not mean False in bool context. () + () == () "" + "" == "" 0 + 0 == 0 timedelta() + timedelta() == timedelta() time() + time() => TypeError [1] https://mail.python.org/pipermail/python-ideas/2014-March/02...

If that were true, it would mean that dict should not support bool: >>> {} + {} Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'dict' and 'dict' >>> bool({}) False Since I find bool(a_dict) to be very useful, and the lack of a_dict+b_dict to be reasonable (precisely because it's non-abelian!), I conclude that logic is cute, but not that relevant. Those who think…

bool({}) should raise an exception, if we're being strict.

You could try to define the addition of keys like you suggest, but you need to force a value type which defines a + operation into the same type. Which is what Counter() does, below (appending strings).

Python is dynamically typed, so you can't maintain these expectations. Therefore, summation and bool({}) should be an error, or merely "true" (ie, yes, it exists, and is not None) -- as per the original thread and resolution.

Post reply on HN