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

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Sun Oct 5 13:21:00 CEST 2008

PEP 3113 offers the following recommendation for refactoring tuple 

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

will be translated into:

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

and similar renaming for lambdas. 

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 

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


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


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

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:

(result, flag)

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


More information about the Python-list mailing list