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

[Donald Stufft]

On Mar 5, 2014, at 9:14 PM, 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?

Well I’ve offered to not only write the patch (assuming that someone else
doesn’t do it before me since my time is limited), but also shepherd it
through review and commit it myself. So I’m willing to pay with my free time
which is a very limited resource :)

In general I agree that everything has to go through a cost/benefit analysis,
and in this case the cost and benefit are both fairly low in the grand scheme
of things but the benefit does outweigh the cost as far as I’m concerned
because the workaround requires you to know that the workaround is
even required at all.

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

It’s not obvious to me that design flaws are more costly to fix because
people rely on even buggy behavior :) I don’t think i’ve advocated for
not sending this through a normal deprecation process at all.

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

There is a difference in the future when 3.5 (or whatever) is a reasonable
minimum for a library. People say the same sort of thing about *anything*
that is fixed or added to Python 3.x only that can’t be backported easily.

There is a wait time until library authors can depend on anything new or
changed in Python and there always has been an always will be. All that
means is that a change now won’t be widely useful until some years down
the road. But that’s true for *anything*, asyncio, PEP453, yield from, and
this change too.

> 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

I’ve read them. I have ~opinions~ about them but I’m not going to derail this
thread with them.

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

As I said, the work around is trivial, *once you know it is needed*. This change
is reducing the cognitive burden and chance for mishap for users who aren’t aware
of this misfeature. It’s making Python a friendlier language to use.

> 
> -- 
> Steven
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140305/f08922f3/attachment-0001.sig>