attaching names to subexpressions

[Steven D'Aprano]

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 
downsides:

* 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.



-- 
Steven