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

[Markus Unterwaditzer]

On 6 March 2014 03:14:57 CET, Steven D'Aprano <steve at pearwood.info> wrote:
>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*.

Just because "somebody" is relying on a wart in the language it doesn't mean that this person is knowing what they are doing, is representative of the rest of Python users or that the wart shouldn't be removed. In my opinion it even means that the person is a bad programmer in a way, because even though he is relying documented behavior, that behavior is relatively unknown and using it intentionally certainly doesn't help readability. Actually i think that this programmer put extra effort into making their own code less readable. Partially, this point has already been made many times in this thread, but apparently this doesn't suffice to make the opposing side realize or respond to it.

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.

Arguably many libraries already do rely on this currently nonexistent feature.

>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.