On 2014-03-05, at 11:23 , Paul Moore <p.f.moore@gmail.com> wrote:

On 5 March 2014 10:16, Shai Berger <shai@platonix.com> wrote:

...

http://bugs.python.org/issue13936 is a complaint about the fact that midnight -- datetime.time(0,0,0) -- is evaluated as False in Boolean contexts. It was closed as invalid, under the claim that """It is odd, but really no odder than "zero values" of other types evaluating to false in Boolean contexts""".

I would like to ask for this to be reconsidered; since the ticket was closed, two main arguments were given for this:

Why on earth would anyone check the boolean value of a time???

Side-effect of e.g. an object with an optional (nullable) time field, the developer didn't realise a time could be false-ish (because seriously?) and then it turns out code along the lines of if event.start_time: # stuff unexpectedly fails if start_time is midnight. I've actually done something close recently, didn't expect more_itertool's peekable iterator could be false-ish[0] because I'd expect empty sequences to be falsy but not empty iterators. It turned out to be useful and to simplify my code, but I can see developers not considering such edge cases unless there's a clear warning (as in ElementTree which IIRC clearly warns that an element with no children is false-ish) especially for objects for which false-ish-ness makes so little sense as a time. [0] even though the behavior is documented.

On Wednesday 05 March 2014 12:44:07 Paul Moore wrote:

I actually find the idea of truth-testing a value that's expected to have a type that is always true *more* unintuitive than an explicit "is not None", so I'd fix the above code regardless of what the truth value of midnight is.

I can appreciate this point of view, but I think it is not the position generally taken by Python (if it were, Boolean evaluation of an object of a type that is always true would have raised an exception). Shai.

On 5 March 2014 12:34, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:

On 5 March 2014 10:59, Shai Berger <shai@platonix.com> wrote:

...

On Wednesday 05 March 2014 12:44:07 Paul Moore wrote:

...

I actually find the idea of truth-testing a value that's expected to have a type that is always true *more* unintuitive than an explicit "is not None", so I'd fix the above code regardless of what the truth value of midnight is.

I can appreciate this point of view, but I think it is not the position generally taken by Python (if it were, Boolean evaluation of an object of a type that is always true would have raised an exception).

I think it's clear that if this were new code being added to the stdlib then the consensus would be that having midnight evaluate as False is ridiculous.

The question is surely whether the issue is worth a backwards compatibility break not whether the current behaviour is a good idea (it clearly isn't).

Precisely. Sorry I wasn't clear enough. And FWIW, my opinion is that the problem is not worth a compatibility break, because it's so easily solved (and the fixed code is probably an improvement in any case). Paul

On 5 March 2014 13:10, Shai Berger <shai@platonix.com> wrote:

On Wednesday 05 March 2014 14:54:27 Paul Moore wrote:

...

And FWIW, my opinion is that the problem is not worth a compatibility break, because it's so easily solved (and the fixed code is probably an improvement in any case).

Ah, but it is only easily solved once it is detected; the behavior causes bugs that surface once in a blue moon (in production, and then they cannot be reproduced by developers who, usually, do not work at midnight).

That's a fair point. But your deprecation suggestion doesn't seem to help this, unless you expect (in a realistic timescale) to be able to drop support for Python <3.7. Your users (on say 2.7 or 3.3) will still get bugs, and now your developers (using 3.7) won't even be able to reproduce the issue by staying up till midnight. And once they do find the bug they will still have to fix it by an explicit test. Again, I'm not saying the current behaviour is sensible, but I doubt the work to fix it will benefit anyone in practice. Paul.

On Wednesday 05 March 2014 15:26:38 Paul Moore wrote:

On 5 March 2014 13:10, Shai Berger <shai@platonix.com> wrote:

...

On Wednesday 05 March 2014 14:54:27 Paul Moore wrote:

...

And FWIW, my opinion is that the problem is not worth a compatibility break, because it's so easily solved (and the fixed code is probably an improvement in any case).

Ah, but it is only easily solved once it is detected; the behavior causes bugs that surface once in a blue moon (in production, and then they cannot be reproduced by developers who, usually, do not work at midnight).

That's a fair point. But your deprecation suggestion doesn't seem to help this, unless you expect (in a realistic timescale) to be able to drop support for Python <3.7.

I expect to drop support for Python<3.7 sometime...

Your users (on say 2.7 or 3.3) will still get bugs, and now your developers (using 3.7) won't even be able to reproduce the issue by staying up till midnight.

If my developers are using 3.7 to debug problems that user encounter with 3.3, they deserve to stay up till midnight and beyond.

And once they do find the bug they will still have to fix it by an explicit test.

The process I want to see is, that Boolean evaluations of time objects is slowly, but more-or-less completely removed from code that targets Python<3.7; then, in a few years, people can go back to writing "if event.start_time" like they do with dates and datetimes.

Again, I'm not saying the current behaviour is sensible, but I doubt the work to fix it will benefit anyone in practice.

So, you support my other suggestion -- a warning on every use of bool(time)? Also, the work to fix it is probably less than the work invested in this discussion so far... In any case, if we all agree that http://bugs.python.org/issue13936 is a valid problem -- can we re-open it, and then discuss how (or if) we solve it? Thanks, Shai.

On 05/03/2014 15:01, Paul Moore wrote:

On 5 March 2014 13:53, Shai Berger <shai@platonix.com> wrote:

...

then, in a few years, people can go back to writing "if event.start_time" like they do with dates and datetimes.

Why on earth would they do that? It's still bad practice. If you're using None as a sentinel, you should test for it explicitly. Nobody has yet suggested any other use case where this matters.

...

...

Again, I'm not saying the current behaviour is sensible, but I doubt the work to fix it will benefit anyone in practice.

So, you support my other suggestion -- a warning on every use of bool(time)?

No. Good programming practice should cover that. We don't warn in other cases where programmers make silly coding errors. Look at Skip's message - should we also warn on uses of bool(int) because people can write bad code that fails to work properly with zero, as well?

...

Also, the work to fix it is probably less than the work invested in this discussion so far...

That is not obvious (given documentation, release management, etc, costs).

...

In any case, if we all agree that http://bugs.python.org/issue13936 is a valid problem -- can we re-open it, and then discuss how (or if) we solve it?

We don't. Can we agree that it's not a bug and abandon this fruitless discussion?

Paul

I wouldn't agree that this has been a fruitless discussion. I would agree that this is not a bug, that the code needs changing, and that at least one new test needs to be added to the unit test suite(s) for the buggy application(s). -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

On 5 March 2014 15:19, Shai Berger <shai@platonix.com> wrote:

What, other than "bug", do you call behavior that isn't sensible?

"Unfortunate". I'm not arguing that the behaviour is useful. Or sensible. What I'm arguing, and you're missing, is that the behaviour is as documented, and so can't be changed without backward compatibility implications. Specifically, see http://docs.python.org/3.4/library/datetime.html#time-objects: """in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that's None), the result is non-zero.""" Your code is ignoring documented behaviour. Worse, your code can clearly be improved by being explicit in your test, and yet you'd rather argue that the Python developers implement a backward compatibility break which you won't even be able to take advantage of until you drop support of versions of Python before 3.7. Paul.

Ryan Hiebert writes:

he'd just like to see Python be better.

We all agree that we'd like Python to be better. But many of us feel that the proposed change does not make Python better. It merely makes it more comfortable for what we (many of us, anyway) consider to be badly written code, and encourages people to write more code in poor style as we see it.

it seems that we are disagreeing on whether this strange behavior should ever change.

Well, yes, for Python 2 (obviously) and Python 3. I don't think anybody would object to changing it in Python 4. (Honestly, I would, on the principle above -- it really is only useful if you want to write code in bad style -- but it doesn't take a French soldier on the parapet to let you know in which general direction the wind blows.)

I think that, at some point, it should. If we ever agree on that, then we can start thinking about when.

I really don't think you'll achieve consensus before we start discussing Python 4 seriously. That's when the hunting season on backward incompatible changes (that don't correct showstoppers) opens.

On Thu, Mar 6, 2014 at 3:05 AM, Shai Berger <shai@platonix.com> wrote:

On Wednesday 05 March 2014 17:37:14 Paul Moore wrote:

...

On 5 March 2014 15:19, Shai Berger <shai@platonix.com> wrote:

...

What, other than "bug", do you call behavior that isn't sensible?

"Unfortunate".

That's unfortunate. You miss a lot of bugs.

A bug is something where behaviour differs from documentation or intent. Differing from expectation isn't necessarily a bug (although in the absence of clear docs or statement of intent, it could be called one), partly because expectations vary. When the bulk of programmers expect one thing and the code does another, it's probably a wart or misfeature, but if it's properly documented, it can't really be called a bug. In this case, I would say that it's a wart. The fact that one timestamp happens to be treated as zero is odd, and I wouldn't advocate it, but now that it's there and documented, it's not a bug. ChrisA

On Wed, Mar 5, 2014 at 11:38 AM, Shai Berger <shai@platonix.com> wrote:

So, I rephrase my request: Would anybody object to a silent warning issued whenever a time-object is evaluated as Boolean?

I would. Users should not be penalized for using a documented behavior. There are legitimate uses for bool(midnight) being False. Midnight is special in many contexts. For example, it is uncertain whether midnight belongs to the previous or next day. If your application wants to group midnight differently from other times - it is perfectly fine to use "if dt.time()" instead of a more verbose "if dt.time() != datetime.time(0, 0)".

On 05/03/2014 17:27, Alexander Belopolsky wrote:

On Wed, Mar 5, 2014 at 11:38 AM, Shai Berger <shai@platonix.com <mailto:shai@platonix.com>> wrote:

So, I rephrase my request: Would anybody object to a silent warning issued whenever a time-object is evaluated as Boolean?

I would. Users should not be penalized for using a documented behavior.

We hope that the Python documentation describes the semantics of the language and packages as completely as is reasonably possible. So you are effectively saying that no backwards-incompatible change should ever be made. If we accepted that, this discussion would end now.

There are legitimate uses for bool(midnight) being False. Midnight is special in many contexts. For example, it is uncertain whether midnight belongs to the previous or next day. If your application wants to group midnight differently from other times - it is perfectly fine to use "if dt.time()" instead of a more verbose "if dt.time() != datetime.time(0, 0)".

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

No virus found in this message. Checked by AVG - www.avg.com <http://www.avg.com> Version: 2012.0.2247 / Virus Database: 3705/6655 - Release Date: 03/05/14

[Rob Cliffe <rob.cliffe@btinternet.com>]

We hope that the Python documentation describes the semantics of the language and packages as completely as is reasonably possible. So you are effectively saying that no backwards-incompatible change should ever be made. If we accepted that, this discussion would end now.

There should be a very high bias against changing documented behavior that is in fact working as documented. The document is a contract with users. Contracts shouldn't be violated without truly compelling cause. "I am altering the deal. Pray I don't alter it any further." There's a reason Darth Vader wasn't proclaimed Python's BDFL ;-)

[Donald Stufft]

When the documented behavior is both nonsensical and the cause of hard to debug bugs that is a pretty compelling use case to me, unless you actively enjoy being user hostile.

Breaking code that currently works is as hostile as hostile gets. Where is the evidence that no code relies on the current behavior? For that matter, where is the evidence that the current behavior is a significant cause of bugs? I know I've used "if some_time_object:", but it did exactly what I expected it to do.

Forgive me if I'm wrong, but aren't you the author of the date time module?

Yes.

If that's the case what you expect it to do isn't particularly relevant as you're intimately aware of it's implementation.

Drat! Checkmated again! I get tired of putting smileys after everything ;-)

It's hard to do any sort of search for this, however in an informal poll where I've shown people this code

Precisely which code did you show them? What were the backgrounds of these people? Etc etc etc.

not a single person thought it made sense, and most of them responded with "wtf?"

Which, via amazing coincidence or foresight, is exactly what I bet you were expecting ;-)

. I've also seen first hand through Django (which is why the person who started this thread) get caught by this bug and have to spend hours trying to figure out why it's behaving that way.

Too sketchy to say much about. If this is a variation of testing "if object:" as a shorthand for testing "if object is None:", little sympathy from me. In any case, this took more of my time so far than any possible outcome would be worth to me, so I'll just close with -0 on changing it (would rather not bother, but won't complain if it is changed).

On Thursday 06 March 2014 14:00:02 Steven D'Aprano wrote:

tracking down bugs can be difficult, but if somebody is spending "hours" trying to debug why "if time_value" sometimes does the wrong thing, *without* bothering to read the documentation for time objects to find out how they're supposed to behave, then I don't have a lot of sympathy.

This argument keeps repeating. It is a gross misunderstanding of the problem. The hours are not spent trying to debug why an if went the wrong way. The hours are spent trying to understand why some feature of a program doesn't work as expected -- *sometimes*. It can easily take hours to try and reproduce the wrong behavior, in vain, because it only shows up on unique data; and the wrong behavior will often not show itself as "an if went the wrong way", but, for example, "sometimes a number here is wrong" -- which happens when the calculation of the number goes over a collection of objects and does complex things including decisions based on time. Of course, once you get to the "if" it's relatively easy (surprising behavior is still surprising, but less mystifying). It's getting to it that's the issue. Thanks, Shai.

On 06.03.2014 03:23, Donald Stufft wrote:

On Mar 5, 2014, at 9:15 PM, Tim Peters <tim.peters@gmail.com> wrote:

...

[Donald Stufft]

...

When the documented behavior is both nonsensical and the cause of hard to debug bugs that is a pretty compelling use case to me, unless you actively enjoy being user hostile.

Breaking code that currently works is as hostile as hostile gets. Where is the evidence that no code relies on the current behavior? For that matter, where is the evidence that the current behavior is a significant cause of bugs? I know I've used "if some_time_object:", but it did exactly what I expected it to do.

Forgive me if I’m wrong, but aren’t you the author of the date time module? If that’s the case what you expect it to do isn’t particularly relevant as you’re intimately aware of it’s implementation.

Just in case you're looking for a relevant use case: Having bool(time(0,0,0)) allows you to quickly check whether you are dealing with a datetime value with (non-trivial) time part or not. You run into situations where you have to test for this in date/time conversions, arithmetics, etc. e.g. if you need to convert a datetime value to a date and want to prevent truncation of information, or if you want to format a datetime value in a user friendly way by omitting the zero time part, or if you're doing datetime arithmetic that has to follow special requirements w/r to days (think interest or insurance math) and you want to quickly check whether you can use the fast path simple calculation, or you need to do the full blown complicated part. Now, those use cases may still not appear relevant to you, but then the argument that "if x:" should not trigger for time(0,0,0) because x might actually be None, is also not relevant to me, since it masks a bug in the example code and those should never go undetected :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Mar 6, 2014, at 3:46 AM, Donald Stufft <donald@stufft.io> wrote:

So to be specific, I think using ``if time_or_something_that_may_be_none:`` is always wrong, but I think the like hood for user confusion and hard to reproduce bugs are far greater when a more or less arbitrary time (especially in the sense of aware times) evaluates as false when a user omits the ``is None`` than when someone expects ``if time:`` to be false at midnight.

I realized this was ambiguous, I always consider directly checking the boolean value of a time object as wrong, as I don’t believe time has any True/False implications in it. This includes both using ``if thing:`` to detect None and using ``if thing:`` to detect midnight. I just think the ``if thing:`` to detect None case is more common and also more difficult to detect when you have a bug because of it and more surprising behavior than the other case. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On 06.03.2014 09:46, Donald Stufft wrote:

On Mar 6, 2014, at 3:35 AM, M.-A. Lemburg <mal@egenix.com> wrote:

...

On 06.03.2014 03:23, Donald Stufft wrote:

...

On Mar 5, 2014, at 9:15 PM, Tim Peters <tim.peters@gmail.com> wrote:

...

[Donald Stufft]

...

When the documented behavior is both nonsensical and the cause of hard to debug bugs that is a pretty compelling use case to me, unless you actively enjoy being user hostile.

Breaking code that currently works is as hostile as hostile gets. Where is the evidence that no code relies on the current behavior? For that matter, where is the evidence that the current behavior is a significant cause of bugs? I know I've used "if some_time_object:", but it did exactly what I expected it to do.

Forgive me if I’m wrong, but aren’t you the author of the date time module? If that’s the case what you expect it to do isn’t particularly relevant as you’re intimately aware of it’s implementation.

Just in case you're looking for a relevant use case:

Having bool(time(0,0,0)) allows you to quickly check whether you are dealing with a datetime value with (non-trivial) time part or not.

I don’t see how midnight is any more or less trivial than 12:01.

...

You run into situations where you have to test for this in date/time conversions, arithmetics, etc. e.g. if you need to convert a datetime value to a date and want to prevent truncation of information, or if you want to format a datetime value in a user friendly way by omitting the zero time part, or if you're doing datetime arithmetic that has to follow special requirements w/r to days (think interest or insurance math) and you want to quickly check whether you can use the fast path simple calculation, or you need to do the full blown complicated part.

I think these would be better served by actually checking for what you mean. For the record I also think that checking for a date time to not be None is also better served by actually checking for what you mean. The difference is in intent and likelihood of confusion.

FWIW, I expect bool(time(0,0,0)) == False, just like I expect bool(0.0) == False. I would find it confusing to have bool(zero_element) == True.

For all of those you’re going to be explicitly testing and working with midnight objects, so you’re going to test them, you’re going to exercise that code. In the ``is None`` case, Midnight is just another value so that bug will lay dormant and undetected until someone just happens to hit an unlucky time. And once you get that it’s likely to be difficult to reproduce.

datetime values with zero time are *very* common in practice (you run into them whenever you convert a date value into a datetime value), so the "is None" case is easy to reproduce and will hit you more often than you like. BTW: Not using "is None" will bite you in many other ways as well. None it typically used as value for "not initialized" or "no value provided". This meaning is completely different from "empty selection" or "empty string", so in order to address all those cases as well, you'd have to change: bool(()) == True bool('') == True etc. The "if x is None:" test is also faster than "if x:", so actually win something by coding correctly ;-) Please provide a stronger argument for needing to change bool(time(0,0,0)) than one which is built on buggy code :-) (I'm running out of smileys...) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

I feel zero value of non abelian group should not mean False in bool context. () + () == () "" + "" == "" 0 + 0 == 0 timedelta() + timedelta() == timedelta() time() + time() => TypeError On Thu, Mar 6, 2014 at 6:32 PM, M.-A. Lemburg <mal@egenix.com> wrote:

On 06.03.2014 09:46, Donald Stufft wrote:

...

On Mar 6, 2014, at 3:35 AM, M.-A. Lemburg <mal@egenix.com> wrote:

...

On 06.03.2014 03:23, Donald Stufft wrote:

...

On Mar 5, 2014, at 9:15 PM, Tim Peters <tim.peters@gmail.com> wrote:

...

[Donald Stufft]

...

When the documented behavior is both nonsensical and the cause of hard to debug bugs that is a pretty compelling use case to me, unless you actively enjoy being user hostile.

Breaking code that currently works is as hostile as hostile gets. Where is the evidence that no code relies on the current behavior? For that matter, where is the evidence that the current behavior is a significant cause of bugs? I know I've used "if some_time_object:", but it did exactly what I expected it to do.

Forgive me if I'm wrong, but aren't you the author of the date time module? If that's the case what you expect it to do isn't particularly relevant as you're intimately aware of it's implementation.

Just in case you're looking for a relevant use case:

Having bool(time(0,0,0)) allows you to quickly check whether you are dealing with a datetime value with (non-trivial) time part or not.

I don't see how midnight is any more or less trivial than 12:01.

...

You run into situations where you have to test for this in date/time conversions, arithmetics, etc. e.g. if you need to convert a datetime value to a date and want to prevent truncation of information, or if you want to format a datetime value in a user friendly way by omitting the zero time part, or if you're doing datetime arithmetic that has to follow special requirements w/r to days (think interest or insurance math) and you want to quickly check whether you can use the fast path simple calculation, or you need to do the full blown complicated part.

I think these would be better served by actually checking for what you mean. For the record I also think that checking for a date time to not be None is also better served by actually checking for what you mean. The difference is in intent and likelihood of confusion.

FWIW, I expect bool(time(0,0,0)) == False, just like I expect bool(0.0) == False. I would find it confusing to have bool(zero_element) == True.

...

For all of those you're going to be explicitly testing and working with midnight objects, so you're going to test them, you're going to exercise that code. In the ``is None`` case, Midnight is just another value so that bug will lay dormant and undetected until someone just happens to hit an unlucky time. And once you get that it's likely to be difficult to reproduce.

datetime values with zero time are *very* common in practice (you run into them whenever you convert a date value into a datetime value), so the "is None" case is easy to reproduce and will hit you more often than you like.

BTW: Not using "is None" will bite you in many other ways as well. None it typically used as value for "not initialized" or "no value provided". This meaning is completely different from "empty selection" or "empty string", so in order to address all those cases as well, you'd have to change:

bool(()) == True bool('') == True etc.

The "if x is None:" test is also faster than "if x:", so actually win something by coding correctly ;-)

Please provide a stronger argument for needing to change bool(time(0,0,0)) than one which is built on buggy code :-) (I'm running out of smileys...)

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Mar 06 2014)

...

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

---

2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- INADA Naoki <songofacandy@gmail.com>

On 06.03.2014 10:52, Antoine Pitrou wrote:

Le 06/03/2014 09:35, M.-A. Lemburg a écrit :

...

Just in case you're looking for a relevant use case:

Having bool(time(0,0,0)) allows you to quickly check whether you are dealing with a datetime value with (non-trivial) time part or not.

This sounds like the kind of shortcut that only an expert would know to take, not something that's actually a good design decision. It's as though pathlib.Path('') evaluated to false for some obscure use case that I cared about.

It doesn't ? :-)

It is not a coincidence, IMO, that the three persons arguing that the current behaviour is reasonable are implementors of datetime modules: you, Tim and Alexander. All other people find the behaviour baffling.

I'm not so sure. Of course, people who have been doing date/time stuff will jump into discussions that deal with them, but the same argument triggering this thread could have applied to other Python types and you would then have a different group of people argue for plausibility of the choice. I find it strange that the only argument against having time(0,0,0) evaluate to False in a boolean context is a wrongly used None test. This argument can be applied to lots of other types as well, where the buggy None test masks errors. Perhaps someone could present at least one compelling argument that is not based on wrong usage of None in if statements. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On 06.03.2014 11:46, Antoine Pitrou wrote:

Le 06/03/2014 11:33, M.-A. Lemburg a écrit :

...

I find it strange that the only argument against having time(0,0,0) evaluate to False in a boolean context is a wrongly used None test.

It's only "wrongly used" because of that particular wart. In other words, the "wrongly used" None test *exposes* the wart, it is not its *cause*.

Wait. Let's be clear on this: Writing if x: print ('x is None') or if x == None: print ('x is None') is wrong code. None is a singleton, so you have to use the "is" operator, i.e. if x is None: print ('x is None') is the only correct way of testing for None. Adding a test to pylint for this would probably be more helpful and address the real problem in a more productive way, than the current discussion to making the above problematic code work in the single use case of x being a datetime.time object.

There are other contexts with implicit boolean conversion, such as any() and all().

If you expect those to work correctly for None testing, then you're writing wrong code as well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On 06.03.2014 12:09, Antoine Pitrou wrote:

Le 06/03/2014 12:04, M.-A. Lemburg a écrit :

...

Writing

if x: print ('x is None')

or

if x == None: print ('x is None')

is wrong code.

No it isn't.

...

None is a singleton, so you have to use the "is" operator, i.e.

if x is None: print ('x is None')

is the only correct way of testing for None.

No it isn't. x == None is a perfectly well-defined way of doing it, even if it isn't the stylistically preferred one.

Depends on what kind of type x is and how that type implements the comparison slots. It is perfectly well possible to define a type that returns True for (x == None), even though x is not None :-)

...

...

class C: ... def __eq__(self, other): ... return (other is None) ... o = C() o == None True

-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On 6 March 2014 21:04, M.-A. Lemburg <mal@egenix.com> wrote:

Wait. Let's be clear on this:

Writing

if x: print ('x is None')

or

if x == None: print ('x is None')

The case in question is essentially this one: if x: assert x is not None # Always valid! .... else: assert x is None # Valid for most user defined types There is a learned intuition that people naturally acquire when learning Python: - numbers may be false (it means zero) - containers may be false (it means empty) - everything else is always true (as that's the default for user defined classes) Where datetime().time() is confusing is the fact the expected behaviour changes based on *which* category you put the number in. The vast majority of Python's users will place structured date and time objects in the "arbitrary object" category, and expect them to always be true. When using None as a sentinel for such types, writing "if x:" when you really mean "if x is not None:" is a harmless style error, with no practical ill-effects. When dealing with time objects, such users are unlikely to be crafting test cases to ensure that "midnight UTC" is handled correctly, so their "harmless style error" is in fact a subtle data driven bug waiting to bite them. It is *really* hard for a static analyser to pick this up, because at point of use "if x:" gives no information about the type of "x", and hence any such alert would have an unacceptably high false positive rate. Now, let's consider the time with the *best* possible claim to being false: timestamp zero. How does that behave? Python 3.3:

...

...

bool(dt.datetime.fromtimestamp(0)) True bool(dt.datetime.fromtimestamp(0).date()) True bool(dt.datetime.fromtimestamp(0).time()) True

Huh, if times are supposed to be valid as truth values, that looks rather weird. What's going on?

...

...

dt.datetime.fromtimestamp(0).time() datetime.time(10, 0)

Oh, I'm in Brisbane - *of course* the truthiness of timestamps should depend on my timezone! Clearly, what I really meant was timestamp -36000, or perhaps 50400:

...

...

bool(dt.datetime.fromtimestamp(-36000).time()) False bool(dt.datetime.fromtimestamp(50400).time()) False

So, unless I happen to live in UTC, it's highly unlikely that I'm going to infer from Python's *behaviour* that datetime.time() (unlike datetime.date() and datetime.datetime()) belong in the "number" category, rather than the "arbitrary object" category. Perhaps it behaves like a number in other ways:

...

...

utcmidnight = dt.datetime.fromtimestamp(50400).time() utcmidnight + 1 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'datetime.time' and 'int' utcmidnight * 1 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for *: 'datetime.time' and 'int' int(utcmidnight) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: int() argument must be a string or a number, not 'datetime.time'

Hmm, nope. And that last one *explicitly* tells me it's not a number! There's a great saying in the usability world: "You can't document your way out of a usability problem". What it means is that if all the affordances of your application (or programming language!) push users towards a particular logical conclusion (in this case, "datetime.time values are not numbers"), having a caveat in your documentation isn't going to help, because people aren't even going to think to ask the question. It doesn't matter if you originally had a good reason for the behaviour, you've ended up in a place where your behaviour is confusing and inconsistent, because there is one piece of behaviour that is out of line with an otherwise consistent mental model. But perhaps I've been told "midnight is false in boolean context". But which midnight? There are three that apply to me:

...

...

naivemidnight datetime.time(0, 0) utcmidnight datetime.time(0, 0, tzinfo=datetime.timezone.utc) localmidnight datetime.time(0, 0, tzinfo=datetime.timezone(datetime.timedelta(0, 36000)))

Are they all False? No, no they're not (unless your local timezone is UTC):

...

...

bool(utcmidnight) False bool(naivemidnight) False bool(localmidnight) True

There's a phrase for APIs like this one: "expert friendly". Experts like a particular behaviour because it lets them do advanced things (like leave the door open for modular arithmetic on timestamp.time() values). However, that's not normally something we see as a virtue when designing APIs for Python - instead, we generally aim for layered complexity, where simple things are simple, and we provide power tools for advanced users that want them. Now, suppose this boolean behaviour went away. How would I detect if a value was midnight or not? Well, first, I would need to clarify my question. Do I mean midnight UTC? Or do I mean midnight local time? It makes a difference for aware objects, after all. Or perhaps I'm not interested in aware objects at all, and only care about naive midnight. Using appropriately named values like those I defined above, those questions are all very easy to express explicitly in ways that don't rely on readers understanding that "bool(x)" on a datetime.time object means the same thing as "x is naive midnight or UTC midnight": if x not in (naivemidnight, utcmidnight): # This is the current bool(x) .... if x != naivemidnight: # This has no current shorthand .... if x != utcmidnight: # This has no current shorthand .... if x != localmidnight: # This has no current shorthand .... And just to demonstrate that equivalence is accurate:

...

...

local_10am = localmidnight.replace(hour=10) local_10am datetime.time(10, 0, tzinfo=datetime.timezone(datetime.timedelta(0, 36000))) bool(local_10am) False local_10am != utcmidnight False local_10am not in (naivemidnight, utcmidnight) False

While it was originally the desire to reduce the impact of a very common bug that prompted me to reopen the issue, it is the improved consistency in the behaviour presented to users of Python 3.6+ that makes me belief this is actually worth fixing. We embarked on the whole Python 3 exercise in the name of making the language easier to learn by removing legacy features and fixing some problematic defaults and design warts - this is a tiny tweak by comparison, and will still go through the full normal deprecation cycle (warning in 3.5, behavioural change in 3.6) Regards, Nick.

On Mar 6, 2014, at 8:21 AM, M.-A. Lemburg <mal@egenix.com> wrote:

On 06.03.2014 13:08, Nick Coghlan wrote:

...

But perhaps I've been told "midnight is false in boolean context". But which midnight? There are three that apply to me:

...

...

...

naivemidnight datetime.time(0, 0) utcmidnight datetime.time(0, 0, tzinfo=datetime.timezone.utc) localmidnight datetime.time(0, 0, tzinfo=datetime.timezone(datetime.timedelta(0, 36000)))

Are they all False? No, no they're not (unless your local timezone is UTC):

...

...

...

bool(utcmidnight) False bool(naivemidnight) False bool(localmidnight) True

Now this is a what I consider a valid argument for making a change.

Thanks, Nick.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Mar 06 2014)

...

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

---

2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Yea Nick put into words what I’ve been attempting to say better than I ever could have :) ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Le 06/03/2014 15:33, Stephen J. Turnbull a écrit :

I don't care if the change is made, but I hope it will be made absolutely clear that it's purely to work around *old* bugs that may never get fixed, and that "if var:" which is actually testing for identity with a false-y sentinel is still strongly discouraged.

Why "strongly discouraged"? This is more of a style issue than anything else? Regards Antoine.

On Mar 07, 2014, at 02:40 AM, Stephen J. Turnbull wrote:

I also value the psychological benefit of being precise here. I'm not even sure it's possible to fool 'is' into thinking some other object is None, but people do a great job of convincing themselves of things like "datetime.time objects can't be false" all the time. Use the "is None" idiom and you know exactly what you're doing. This latter is close to "just style", of course.

Not just "you" (i.e. the author of the code), but everyone who comes after you and reads it. Being more explicit with identity tests against None assists future minions in understanding the intent of the code. When using the Socratic Method Of Code Reviews, I always ask about whether the author really expects the 'var' in "if var:" to be any truth-y value. The answer is usually "no", in which case I encourage tightening up the conditional. There are valid cases where a test is really trying to catch any truth-y or false-y value. I usually encourage a comment to clarify the author's intent in those cases. -Barry

On 03/06/2014 09:40 AM, Stephen J. Turnbull wrote:

Antoine Pitrou writes:

...

Le 06/03/2014 15:33, Stephen J. Turnbull a écrit :

...

...

never get fixed, and that "if var:" which is actually testing for identity with a false-y sentinel is still strongly discouraged.

Why "strongly discouraged"? This is more of a style issue than anything else?

No, it's not just a style issue. As Skip points out, it's a *semantic* issue as well.

Indeed, I have been bitten by using the lazy method of `if var` instead of `if var is not None`, and then been briefly puzzled as why my empty string | container | whatever that I passed in did not give me the correct results. I'm still all for having truthy midnights. :) -- ~Ethan~

On 03/06/2014 08:13 AM, Alexander Belopolsky wrote:

On Thu, Mar 6, 2014 at 8:21 AM, M.-A. Lemburg <mal@egenix.com <mailto:mal@egenix.com>> wrote:

> Are they all False? No, no they're not (unless your local timezone is UTC): > >>>> bool(utcmidnight) > False >>>> bool(naivemidnight) > False >>>> bool(localmidnight) > True

Now this is a what I consider a valid argument for making a change.

FWIW, I would be +0 for making a change so that t.tzinfo is not None implies bool(t.timetz()) is True.

My intuition goes like this. Given

...

...

...

from datetime import * t1 = datetime(2014, 1, 1) t2 = datetime(2014, 1, 1, 12) t3 = datetime(2014, 1, 1, tzinfo=timezone.utc)

Instance t1 has no time information, so t1.time() is false-y.

If datetime actually worked like that I would agree with you; but it doesn't -- it says you have the time of midnight on 2014, 1, 1, not that you don't have a time at all. -- ~Ethan~

On Thu, Mar 6, 2014 at 12:08 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

Now, let's consider the time with the *best* possible claim to being false: timestamp zero. How does that behave?

[... snipped ...]

So, unless I happen to live in UTC, it's highly unlikely that I'm going to infer from Python's *behaviour* that datetime.time() (unlike datetime.date() and datetime.datetime()) belong in the "number" category, rather than the "arbitrary object" category.

This one's even *more* fun if you live in the UK. I live on the Greenwich Meridian (and I mean that quite literally: it goes through the middle of my living room), and since the epoch was in January, well away from British Summer Time, I shouldn't see any of those pesky timezone-related problems that those poor underprivileged people living in non-UTC timezones see. Right? Here's Python 2.7 on my Mac laptop, whose timezone is set to London time:

...

...

import datetime as dt bool(dt.datetime.fromtimestamp(0).time()) True

And on Windows (again with timezone set to the UK):

...

...

import datetime as dt bool(dt.datetime.fromtimestamp(0).time()) False

Wait, what? It turns out that in January 1970, the UK government was in the middle of an experimental change to a year-round GMT+1 timezone. Some operating systems seem to be aware of that fact; some aren't. Count me in the bool(time(0)) should be True camp, by the way. -- Mark

On 06/03/2014 10:57, Paul Moore wrote:

I had promised to stay out of this discussion as I no longer thing it adds much value (note that the bug has been reopened long since) and I was getting tired of having people decide that I'd said something I didn't mean.

But just to add a perspective from someone who *doesn't* develop a datetime module, I encounter "special" midnight values very often. Databases (at least Oracle, and I believe others) typically store date values ("Thursday 6th March 2014") as a timestamp value with midnight as a time part. So checking the time part of a datetime value for midnight as a "special, means omitted" value is not uncommon in that domain.

Paul

You're joking, right? How do you distinguish "omitted" from "provided, equals midnight" ? Rob Cliffe

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2247 / Virus Database: 3705/6655 - Release Date: 03/05/14

Antoine Pitrou <solipsis@...> writes:

Le 06/03/2014 09:35, M.-A. Lemburg a écrit :

...

Just in case you're looking for a relevant use case:

Having bool(time(0,0,0)) allows you to quickly check whether you are dealing with a datetime value with (non-trivial) time part or not.

This sounds like the kind of shortcut that only an expert would know to take, not something that's actually a good design decision. It's as though pathlib.Path('') evaluated to false for some obscure use case that I cared about.

On the other hand I would not dare to assume it's True without checking.

It is not a coincidence, IMO, that the three persons arguing that the current behaviour is reasonable are implementors of datetime modules: you, Tim and Alexander. All other people find the behaviour baffling.

Not all. :) I think viewing midnight as (unix_time % 86400) is quite reasonable. Stefan Krah

Andrew Barnert wrote:

I agree with Stefan here. Treating midnight as zero is not at all baffling. There's a reason modular arithmetic is taught to kids as "clock arithmetic",

I still say this is confusing times with timedeltas. It makes no conceptual sense to add two times of day together. You can only make it work if you abuse one type to mean two different things. We keep datetimes and timedeltas clearly separated. Why shouldn't we do the same for times of day? -- Greg

On 3/6/2014 4:52 AM, Antoine Pitrou wrote:

It is not a coincidence, IMO, that the three persons arguing that the current behaviour is reasonable are implementors of datetime modules: you, Tim and Alexander. All other people find the behaviour baffling.

Wrong. I don't. What I find baffling and annoying is the endlessly repeated false claim that there is nothing special about midnight, as if a thousands repetitions will change the fact. Ditto for the claim that there is nothing problematical about using 'a' as a substitute for 'a is not None'. Surely you know that the subset of people who pay attention to an endless drumbeat thread like this is severely biased. -- Terry Jan Reedy

[Greg Ewing]

... Altogether, the whole thing seems to be a mess.

Although a mess that fits in a thimble that successfully hid in a dark corner unnoticed for a decade ;-)

On 03/06/2014 04:08 PM, Tim Peters wrote:

[Greg Ewing]

...

... Altogether, the whole thing seems to be a mess.

Although a mess that fits in a thimble that successfully hid in a dark corner unnoticed for a decade ;-)

If the decade is now, it didn't go that long. I discovered this irritation within a year of learning Python, and at least three years ago brought it up on one of the mailing lists. I ended up making my own Date, Time, and DateTime classes. -- ~Ethan~

Le 06/03/2014 03:15, Tim Peters a écrit :

[Donald Stufft]

...

When the documented behavior is both nonsensical and the cause of hard to debug bugs that is a pretty compelling use case to me, unless you actively enjoy being user hostile.

Breaking code that currently works is as hostile as hostile gets. Where is the evidence that no code relies on the current behavior? For that matter, where is the evidence that the current behavior is a significant cause of bugs? I know I've used "if some_time_object:", but it did exactly what I expected it to do.

The current behaviour being highly unintuitive is a likely source of bugs, IMO. Regards Antoine.

On Mar 06, 2014, at 11:56 AM, Rob Cliffe wrote:

Instances of existing code that would be broken by the change: 0

You can't know this because you can't audit all the Python code in the world. -Barry

On 06/03/2014 23:51, Greg Ewing wrote:

Barry Warsaw wrote:

...

On Mar 06, 2014, at 11:56 AM, Rob Cliffe wrote:

...

Instances of existing code that would be broken by the change: 0

You can't know this because you can't audit all the Python code in the world.

I think he means instances that have been pointed out so far in this discussion.

Quite. If you read my post, I was initialising totals. I invited the universe to add to them.

On 07/03/2014 03:58, Stephen J. Turnbull wrote:

Greg Ewing writes:

...

Barry Warsaw wrote:

...

On Mar 06, 2014, at 11:56 AM, Rob Cliffe wrote:

...

Instances of existing code that would be broken by the change: 0

You can't know this because you can't audit all the Python code in the world.

I think he means instances that have been pointed out so far in this discussion.

Well, either way it's a pretty careless claim.

Please read what I actually said: Let's _start_ a survey.

If I had to do it over again I would *definitely* never make a time value "falsy". The datetime module was conceived long ago, when the dangers of falsy objects that weren't clearly trying to be "like numbers" or "like collections" weren't so clear. Today I would argue that times aren't enough "like numbers" to qualify. The only question left in my mind is how safe it is to change the current behavior, given that it's been documented and implemented for over a decade. If this was for Python 3.0 (or even 3.1) I would definitely vote for fixing it, damn the torpedoes. But given that we're talking about 3.5, I'm more hesitant. It's also not something for which a deprecation warning would work well. (When would it be issued? Whenever bool(<time>) is called? Or only when it's about to return False?) Still, my intuition tells me that it's pretty much a nuisance feature and few people have actually relied on it, so I'd be okay with fixing (and breaking!) this in 3.5, perhaps after a thorough search for how much the feature is actually relied upon and how legitimate or important those uses are. A search should *also* try to unearth code that is technically *broken* by the current behavior. I would expect there to be quite a lot of the latter kind, and very few of the former. Fearing I have said nothing new, -- --Guido van Rossum (python.org/~guido)

Guido van Rossum writes:

It's also not something for which a deprecation warning would work well. (When would it be issued? Whenever bool(<time>) is called?

Yes! Yes! Yes! Just joking -- that's got to be the wrong thing to do, because it would warn on precisely the construct (None as sentinel for "uninitialized") that's the only reason anybody wants this.

Or only when it's about to return False?)

That seems reasonable to me. People who are testing for this are presumably *constructing* instances of midnight, either with a crontab of "* * * * *" or in a simulation -- they'll hit it frequently. The other case that seems plausible is using a zero time as a sentinel for "uninitialized" or "unspecified", and that *must* get a warning.

Fearing I have said nothing new,

IIRC, you're the only person to have mentioned the pragmatic issues about the DeprecationWarning.

On Fri, Mar 7, 2014 at 4:48 PM, Donald Stufft <donald@stufft.io> wrote:

On Mar 7, 2014, at 12:17 PM, Guido van Rossum <guido@python.org> wrote:

If I had to do it over again I would *definitely* never make a time value "falsy". The datetime module was conceived long ago, when the dangers of falsy objects that weren't clearly trying to be "like numbers" or "like collections" weren't so clear. Today I would argue that times aren't enough "like numbers" to qualify.

The only question left in my mind is how safe it is to change the current behavior, given that it's been documented and implemented for over a decade. If this was for Python 3.0 (or even 3.1) I would definitely vote for fixing it, damn the torpedoes. But given that we're talking about 3.5, I'm more hesitant. It's also not something for which a deprecation warning would work well. (When would it be issued? Whenever bool(<time>) is called? Or only when it's about to return False?)

Still, my intuition tells me that it's pretty much a nuisance feature and few people have actually relied on it, so I'd be okay with fixing (and breaking!) this in 3.5, perhaps after a thorough search for how much the feature is actually relied upon and how legitimate or important those uses are. A search should *also* try to unearth code that is technically *broken* by the current behavior. I would expect there to be quite a lot of the latter kind, and very few of the former.

Hrm, I'm not actually sure how to even achieve such a search. Due to Python's dynamic nature it's pretty hard to determine what type is being used in a boolean expression, if that data is even available (It could be coming from a database or some other data source).

Do you have any idea how to do such a search?

I know someone at Sourcegraph who thinks he knows how to modify Sourcegraph to do it. -- --Guido van Rossum (python.org/~guido)

Paul Moore wrote:

"""in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that's None), the result is non-zero."""

Aaaaargh... I didn't know this had since been documented. Wy opinion still stands -- documenting this was the wrong thing to do. I hope it can still be fixed. -- Greg

On 05/03/2014 15:19, Shai Berger wrote:

On Wednesday 05 March 2014 17:01:33 you wrote:

...

On 5 March 2014 13:53, Shai Berger <shai@platonix.com> wrote:

...

...

Again, I'm not saying the current behaviour is sensible, but I doubt the work to fix it will benefit anyone in practice.

[...]

...

In any case, if we all agree that http://bugs.python.org/issue13936 is a valid problem

We don't. Can we agree that it's not a bug and abandon this fruitless discussion?

What, other than "bug", do you call behavior that isn't sensible?

Documented behaviour. As opposed to insanity: doing the same thing over and over again and expecting different results. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

Oscar Benjamin wrote:

The question is surely whether the issue is worth a backwards compatibility break not whether the current behaviour is a good idea (it clearly isn't).

The currrent behaviour is sufficiently useless that it seems unlikely there would be much code out there relying on it. -- Greg

On 5 March 2014 15:34, Skip Montanaro <skip@pobox.com> wrote:

On Wed, Mar 5, 2014 at 4:44 AM, Paul Moore <p.f.moore@gmail.com> wrote:

...

...

if event.start_time: # stuff

unexpectedly fails if start_time is midnight.

Yeah, I was classing that as "application bug" and it's easy to fix with an "is not None".

+1, +1, +1. This is nothing more than an application bug. Issue 13936 should not be reopened.

This is a very common mistake when None is used as a sentinel value (though people normally get away with it), especially by people coming from languages having NULL pointers which shall not be named. After all, "None" and "NULL" both start with the letter "N". Surely, they must represent the same fundamental concept, right? <wink>

Let's change the problem slightly. Instead of time objects, let's consider the domain of possible values to be integers. Clearly, None is not a member of that set. You could thus use it as a sentinel. So, tell me, OP. Would this usage be correct?

if event.some_id: # stuff

I would argue, "no." I would not argue that 0 should not compare as False, however.

You come up with an instance where 0 clearly does not apply as something to incur a different branch, which is very apparent in just reading the line, so very easy to spot as a mistake. But this 0 isn't a real zero. It's just a unique identifier that happens to be implemented as an integer(because it's convenient for your database, iterators and whatnot.) Let me show you an actual zero: if event.num_attendants: prepare_cake() else: cancel_event() When no one is coming to your party, is is clearly a different condition than if any number of people are coming to your event. When you read "if num_attendants", you can clearly tell this is going to do something depending on if people are coming or not. Let's read this line: if not event.date: How would you read it, knowing nothing about date objects? I would read it to mean "has no date been set?" and would naturally continue the code as such: if event.date: schedule_event() I cannot fathom one example where it could read as "does the party start at midnight?". Can you?

On Wed, Mar 5, 2014 at 9:42 AM, Paul Moore <p.f.moore@gmail.com> wrote:

On 5 March 2014 15:08, Yann Kaiser <kaiser.yann@gmail.com> wrote:

...

Let me show you an actual zero:

if event.num_attendants: prepare_cake() else: cancel_event()

When no one is coming to your party, is is clearly a different condition than if any number of people are coming to your event. When you read "if num_attendants", you can clearly tell this is going to do something depending on if people are coming or not.

I'm sorry, are you really trying to say that the above code is better than

if event.num_attendants != 0: prepare_cake() else: cancel_event()

?

(Personally, I'd actually prefer something like "if event.num_attendants > 0" or switch the order of clauses and test for being equal to 0, but that's a minor issue. The major point is I'd prefer any of these to your version).

I suspect you'd like the whole idea of empty collections and zeroes evaluating false to go away, to force this kind of style (one right way to do it and all). Some languages do that. Python isn't one of them. I can see both sides, but I like how Python can use empty lists and zeros as false values, and I often (but not always) write code that takes advantage of it.

On Wed, Mar 5, 2014 at 10:24 AM, Paul Moore <p.f.moore@gmail.com> wrote:

PS One final point, and I'll say this one last time and then shut up. I have no objection to making Python better. Nor do I insist that backward compatibility should never be broken. Nor do I wish Python were Java. Nor do I discount the issue of hard to find bugs. But equally, I don't think Python is perfect, nor do I think that this behaviour is ideal. I also don't think that the core developers have infinite time, nor do I think that every wart in Python needs to be fixed. And I trust the core developers to make the right judgements most of the time. All anyone should infer from this discussion is that I don't think that reopening the bug report referred to by the OP is productive. (You may also assume from the fact that I will drop out of this discussion now, that I no longer think that this thread is particularly productive :-()

Thanks for bringing this up. Even assuming that this was accepted as a bug, it's an entirely separate discussion to decide whether worth fixing or if it's worth the dev's time. I make no assertion on that, as that's their time and not mine. I hold the developers with highest regard, even in my disagreement. Python is my language of choice because of the effort of these folks, and I thank them. This seems like it could be a simple enough bug that were it allowed, it would be a fix that even someone as inexperienced with Python's internals as myself could fix. If that's not true and the issue is that it's simply too much work to change, then it should be marked "wontfix" rather than "invalid", and that's a decision that I would not contest (at least not without a working patch). I, like you, suspect that I will be abandoning further involvement, as simply arguing won't change people's minds.

On Thu, Mar 6, 2014 at 2:55 AM, Ryan Hiebert <ryan@ryanhiebert.com> wrote:

I suspect you'd like the whole idea of empty collections and zeroes evaluating false to go away, to force this kind of style (one right way to do it and all). Some languages do that. Python isn't one of them.

I can see both sides, but I like how Python can use empty lists and zeros as false values, and I often (but not always) write code that takes advantage of it.

The broad concept is: A thing is true, a non-thing is false. The question is, though, which things are actually non-things? Since Python doesn't have a concept of not storing anything into a variable, there has to be a thing that represents the state of not being a thing, so None should be false. Python's made the choice that an empty string is a non-thing, but other languages choose instead to have a separate "Nil" value and all strings are true. Same with lists, tuples, etc. Pike's choice is that the integer 0 is false, and anything else is true, so you distinguish between having a string and not-having a string, rather than between having a non-empty string and having an empty string. Simple design choice, and one that each language follows consistently. But if you truly want to abolish the confusion, you want REXX. In REXX, 0 is false and 1 is true, and everything else is error 34, "Logical value not 0 or 1". Is that really an improvement? Not in my opinion. ChrisA

The obvious solution is just to fix the Python if statement to remove implicit bool coercion. So they would all evaluate to if isinstance (x, bool) and x. Problem solved. On Mar 6, 2014 5:27 PM, "Ethan Furman" <ethan@stoneleaf.us> wrote:

On 03/05/2014 07:42 AM, Paul Moore wrote:

...

On 5 March 2014 15:08, Yann Kaiser <kaiser.yann@gmail.com> wrote:

...

Let me show you an actual zero:

if event.num_attendants: prepare_cake() else: cancel_event()

When no one is coming to your party, is is clearly a different condition than if any number of people are coming to your event. When you read "if num_attendants", you can clearly tell this is going to do something depending on if people are coming or not.

I'm sorry, are you really trying to say that the above code is better than

if event.num_attendants != 0: prepare_cake() else: cancel_event()

?

Yes. This is Python. blah blah blah != 0 is unnecessary boiler-plate [1].

-- ~Ethan~

[1] In most cases. I have used `== 0` or `!= 0` when it makes the code clearer, but that's pretty rare.

-- ~Ethan~ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Yann Kaiser writes:

if event.date: schedule_event()

I cannot fathom one example where it could read as "does the party start at midnight?". Can you?

No, because it obviously reads as "... WTF??!?"[1] Of course, that's because I've imbibed of the "Python is not C or C++" Kool-Aid, but I just don't see why we should encourage C idioms in Python when there are plenty of other cases where use of a bare expression rather "... is None" can bite. I find Skip Montanaro's implied issue Please reconsider the Boolean evaluation of None far more plausible.<wink/> Footnotes: [1] if event.date: print("Happy New Year/Century/Millennium!")

On Wed, Mar 5, 2014 at 9:15 AM, Shai Berger <shai@platonix.com> wrote:

Also, when opening this thread, I argued that 0 is special, but midnight is not -- which you completely ignore.

Zero is not different, at least when considered as an element of a set (of integers, in my example). What's important is that we have a set of values (either time objects or integers in these two examples) and need some way to specify a sentinel value. That sentinel must not be in the set of valid values. In both of these cases, None fills the bill. Note that the only reasonable relationship between None and either the set of all time objects or the set of all integers is that it is not a member of either set. Testing that membership by appealing to their value cast to a boolean is simply wrong. I'll push the argument just a bit further. Suppose you have an attribute which corresponds to the setting of a two-valued sensor external to your system. You choose to represent those two values in your program as True and False. You need a way to tell if any sensor inputs have been detected yet, or not, so you initialize the attribute with a sentinel value. I don't care what value you choose out of all the possible sentinel values available to you (None, [], ["xyz"], {}, 7, 0.0, etc), treating any of them as a boolean will be wrong. If you do, you will erroneously always believe that your sensor has produced a value. I have made this sort of mistake many times over the years, and seen other people do it as well. If what you really want to test is membership of a value in a set, be explicit about it. Skip

On Wed, Mar 5, 2014 at 11:24 AM, Shai Berger <shai@platonix.com> wrote:

If your argument is not that "if obj:" should never be used, except when obj actually is Boolean, please elaborate.

My approach continues to be to consider the overall set of objects from which you draw values to assign to obj. Call that set V. If this expression is true: len([bool(x) for x in V]) == 1 then using "if obj:" might be valid (if the one "false" value of that set is some sort of distinguishing characteristic, as it often is). If, however, the length of that set is greater than one, you must be explicit in your conditional expressions. It is unfortunate for your purposes that bool(datetime.time(0, 0, 0)) is False, but it's a documented property of that object, and is highly unlikely to change. In your case V is None plus the set of all time objects. That has two values which evaluate to False, so "if obj:" is not appropriate. If, on the other hand, the set of all values is the set of all strings or the set of all integers or the set of all lists, then maybe the falsity of the zero values in those sets ("", 0, []) has some use. My last comment on this topic. I will invoke the Uncle Timmy rule (which I just made up). Never contradict a decision Uncle Timmy made. He had his reasons. They were very good reasons. They were almost certainly better than any reasons you can come up with as counterarguments. Deal with it. :-) Skip

On Wed, Mar 05, 2014 at 08:44:55PM +0200, Shai Berger wrote:

...

It is unfortunate for your purposes that bool(datetime.time(0, 0, 0)) is False, but it's a documented property of that object, and is highly unlikely to change.

I think this is what's called 'begging the question' -- this discussion was not about the validity of boolean testing in general, but about the validity of this property of time objects. Yes, it's documented. I'm trying to make it change. There is a lot of support for that, and the opposition seems to be centered on "because it's documented" -- with the two exceptions being an edge use-case (actually checking midnight) and your call to authority below.

There are some very powerful practical reasons for leaving the status quo, namely backwards-compatibility and code-churn. These are real costs, not for the person who writes the patch, or the people who write the tests, and document the change. But these are potential costs for the millions of people using Python who may be *relying* on midnight being falsey, or nevertheless will have to change their code if this change occurs. There's also the argument from consistency: midnight is the zero point of the day, and zero is falsey. It would be surprising if something which is essentially zero became truthy. Compared to those costs, the benefits are insignificant. For library authors, they cannot take advantage of this new always-truthy time objects for probably eight or ten years, when they drop all support for any prior to 3.6 or 3.7. A tiny benefit, discounted even further because it is so far in the distance, versus significant costs. Application authors, only using a single version of Python, may be able to make use of this rather sooner: perhaps as little as three years from now.

It's a gotcha. Let's remove it. If we don't remove it, let's give ourselves a tool to detect it.

Um, it's easy to detect it. not time_obj returns True if time_obj is midnight and therefore falsey. -- Steven

[Bruce Leban]

And the documentation is not exactly clear for understanding when a time object is falsey. In particular, the "converting it to minutes" part seems irrelevant

That's there because `utcoffset()` is defined to return minutes. A rule is needed to specify how the naive time object and `utcoffset()` interact to define the result.

as a time of 1 microsecond from midnight is truthy and timedeltas are not numbers and are not in minutes

timedeltas have nothing to do with this. The docs could be expanded to specify precisely how the naive time object is converted to minutes, but I think that's so obvious it would just be tedious to do so.

Perhaps a reasonable improvement would be to change this to:

a time object is considered to be true unless it represents exactly midnight local time, that is, it's false if subtracting the utcoffset() from the time produces an all-zero result (or it's all-zero to start with if the utcoffset is None).

You still need a rule to define _how_ "subtracting the utcoffset() from the time" is intended to work, since arithmetic on naive time objects is not defined. Add "convert it to minutes" ;-)

On Wed, Mar 5, 2014 at 5:53 PM, Tim Peters <tim.peters@gmail.com> wrote:

That's there because `utcoffset()` is defined to return minutes.

It returns either minutes *or a timedelta*: datetime.utcoffset()¶<http://docs.python.org/2/library/datetime.html#datetime.datetime.utcoffset> If tzinfo <http://docs.python.org/2/library/datetime.html#datetime.tzinfo> is None, returns None, else returns self.tzinfo.utcoffset(self), and raises an exception if the latter doesn't return None, or a timedelta<http://docs.python.org/2/library/datetime.html#datetime.timedelta> object representing a whole number of minutes with magnitude less than one day. tzinfo.utcoffset(*self*, *dt*) Return offset of local time from UTC, in minutes east of UTC. If local time is west of UTC, this should be negative. Note that this is intended to be the total offset from UTC; for example, if atzinfo<http://docs.python.org/2/library/datetime.html#datetime.tzinfo> object represents both time zone and DST adjustments, utcoffset()<http://docs.python.org/2/library/datetime.html#datetime.tzinfo.utcoffset> should return their sum. If the UTC offset isn't known, return None. Else the value returned must be a timedelta<http://docs.python.org/2/library/datetime.html#datetime.timedelta>object specifying a whole number of minutes in the range -1439 to 1439 inclusive (1440 = 24*60; the magnitude of the offset must be less than one day). A

rule is needed to specify how the naive time object and `utcoffset()` interact to define the result.

Not sure why you attach 'naive' to time. Time objects carry units with them, unlike integers. I would say 'naive time value' in reference to an integer. Combining a time and an integer can be done by converting the time to minutes (which is a bit confusing since in most contexts in this class, minutes values are integers) or it can be done by interpreting the integer utcoffset result as minutes (as it is documented).

...

Perhaps a reasonable improvement would be to change this to:

a time object is considered to be true unless it represents exactly midnight local time,

The above part is the key part of my suggested improvement. Reading the current documentation, the fact that it means midnight local time is falsey is not obvious. --- Bruce Learn how hackers think: http://j.mp/gruyere-security https://www.linkedin.com/in/bruceleban

On Wed, Mar 5, 2014 at 8:13 PM, Tim Peters <tim.peters@gmail.com> wrote:

[Tim]

...

...

That's there because `utcoffset()` is defined to return minutes.

[Bruce Leban]

...

It returns either minutes or a timedelta:

I wrote the code and I wrote the docs. I know what it does ;-) Going into tedious detail (as the docs do) is simply irrelevant to the point here: utcoffset() returns minutes. Whether that's _spelled_ as an integer or as a timedelta, minutes is minutes is minutes.

Just because you wrote the docs doesn't mean you know what they mean to other readers. The point of documentation is to explain it to someone who doesn't know what it does after all.

Start with the second paragraph of the datetime docs:

There are two kinds of date and time objects: "naive" and "aware".

Thanks. Before this thread, I had never heard anyone express it as "midnight

local time" before. Now that I have heard it, eh - I don't find it a helpful way to view it.

Well, it's not surprising that you don't find it's helpful. In fact, it's wrong, which to me indicates how confusing this. Which of the following are falsey? 00:00:00+01:00 01:00:00+01:00 01:00:00-01:00 07:00:00+07:00 23:00:00-01:00 I find it particularly surprising that the bug that the OP described finding would occur in the Russia and China, but not in the US. Obviously, not an accident. :-) --- Bruce

On Thu, Mar 6, 2014 at 12:53 AM, Tim Peters <tim.peters@gmail.com> wrote:

[Bruce Leban <bruce@leapyear.org>]

...

... Just because you wrote the docs doesn't mean you know what they mean to other readers. The point of documentation is to explain it to someone who doesn't know what it does after all.

Of course. What's your point here?

I am with Bruce here. I tried to digest your notes on timezone algebra [1] for years and I still don't understand it. [1] http://hg.python.org/cpython/file/b07400659dba/Lib/datetime.py#l1922

On Mar 6, 2014, at 11:50 AM, Tim Peters <tim.peters@gmail.com> wrote:

[Bruce Leban <bruce@leapyear.org>]

...

...

...

... Just because you wrote the docs doesn't mean you know what they mean to other readers. The point of documentation is to explain it to someone who doesn't know what it does after all.

[Tim]

...

...

Of course. What's your point here?

[Alexander Belopolsky <alexander.belopolsky@gmail.com>]

...

I am with Bruce here. I tried to digest your notes on timezone algebra [1] for years and I still don't understand it.

[1] http://hg.python.org/cpython/file/b07400659dba/Lib/datetime.py#l1922

But those aren't user docs - they're notes for developers who are deeply steeped in internal details. And they're hard! Mucking with "all possible" time zones raises mountains of excruciatingly subtle details and corner cases. The masses of tedious "algebra" were needed to justify how the internals get away with doing "so little" - and to explain why the code still wouldn't work right in all cases if the "standard offset" of a single time zone changed (or changes) over time.

Do you claim you still don't understand when bool(time) returns True and False? Those are user docs. I don't claim that reading them will make anyone feel good ;-), but I do believe the computation is described clearly enough to enable a reasonable user to predict the result in all cases.

I don’t think a reasonable user would predict that midnight UTC in a timezone with a UTC offset of +5 would be false, while midnight UTC in a timezone with a UTC offset of -5 would not be false.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Mar 6, 2014, at 12:01 PM, Tim Peters <tim.peters@gmail.com> wrote:

[TIm]

...

...

... Do you claim you still don't understand when bool(time) returns True and False? Those are user docs. I don't claim that reading them will make anyone feel good ;-), but I do believe the computation is described clearly enough to enable a reasonable user to predict the result in all cases.

[Donald Stufft <donald@stufft.io>]

...

I don't think a reasonable user would predict that midnight UTC in a timezone with a UTC offset of +5 would be false, while midnight UTC in a timezone with a UTC offset of -5 would not be false.

As I said, I didn't claim a reasonable user would feel good about it, and all you're saying here is that they wouldn't feel good about it. I'm not arguing that they should feel good about it.

I said that the docs explained the computation clearly enough that a reasonable user - who read the docs and earnestly tried to apply them - _could_ predict the results. And you just showed that you, for example, can predict them. Since you're the very definition of "reasonable", I close my case for that ;-)

Actually I wasn’t able to predict it :) Someone else posted a number of times offsets and their boolean values. I was really confused when it turned out that 01:00:00+01:00 (1AM France/Midnight UTC) was False but 19:00:00-05:00 (7PM Boston/Midnight UTC) wasn’t. I only realized that the cause was the specific formula that was used when I reversed it and tried to figure out what time in Boston would be False and realized it was -05:00. I don’t think it’s reasonable by any definition of the word that in order to predict the results a user would have to turn it into an algebraic formula and solve for X to determine that the only way for Boston to have a False time is if time was negative. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

[Alexander Belopolsky <alexander.belopolsky@gmail.com>]

I have to admit that before this discussion, I did not know about the following consequence of the documented behavior:

...

...

...

from datetime import * t = datetime(2014, 1, 1, tzinfo=timezone.utc) tz1 = timezone(timedelta(hours=5)) tz2 = timezone(timedelta(hours=-5)) bool(t.timetz()) False bool(t.astimezone(tz1).timetz()) False bool(t.astimezone(tz2).timetz()) True

I'm not sure I did either! An "aware" time object is a bizarre beast, and I've never used one outside of writing datetime test cases. I'm not even sure why aware time objects exist - we'd have to dig into Guido's subconscious for that one ;-)

On Thu, Mar 6, 2014 at 12:16 AM, Bruce Leban <bruce@leapyear.org> wrote:

Well, it's not surprising that you don't find it's helpful. In fact, it's wrong, which to me indicates how confusing this. Which of the following are falsey?

00:00:00+01:00 01:00:00+01:00 01:00:00-01:00 07:00:00+07:00 23:00:00-01:00

I find it particularly surprising that the bug that the OP described finding would occur in the Russia and China, but not in the US. Obviously, not an accident. :-)

"Aware" time objects are problematic even before you consider their bool behavior. Fortunately, you don't encounter them too often because dt.time() returns naive time even if dt is an aware datetime instance. Again, the use case that I find compelling is to test dt.time() for falsehood to detect datetime objects that fall on midnight. I don't understand why people are denying that midnights are special points. All real numbers are equal, but integers are more equal than others. When you plot say hourly timeseries it is not uncommon to mark midnight ticks on the time axis with dt.date() and other ticks with dt.hour. Whenever you need to do something special when you start a new date in a simulation of a physical process it is convenient to have a simple test for midnight.

On Thu, Mar 6, 2014 at 2:02 AM, Bruce Leban <bruce@leapyear.org> wrote:

On Wed, Mar 5, 2014 at 10:47 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

...

it is convenient to have a simple test for midnight.

Except this isn't it. That's only works for naive times. For aware times:

00:00:00+00:00 = midnight England = midnight UTC => False 00:00:00+01:00 = midnight France = 2300 UTC => True 01:00:00+01:00 = 1 am France = midnight UTC => False 19:00:00-05:00 = 1 am Boston = midnight UTC => True

Code that relies that bool(time) is False for midnight is broken IMHO.

You keep fighting your own straw-man. My use case is not using an arbitrary time object that someone decided to imbue with a timezone info. What I want is given a *datetime* instance dt to check whether it falls on midnight in whatever timezone dt.tzinfo represent or naively if dt.tzinfo is None. I claim that "if dt.time()" is a perfectly good shorthand for "if dt.time() != datetime.time(0)". I am not trying to argue that "if not dt.timetz()" test is equally useful.

On Thu, Mar 6, 2014 at 2:30 AM, Donald Stufft <donald@stufft.io> wrote:

It’s not reasonable to expect that midnight will evaluate to false, ..

Only in the world where it is not reasonable to expect programmers to read library documentation. In my world it is reasonable to expect that the behavior that was documented in 10 major versions and for 10 years can be relied on.

especially when it doesn’t if you happen to have a tzinfo on the time (sometimes!).

As long as tzinfo specifies a fixed offset, there is no problem with the current definition. If you are unfortunate enough to live in a place with semi-annual DST adjustment, aware time objects are problematic for reasons that have nothing to do with the discussion at hand.

On Mar 6, 2014, at 2:43 AM, Donald Stufft <donald@stufft.io> wrote:

On Mar 6, 2014, at 2:40 AM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:

...

On Thu, Mar 6, 2014 at 2:30 AM, Donald Stufft <donald@stufft.io> wrote: It’s not reasonable to expect that midnight will evaluate to false, ..

Only in the world where it is not reasonable to expect programmers to read library documentation. In my world it is reasonable to expect that the behavior that was documented in 10 major versions and for 10 years can be relied on.

especially when it doesn’t if you happen to have a tzinfo on the time (sometimes!).

As long as tzinfo specifies a fixed offset, there is no problem with the current definition. If you are unfortunate enough to live in a place with semi-annual DST adjustment, aware time objects are problematic for reasons that have nothing to do with the discussion at hand.

Nope! It essentially in an aware time would be “false if whatever time is at the same time as UTC midnight, but only if your UTC offset is positive”. If your UTC offset is negative then you end up with 1440 instead of 0.

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Actually now that I think about it more, in aware times it’s impossible for it to time objects to ever be false if the tzinfo is negative, because that would require the time to negative. Take -5 for instance: x - (-5 * 60) = 0 x - (-300) = 0 x + 300 = 0 x = -300 So in order for a time with UTC offset of -5 to ever be False, it would have to be -05:00:00 there. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Bruce Leban wrote:

Except this isn't it. That's only works for naive times. For aware times:

00:00:00+00:00 = midnight England = midnight UTC => False 00:00:00+01:00 = midnight France = 2300 UTC => True 01:00:00+01:00 = 1 am France = midnight UTC => False 19:00:00-05:00 = 1 am Boston = midnight UTC => True

That's... I don't know what it is. Is there a rationale for this? I'm totally failing to see it. -- Greg

On Wed, Mar 5, 2014 at 11:00 PM, Bruce Leban <bruce@leapyear.org> wrote:

Not sure why you attach 'naive' to time.

'naive' is a defined term in the context of the datetime module. It means tzinfo is None.

On Thu, Mar 06, 2014 at 05:41:11PM +1300, Greg Ewing wrote:

Steven D'Aprano wrote:

...

There's also the argument from consistency: midnight is the zero point of the day, and zero is falsey.

Regarding midnight as a "zero point" is an arbitrary convention.

True, as I mentioned in another post. Nevertheless, we have many arbitrary conventions enshrined in Python. Using base 10 for the representation of numbers, instead of, say, balanced ternary notation, is an arbitrary convention. Numbering sequences from 0 is another. If you would prefer another convention for the zero point of the day (say, midday, dusk, dawn, or 2:15pm) then feel free to subclass datetime.time :-) Or even no zero point at all. Tossing out a wild idea, why not leave datetime.time alone and add a new class which is exactly the same but is always truthy? That doesn't break backward compatibility, and so it could happen immediately (too late for 3.4, but certainly for 3.5). All we need is an appropriate name, and a decision as to which ought to inherit from which. The bike-shedding should be over by 3.5 alpha 1 *wink* Despite my quip about the bike-shedding, I am actually serious. -- Steven

On Thu, Mar 06, 2014 at 11:40:21AM +0000, Rob Cliffe wrote:

On 06/03/2014 10:52, Steven D'Aprano wrote:

...

Or even no zero point at all. Tossing out a wild idea, why not leave datetime.time alone and add a new class which is exactly the same but is always truthy? That doesn't break backward compatibility, and so it could happen immediately (too late for 3.4, but certainly for 3.5).

All we need is an appropriate name, and a decision as to which ought to inherit from which. The bike-shedding should be over by 3.5 alpha 1 *wink*

Despite my quip about the bike-shedding, I am actually serious.

You're joking, right?

What part of "I am actually serious" suggests to you that I am joking? No, I am not joking. When you have a misdesigned API that cannot be fixed without breaking backwards compatibility, or at least cannot be fixed *quickly*, it may be sensible to leave the old API in place and place a new one side-by-side. If the old one is actively harmful, it can even be deprecated for eventual removal, otherwise it can remain indefinitely. Does the term "legacy API" sound familiar? This is *extremely common* in the software industry, at least in that part that isn't run by cowboy coders who have no concern about breaking their users' code. It's quite common in Python too: consider the legacy API of os.system, the deprecated API of the popen2 module, and the modern subprocess API.

Suppose you were considering taking up a new language and you found something in the docs which said: "Here's a class that does so-and-so. And here's another slightly different one that you can use instead, because we didn't get the first one quite right." Would that be a turn-on?

Yes. This would tell me that the developers of this language took backward compatibility seriously, and that they weren't afraid to admit to mistakes. -- Steven

On 06/03/2014 12:35, Steven D'Aprano wrote:

On Thu, Mar 06, 2014 at 11:40:21AM +0000, Rob Cliffe wrote:

...

On 06/03/2014 10:52, Steven D'Aprano wrote:

...

Or even no zero point at all. Tossing out a wild idea, why not leave datetime.time alone and add a new class which is exactly the same but is always truthy? That doesn't break backward compatibility, and so it could happen immediately (too late for 3.4, but certainly for 3.5).

All we need is an appropriate name, and a decision as to which ought to inherit from which. The bike-shedding should be over by 3.5 alpha 1 *wink*

Despite my quip about the bike-shedding, I am actually serious. You're joking, right? What part of "I am actually serious" suggests to you that I am joking? No, I am not joking.

When you have a misdesigned API that cannot be fixed without breaking backwards compatibility, or at least cannot be fixed *quickly*, it may be sensible to leave the old API in place and place a new one side-by-side. If the old one is actively harmful, it can even be deprecated for eventual removal, otherwise it can remain indefinitely. Does the term "legacy API" sound familiar?

This is *extremely common* in the software industry, at least in that part that isn't run by cowboy coders who have no concern about breaking their users' code. It's quite common in Python too: consider the legacy API of os.system, the deprecated API of the popen2 module, and the modern subprocess API.

...

Suppose you were considering taking up a new language and you found something in the docs which said: "Here's a class that does so-and-so. And here's another slightly different one that you can use instead, because we didn't get the first one quite right." Would that be a turn-on? Yes. This would tell me that the developers of this language took backward compatibility seriously, and that they weren't afraid to admit to mistakes.

Fair point. (It just feels untidy to me!) At least having two classes would highlight the difference in behaviour. Which makes me think, maybe the right thing to do now is to draw more attention to the behaviour in the docs. Section 8.1.5 time Objects currently states "in Boolean contexts, a time <http://docs.python.org/2/library/datetime.html#datetime.time> object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that's None), the result is non-zero." This could be expanded, using the sort of examples Nick Coghlan produced, and a warning added that using bool on time objects is discouraged. And section 3.1 Truth Value Testing which claims to explicitly list all the falsey objects includes "instances of user-defined classes, if the class defines a __nonzero__() or __len__() method, when that method returns the integer zero or bool value |False|" I think this could be reworded. "user-defined classes" does not suggest to me that it includes classes in the stdlib. Would it be going too far to include in this section a short warning that using bool (explicitly or implicitly) on time objects is discouraged, or at least may not behave as expected? Rob Cliffe

Shai Berger writes:

At issue here is the fact that the idiom doesn't fit where one would expect that it should.

This is the real problem. People are programming in un-Pythonic style by analogy to either other languages or to other cases in Python where the __len__ method provides a natural cast to Boolean, and deciding since they like the idiom, the behavior of time.time is "unexpected." But your claim is *not* a "fact". Quite the reverse, I was mildly surprised even the last time around that anybody would argue that it's a good idea to use a sentinel to indicate "uninitialized" and then fail to test explicitly for the sentinel. For example, I wouldn't be surprised to see something like this in an MTA or other program that should not let data out of its sight without a timestamp: my_time = None if not my_time and x: my_time = x.supposed_to_be_time_but_in_fact_sometimes_0 if not my_time: my_time = time.now() What are the odds that you'll detect the bug in initializing 'x' in a timely fashion? OTOH, if you test for "is None" you'll probably get a quick TypeError the first time the bug manifests. (No guarantees, of course, but why trade a potentially easy bug for a probably hard one?) If you asked me to implement a Time class, would I have any false instances? Quite possibly, yes. Of course I might implement it as a namedtuple (h, m, s), in which case it would always be true. OTOH, I might implement it as seconds-since-midnight, and probably not bother to give it a __bool__ method to ensure bool(midnight) == True. So I don't really care *why* Uncle Timmy chose to make midnight be false, I only offer kudos for documenting it. :-)

On 5 March 2014 17:27, Amber Yust <amber.yust@gmail.com> wrote:

Let's turn this around. Aside from backwards compatibility, what benefit is there from having midnight evaluate as false?

Zero cost. Any alternative must justify the cost of making the change. Simple as that. Quantify the cost of making the change (properly!) and describe the benefits in such a way as to justify those costs. Paul

On 05/03/2014 18:12, Amber Yust wrote:

I think this is the wrong stage to evaluate cost. After all, one of the tenets of open source is that the core devs don't have to be the source of all change.

But the core devs have to review the change and ultimately decide whether or not to commit it. In this case it looks as if a patch would not be accepted, so why keep going on about it, especially when there's a known work around? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

On 05/03/2014 18:26, Amber Yust wrote:

Where did you see an indication that a patch would not be accepted?

On Mar 5, 2014 10:24 AM, "Mark Lawrence" <breamoreboy@yahoo.co.uk <mailto:breamoreboy@yahoo.co.uk>> wrote:

On 05/03/2014 18:12, Amber Yust wrote:

I think this is the wrong stage to evaluate cost. After all, one of the tenets of open source is that the core devs don't have to be the source of all change.

But the core devs have to review the change and ultimately decide whether or not to commit it. In this case it looks as if a patch would not be accepted, so why keep going on about it, especially when there's a known work around?

-- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language.

Mark Lawrence

---

http://bugs.python.org/issue13936 has been closed as invalid and I don't see a rush of core devs backing this proposal. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

On 05/03/2014 19:06, Amber Yust wrote:

It was closed by one or two individuals, and there has been significant comment since then. Asking to revisit a decision isn't crazy, and there have been reasonable suggestions made. I don't see a lack of core dev "jumping upon" as an active indication that patches would be rejected; merely that core devs are unlikely to produce such a patch themselves.

On Mar 5, 2014 11:00 AM, "Mark Lawrence" <breamoreboy@yahoo.co.uk <mailto:breamoreboy@yahoo.co.uk>> wrote:

On 05/03/2014 18:26, Amber Yust wrote:

Where did you see an indication that a patch would not be accepted?

On Mar 5, 2014 10:24 AM, "Mark Lawrence" <breamoreboy@yahoo.co.uk <mailto:breamoreboy@yahoo.co.uk> <mailto:breamoreboy@yahoo.co.__uk <mailto:breamoreboy@yahoo.co.uk>>> wrote:

On 05/03/2014 18:12, Amber Yust wrote:

I think this is the wrong stage to evaluate cost. After all, one of the tenets of open source is that the core devs don't have to be the source of all change.

But the core devs have to review the change and ultimately decide whether or not to commit it. In this case it looks as if a patch would not be accepted, so why keep going on about it, especially when there's a known work around?

-- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language.

Mark Lawrence

---

http://bugs.python.org/__issue13936 <http://bugs.python.org/issue13936> has been closed as invalid and I don't see a rush of core devs backing this proposal.

There can be lots of comments by Her Majesty Queen Elizabeth II or President Obama but they don't really count unless they put forward arguments to pursuade the core devs to change their minds about this issue. I see no evidence here that this is likely to happen, or do the core devs all come to life at the same time as they're all in the same time zone? A patch can be placed on the issue but if a core dev reviews and it and decides not to commit it nothing happens? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

On 05/03/2014 18:33, Shai Berger wrote:

On Wednesday 05 March 2014 20:23:12 Mark Lawrence wrote:

...

On 05/03/2014 18:12, Amber Yust wrote:

...

I think this is the wrong stage to evaluate cost. After all, one of the tenets of open source is that the core devs don't have to be the source of all change.

But the core devs have to review the change and ultimately decide whether or not to commit it. In this case it looks as if a patch would not be accepted, so why keep going on about it, especially when there's a known work around?

As noted before, the workaround is trivial once you detect the problem. Detecting the problem is not easy.

Shai.

Use mocks in unit testing? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com