> On Apr 22, 2020, at 14:09, Steven D'Aprano <st...@pearwood.info> wrote:
> 
> On Wed, Apr 22, 2020 at 10:33:24AM -0700, Andrew Barnert via Python-ideas 
> wrote:
> 
>> If that is your long-term goal, I think you could do it in three steps.
> 
> I think the first step is a PEP. This is not a small change that can be 
> just done on a whim.

Yes, I agree. Each of the three steps will very likely require a PEP.

And not only that, the PEP for this first step has to make it clear that it’s 
useful on its own—not just to people like Serhiy who eventually want to replace 
zip and see it as a first step, but also to people who do not want zip to ever 
change but do want a convenient way to opt in to checking zips (and don’t find 
more-itertools convenient enough) and see this as the _only_ step.

>> And of course after the first two steps you can proselytize for the
>> next one. If you can convince lots of people that they should care
>> about the choice more often and get them using the explicit functions,
>> it’ll be a lot harder to argue that everyone is happy with today’s
>> behavior.
> 
> If they need to be *convinced* to use the new function, then they don't 
> really need it and didn't want it.

I had to be convinced that I wanted str.format. (The guy who convinced me was 
enthusiastic enough that he went through the effort of writing a __format__ 
method for my Fixed1616 class to show how easily extensible it is.) But really, 
I did want it, and just didn’t know it yet.

Hell, I had to be convinced to use Python instead of sticking with Perl and 
Tcl, but it turned out I did want it.

Let’s assume that the proponents of adding zip_strict are right that using it 
will often give you early failures on some common uses that are today painful 
to debug. If so, most people don’t know that today, and aren’t going to think 
of it just because a new function shows up in itertools, or a new flag on a 
builtin, or whatever. Someone will have to convince them to use it. But then, 
one evening, they’ll get an exception and realize, “Whoa, that would have taken 
me hours to debug otherwise, if I’d even spotted the bug…”, and they’ll realize 
they needed it, just as much as the handful who noticed the need in advance and 
went looking.

The proponents of the bigger, longer-term change of eventually making this the 
default behavior for zip may be right too. If so, many of the people who were 
convinced to use zip_strict will find it helpful so often, and zip_shortest so 
unusual in their code, that they start asking why the hell strict isn’t the 
default instead of shortest. And then it’ll be a lot easier for Serhiy or 
whoever to sell such a big change. Of course if that doesn’t ever happen, it’ll 
be a lot harder to sell the change—but in that case, the change would be a 
mistake, so that’s good too.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PPSOSLWFLGV4KF2X44THDJ53XPIOSZTY/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to