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 -- http://mail.python.org/mailman/listinfo/python-list
