[Python-ideas] if in for-loop statement

[Paul Moore]

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