[Python-3000] PEP 3113 (Removal of Tuple Parameter Unpacking)

Nick Coghlan ncoghlan at gmail.com
Mon Mar 5 11:17:36 CET 2007


Ka-Ping Yee wrote:
> In summary, all of the arguments for removing this feature are of the
> form "It won't hurt very much if we remove the feature"; the arguments
> for keeping the feature are of the form "This feature is useful and
> good for the language."  Notice the asymmetry: there are no arguments
> that removing it will actually yield a better language, only arguments
> that the harm caused by removing it will be small.

The way I interpret the argument is more along the lines of "this 
feature has been in the language for years, but look at all these other 
aspects of the language and standard library that still don't support it 
correctly".

Now we have more features we want to add which would *also* require 
additional work in order to make tuple parameters work correctly.

I see the PEP as asking the question as to whether or not we really want 
to keep supporting a feature which makes it harder to do other things we 
want to do, when nobody has cared enough to even make that feature fully 
supported in the Python 2.x series.

As I recall, tuple parameter unpacking was also a cause of a number of 
tricky bugs during the transition to the AST-based compiler.

A little used feature that imposes a significant maintenance burden 
strikes me as well worth getting rid of - maintaining the status quo 
appears to be far from free once development effort is taken into account.

Further, by stripping the current version of this ability out, it opens 
the door to the introduction of a far less painful pre-AST form of 
syntactic sugar (similar to the way try-except-finally unification was 
handled). Such a re-introduction of automatic parameter unpacking might 
also be able to be designed such that the tuple itself is still assigned 
a name (which would alleviate many of the problems that make the current 
version of tuple parameter unpacking such a pain to deal with on the 
implementation side).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org


More information about the Python-3000 mailing list