[Python-ideas] Infix functions

[Nick Coghlan]

On 24 February 2014 09:14, Nicholas Cole <nicholas.cole at gmail.com> wrote:
>
> I'm comfortable with a language that is very slightly more verbose than it
> could be. Python at version 3.4 is very readable. Please let's keep it that
> way!
>
> I'm not getting at anyone - or any particular proposal -  but there have
> been a spate of similar things!

Don't worry, this is just an artefact of the brainstorming nature of
python-ideas. Most of the ideas that are posted here won't be a good
fit for Python, and *that's OK*. This applies even to the ideas that
are posted by experienced core developers - those of us that have been
around for long enough to build a pretty good intuition for what
counts as "Pythonic" may skip the python-ideas phase of the process
when we're confident an idea is a good one and go straight to
python-dev or the issue tracker.

The end result is that python-ideas discussions related to more
esoteric proposals will typically churn around for a while, and then
dwindle away naturally. Sometimes more experienced list participants
will attempt to nudge such threads in more productive directions, but
other times we'll just let them take their natural course (which of
those happens will depend mainly on whether there seems to be a
possible seed of a good idea in the initial proposal, and how much
time people have available to participate in the discussion).

Occasionally, someone will hit on something that actually seems
promising, and a PEP or a new third party PyPI module is born. PEP
463's except expressions are the most recent example of that, and PEP
450's statistics module is an example of one that went through the
process of starting life as a third party module on PyPI (statslib).
Other times, a PEP will be born that isn't actually ready for
submission to python-dev, but instead acts as a historical record for
a problem that is interesting but difficult to solve in a Pythonic way
(my own PEPs 403 and 3150 fall into that category).

The other thing to remember is that many of the more conservative
members of the core development team *don't* participate in
python-ideas (making that possible is one of the main reasons they're
two separate lists), so even if a proposal gets to the point of being
submitted as a PEP, that's still no guarantee that the PEP will be
*accepted*. python-dev review may highlight issues that we missed here
on python-ideas, and while those can often be fixed by slight tweaks
to the PEP, sometimes they may be judged to represent such a fatal
flaw that the PEP will be explicitly rejected rather than being
revised.

So yeah, it's part of the nature of python-ideas to be an environment
for relatively free-wheeling "throw ideas at the wall to see what
sticks" discussions, as well as history lessons on why things are the
way they are, and providing advice on how to build a persuasive case
for a particular change. By contrast, python-dev is more focused on
the filtering stage of answering the question "Does this change
represent an overall improvement to Python?", and the default answer
to that question is always going to be No (simply on the grounds that
the number of ways we could make Python worse is unbounded, so any new
proposal needs to make a persuasive case for how that *particular*
change actually makes Python better).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia