2to3 refactoring [was Re: Tuple parameter unpacking in 3.x]

[Steven D'Aprano]

PEP 3113 offers the following recommendation for refactoring tuple 
arguments:

def fxn((a, (b, c))):
    pass

will be translated into:

def fxn(a_b_c):
    (a, (b, c)) = a_b_c
    pass

and similar renaming for lambdas. 
http://www.python.org/dev/peps/pep-3113/


I'd like to suggest that this naming convention clashes with a very 
common naming convention, lower_case_with_underscores. That's easy enough 
to see if you replace the arguments a, b, c above to something more 
realistic:

def function(vocab_list, (result, flag), max_value)

becomes:

def function(vocab_list, result_flag, max_value)

Function annotations may help here, but not everyone is going to use them 
in the same way, or even in a way that is useful, and the 2to3 tool 
doesn't add annotations.

It's probably impossible to avoid all naming convention clashes, but I'd 
like to suggest an alternative which distinguishes between a renamed 
tuple and an argument name with two words:

def function(vocab_list, (result, flag), max_value):
    pass

becomes:

def function(vocab_list, t__result_flag, max_value):
    result, flag = t__result_flag
    pass

The 't__' prefix clearly marks the tuple argument as different from the 
others. The use of a double underscore is unusual in naming conventions, 
and thus less likely to clash with other conventions. Python users are 
already trained to distinguish single and double underscores. And while 
it's three characters longer than the current 2to3 behaviour, the length 
compares favorably with the original tuple form:

t__result_flag
(result, flag)

What do people think? Is it worth taking this to the python-dev list?


-- 
Steven