[Python-ideas] Please reconsider the Boolean evaluation of midnight

[Steven D'Aprano]

On Wed, Mar 05, 2014 at 04:31:36PM -0500, Donald Stufft wrote:

> I find the argument that it would only be fixed in 3.something and thus not be really
> fixed for X years disingenuous at best. That fact is true for *ALL* bug fixes in Python
> so by that logic we should simply give up on fixing anything in Python ever?

Not at all. But it does mean that the benefit of fixing it needs to be 
worth the wait. Suppose we said "Sure, we'll fix it, but you have 
to pay for the fix." How much would you be willing to pay to have it 
fixed? 

("Pay" doesn't have to mean money. It can also mean, how much pain or 
inconvenience are you willing to experience, or how much time and effort 
are you willing to out into this.)

If I said, "Oh by the way, although you have to pay right now, you won't 
see any benefit until 2024", now how much are you willing to pay?

Design flaws are more costly to fix than outright bugs, not because they 
take more time and effort to change, but because you're changing 
behaviour that *somebody out there is relying on*. What you consider a 
terrible misfeature is *somebody's* critical feature, and you're 
proposing that we take that away. That's okay, we can do that after a 
suitable deprecation period. (You wouldn't want us to break your code, 
so you ought to extend the same courtesy to other people.)

But even if there isn't anyone relying on this, and we fix it as soon as 
possible (which will be 3.5), your library *still* can't rely on it 
until it drops all support for versions below 3.5. Since you can't rely 
on that feature being present, you have to write your library code as if 
it wasn't present. So there is *absolutely no difference* between your 
library with this (alleged) bug being fixed, or it not being fixed.

The situation for application developers is a bit different. An 
application developer can simply say, I'm going to immediately migrate 
to 3.5 to take advantage of this new feature/bug fix. That's okay too. 

The job of the core developers is to balance all these competing 
interests: the library developers, the application developers, the users 
who don't care one way or another but do care about some other bug 
that's not being fixed because people are arguing about this one, the 
people (actual or hypothetical) who actually like this (mis)feature the 
way it is, people who don't like it but have written code that relies on 
it, and, yes, even the core developers themselves, who are perfectly 
entitled to say that the effort in fixing this is greater than the 
benefit so they're not going to do it.

If you haven't already read Nick's blog posts on these issues, you 
should:

http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html
http://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html


For what it's worth, I think the current behaviour is a misfeature, and 
in a perfect world it would be fixed. But the cost of this is so 
miniscule, and the work-around so trivial, that although the fix is 
cheap, the benefit is even lower. I've only spent a few minutes reading 
and responding to this thread. Those few minutes are already worth far 
more than any benefit to me in fixing this. That's *my* personal opinion 
on this, others may differ, so I'm a +0 on deprecating the behaviour in 
3.5 and changing it in 3.6 or 3.7, and -0.5 on changing it immediately 
in 3.5.



-- 
Steven