attaching names to subexpressions
steve+comp.lang.python at pearwood.info
Sun Oct 28 07:59:52 CET 2012
On Sun, 28 Oct 2012 01:57:45 -0400, Devin Jeanpierre wrote:
> We have a problem, and two solutions. Solution 1 has downside A, and
> solution 2 has downside B. If he complains about downside A, you say,
> well, use solution 2. If he complains about downside B, you say, well,
> use solution 1.
> What if he wants to avoid both downsides A and B? What solution does he
> use then?
"I want to have my cake, and eat it too." Every solution has some
downside. Just because no other solution is perfect (whatever that
means!) doesn't mean we must keep adding more and more ways to solve the
same problem into a language.
The proposed solution, assignment as an expression, has multiple
* Since it doesn't actually exist yet, you can't use it. It's
not a solution until *at least* Python 3.4. The first alpha
is scheduled in August 2013, the first stable release is not
due until end of Feb 2014. So you have to wait 16 months
before you can use this in production code.
* If you support multiple versions of Python, you can't use
this. Assuming, conservatively, that you need to support
the current version of Python plus two older versions, that
means you can't use this until Python 3.6, which is probably
due out in 2017. "Wait five years" is hardly a solution for
code you are writing today.
* You can't just wave a magic wand and have Python support this
new syntax. Somebody has to write a PEP and get it approved;
somebody has to modify the parser, write documentation for it,
write tests, ensure it doesn't break anything.
* And once it does exist, it adds to the complexity of Python
the language. People learning the language have one more
feature to learn. Every time you write a loop, you have one
more decision to make -- should I write this loop using A,
or B, or C?
* Like all features, it is open to abuse. Does the benefit
from the good uses outweigh the cost of the abuses? Given
that I think the benefit is at best minor, I doubt that it
will outweigh the harm to readability and maintainability
when it is abused.
* What unexpected problems is this going to cause? I don't
know -- but that's the point, if they exist they will be
*unexpected*. Python 3 introduced the literal ... as an
alias for Ellipsis. Nobody realised that this would have
consequences for doctests until somebody reported a
problem, by which time it was too late.
All these downsides make the barrier to entry for new syntax very high.
Python is a 20 year old mature language. Most, perhaps all, of the low-
hanging fruit syntax-wise has been picked. Don't be surprised when
there is opposition to adding new syntax. With very few exceptions, new
syntax has real costs and little or questionable benefit.
Adding syntax is not free, it costs somebody time and effort. Unless the
syntax is a big win, that time and effort is probably better put into
fixing bugs. There is a great shortage of time and manpower for the
Python developers, there is a list of open bugs half a mile long. Every
minute spent adding new syntax for some minor benefit is time that could
be fixing bugs that cause actual problems with real-world code, not just
to satisfy some minor concern about DRY purity.
More information about the Python-list