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

[Peter Otten]

Steven D'Aprano wrote:

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

Let's see what the conversion tool does:

$ cat tmp.py
g = lambda (a, b): a*b + a_b
$ 2to3 tmp.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
--- tmp.py (original)
+++ tmp.py (refactored)
@@ -1,1 +1,1 @@
-g = lambda (a, b): a*b + a_b
+g = lambda a_b1: a_b1[0]*a_b1[1] + a_b
RefactoringTool: Files that need to be modified:
RefactoringTool: tmp.py

So the current strategy is to add a numerical suffix if a name clash occurs.
The fixer clearly isn't in final state as for functions instead of lambdas
it uses xxx_todo_changeme.

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

I suppose that actual clashes will be rare. If there is no clash a_b is the
best name and I prefer trying it before anything else. 
I don't particularly care about what the fallback should be except that I
think it should stand out a bit more than the current numerical suffix.
xxx1_a_b, xxx2_a_b,... maybe?

Peter