[Python-ideas] if in for-loop statement

[Henk-Jaap Wagenaar]

Hi Paul,

Thanks for typing that all out and taking the time to respond to my emails.
I think as you say, it might be good to put this somewhere obvious.

I did find https://docs.python.org/devguide/langchanges.html and
http://www.curiousefficiency.org/posts/2011/02/justifying-python-language-changes.html
but the things you wrote would be useful to add the former (or be linked
from there). It would also be good if there was a counter-point to that
blog post of changes (like this one) that are not sufficiently thought
through or significant enough to be accepted: it is always good to have
examples on both sides.

In terms of your "it keeps coming up", maybe there should be a general PEP
(or something else) that simply outlines a bunch of ideas (and will be kept
adding to) that keep cropping up but have been rejected/received
unsympathetically many times? Including maybe links to these threads?

Maybe that is something that could save you (and others subscribed) time
and effort?

H-J

On 23 February 2017 at 15:02, Paul Moore <p.f.moore at gmail.com> wrote:

> On 23 February 2017 at 14:20, Henk-Jaap Wagenaar
> <wagenaarhenkjaap at gmail.com> wrote:
> >
> > In a straw poll at the company I work at everyone was in favour, though
> they
> > obviously are not in charge of implementing or changing documentation so
> > that is easy for them to say, they've got no skin in the game. I don't
> know
> > whether it is common for such an idea to be brought up again and again by
> > newcomers/those who don't strolls the archives enough, but if it keeps
> being
> > brought up, and the main argument against is it would take time and
> effort
> > to document and implement for little benefit, if Python sticks around
> for a
> > long enough time, it will end up taking less time simply implement it!
>
> We really need a FAQ for this, if there isn't one already. You quoted
> Nick referring to a post I'd already made on this, and while I'm
> afraid I don't have time to find a link for you, I'll try to summarise
> again here.
>
> The bar for syntax changes to Python (and also library changes,
> although to a slightly lesser extent) is deliberately very high. This
> is not because people don't like proposals, but rather because the
> proposers consistently and drastically underestimate the cost of
> adding new features to the language.
>
> Things that need to be factored into the cost of a change:
>
> 1. Written materials, such as books, training courses, blog posts will
> be out of date, at best offering obsolete advice, at worst being
> outright wrong. Either the authors have extra work to do to change
> them, or the readers need to learn the "new truth", probably by making
> mistakes that they could have avoided if the material were correct.
> 2. Core developers need to understand the implementation of the new
> feature in order to support it.
> 3. Unintended consequences and/or problems with the design of the new
> feature (= bugs) need to be fixed.
> 4. People writing code that needs to support multiple versions of
> Python probably won't benefit, as they'll have to avoid the feature.
> But they will pay costs:
>   a) They need to review that decision over time - is the new feature
> compelling enough that we should drop support for older versions yet?
>   b) If there's an existing way of writing the construct, why ever
> change to the new version at all?
>   c) PRs written by people used to the new feature will need reviewing
> and fixing for compatibility.
> 5. People not interested in the new feature will encounter it in other
> people's code and will need to understand it.
> 6. Someone has to code it. It's often not at all clear whether the
> proposer is offering to spend the time implementing the feature, and
> we typically don't bluntly say "well, will you write the code?" both
> because it's a bit aggressive, and also because an answer of "yes"
> isn't enough by itself - so we don't want to mislead people that the
> *only* problem is finding someone to code the change.
>
> There's probably others that I have missed.
>
> In addition, there's a couple of other points, not directly related to
> cost but still downsides of new features:
>
> 1. People need to be able to search for the new feature and learn it.
> For syntax in particular, that's hard, as you can't search for
> something unless you know the right terms. Often a library function is
> better than syntax for precisely this reason.
> 2. If a new syntax is defined as "equivalent to XXX which is how you
> write it now", then (a) it immediately violates the "there should be
> one obvious way to do it" rule, *unless* the new syntax is so
> compelling as to immediately be seen as the new "obvious" way to do
> things. And (b) the people having to support older versions of Python
> (i.e. a *lot* of people) have no incentive to use the new construct
> because then they'd have to drop support for existing Python versions.
>
> Now, none of the above are insurmountable. We do get new syntax
> features - and they aren't always massive like async or typing.
> Unpacking generalisations and f-strings are recent new syntax. But you
> have to have a *really* good story in terms of benefits to pass the
> bar. And that means a lot more than just "most people on the list
> weren't actively against it" in the case of a proposal that's already
> been made and rejected.
>
> Regarding your other points, it *is* hard for newcomers to know what's
> an old idea. We do what we can (even to the extent of sometimes
> recommending PEPs just so that ideas can be formally rejected for
> reference) but not everyone reads up on the history, and we try to be
> forgiving of that. Your original post showed that you had done some
> research, so thanks for that. Hopefully, we can work on clarifying for
> people like you why the "it keeps coming up" argument isn't sufficient
> by itself.
>
> As regards "it will take less time in the end to implement it", if
> only that were true :-) Sadly, most of the people contributing to
> discussions here (and even though I'm a core dev, I include myself
> here) don't actually write code for the Python core that often -
> whether because time to write emails is easier to find than time to
> code, or for other reasons, isn't that important. So even we were all
> to spend a week off from Python-ideas, that wouldn't necessarily
> translate into new patches for Python.
>
> I hope that puts the discussion into context.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170223/998e8df7/attachment.html>