ci.addCallback(lambda (ai, bi): ai * bi)
or
map(lambda (i, s): (field(i + 1), s), enumerate(si))
Rewriting these to
ci.addCallback(lambda abi: abi[0] * abi[1])
and
map(lambda is: (field(is[0] + 1), is[1]), enumerate(si))
makes the code much uglier! And slightly longer.
Nick said:I don't think many people will miss tuple unpacking in def statements.
I think the warning is probably wrong anyway - you just need to remove
a few parens...
On
Python 3.0rc1 (r30rc1:66499, Oct 4 2008, 11:04:33)
File "<stdin>", line 1
f = lambda (ai, bi): ai * bi
^
SyntaxError: invalid syntax
But
File "<stdin>", line 1
lambda (i, s): (field(i + 1), s)
^
SyntaxError: invalid syntax
So just remove the parentheses and you'll be fine.
Martin said:A somewhat related question: do I pay a performance penalty when I let a
function define an inner function like this:
def foo():
def bar()
...
bar()
compared to just defining it once outside:
def bar():
...
def foo():
...
bar()
I'm thinking that each execution of the first foo could spend a little
time defining a new bar each time, or is that not how things work?
I realize that defining bar as an inner function has the advantage of
being able to see variables in the namespace of foo.
Dennis Lee Bieber said:Given that most lambda's are rather short, is it really thatIn 3.0 it has to be rewritten as
def f(ab):
a, b = ab
return a*b
i. e. it needs a statement and an expression and is therefore no
longer suitable for a lambda.
much of a pain to just use (for the above example) ab[0]*ab[1] without
unpacking?
Well -- it is because the code used to be short and sweet that it feels
ugly to me to change
lambda (a, b): a * b
into
lambda ab: ab[0] * ab[1]
The first looks perfect -- it matches the math behind the code that I am
writing. The second does not look so nice.
6
From reading the PEP-3113 I got the impression that the author thought
that this feature was unused and didn't matter. With this I wish to say
that it matters to me.
A somewhat related question: do I pay a performance penalty when I let a
function define an inner function like this:
def foo():
def bar()
...
bar()
compared to just defining it once outside:
def bar():
...
def foo():
...
bar()
I'm thinking that each execution of the first foo could spend a little
time defining a new bar each time, or is that not how things work?
I realize that defining bar as an inner function has the advantage of
being able to see variables in the namespace of foo.
[1.8273210525512695, 1.1913230419158936, 1.1786220073699951]assert func(37) == func2(37)
from timeit import Timer
t1 = Timer('func(23)', 'from __main__ import func')
t2 = Timer('func2(23)', 'from __main__ import func2')
t1.repeat() [1.5711719989776611, 0.82663798332214355, 0.82708191871643066]
t2.repeat()
Steven said: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 said: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 said: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?
Thanks! And I know it's too late, I should have found out about this
earlier :-(
There's the possibility that the most important words should go first in
this case:
result_flag__t
But, I'll admit that other people could have learned different orders of
scanning words than I, especially depending on their spoken language
backgrounds. A poll of the newsgroup isn't exactly academically
impartial sampling, but there aren't any better ways to make decisions,
are there? (I think it would be easy to make either one a habit.)
Here's the other option in the same context:
def function(vocab_list, result_flag__t, max_value):
result, flag = result_flag__t
pass
To be thorough, there's also a trailing double underscore option.
def function(vocab_list, result_flag__, max_value):
result, flag = result_flag__
pass
Which I don't recognize from any other usages, but I defer. If there
aren't any, conditionally, I think this is my favorite.
And that there were good alternatives, and that there were technical
reasons why maintaining the feature in the face of other arguments
options would be a nuisance.
>>> With this I wish to say that it matters to me.
For future reference, the time to have said something would have been
during the 3 month alpha phase, which is for testing feature and api
changes. I suspect, from reading the pydev discussion, that the answer
still would have been to either use a def statement and add the unpack
line or to subscript the tuple arg to stick with lambda expressions.
But who knows?
There are two things to realize about the tuple unpacking that acted
as motivation. One is supporting them in the compiler is a pain.
...
Second, tuple unpacking in parameters breaks introspection horribly.
Steven said: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?
Could it be a double underscore instead, eg a__b,Steven D'Aprano wrote: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.pySo 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.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?
Possibly you have misunderstood me. I'm not concerned with a clash
between names, as in the following:
lambda a_b, (a, b):
maps to -> lambda a_b, a_b:
as I too expect they will be rare, and best handled by whatever mechanism
the fixer users to fix any other naming clash.
I am talking about a clash between *conventions*, where there could be
many argument names of the form a_b which are not intended to be two item
tuples.
In Python 2.x, when you see the function signature
def spam(x, (a, b))
it is clear and obvious that you have to pass a two-item tuple as the
second argument. But after rewriting it to spam(x, a_b) there is no such
help. There is no convention in Python that says "when you see a function
argument of the form a_b, you need to pass two items" (nor should there
be).
But given the deafening silence on this question, clearly other people
don't care much about misleading argument names.
*wink*
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.