On Oct 11, 2:23 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
snip
> 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 signatur
On Oct 11, 8:23 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sun, 05 Oct 2008 17:15:27 +0200, Peter Otten wrote:
> > Steven D'Aprano wrote:
>
> >> PEP 3113 offers the following recommendation for refactoring tuple
> >> arguments:
>
> >> def fxn((a, (b, c))):
> >> pass
On Sun, 05 Oct 2008 17:15:27 +0200, Peter Otten wrote:
> 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
>> p
Brett C.:
> 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.
Are there ways to re-implement from scratch similar native pattern-
match
On Oct 5, 9:13 am, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Martin Geisler wrote:
> > Steven D'Aprano <[EMAIL PROTECTED]> writes:
> >>> From reading the PEP-3113 I got the impression that the author
> >>> thought that this feature was unused and didn't matter.
>
> And that there were good alternati
On Sun, 05 Oct 2008 "Aaron \"Castironpi\" Brady" wrote:
>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
Martin Geisler wrote:
Steven D'Aprano <[EMAIL PROTECTED]> writes:
From reading the PEP-3113 I got the impression that the author
thought that this feature was unused and didn't matter.
And that there were good alternatives, and that there were technical
reasons why maintaining the feature i
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/
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 lik
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 nam
Martin Geisler <[EMAIL PROTECTED]> wrote:
> Letting the callbacks take several arguments would definitely be the
> nicest syntax, but I'm unfortunately restricted by the Twisted
> framework: there all functions in a callback chain return one result
> which is passed to the next callback as the fir
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> On Sat, 04 Oct 2008 17:07:14 +0200, Martin Geisler wrote:
>
>> 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
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> On Sat, 04 Oct 2008 22:57:23 +0200, Martin Geisler wrote:
>
> Here's another alternative. Compare:
>
x = (2, 3)
(lambda (a,b): a*b)(x)
> 6
>
> with this:
>
(lambda a,b: a*b)(*x)
> 6
Letting the callbacks take several arguments would def
On Sat, 04 Oct 2008 17:07:14 +0200, Martin Geisler wrote:
> 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:
>
>
On Sat, 04 Oct 2008 22:57:23 +0200, Martin Geisler wrote:
> Dennis Lee Bieber <[EMAIL PROTECTED]> writes:
>
>> On Sat, 04 Oct 2008 13:14:40 +0200, Peter Otten <[EMAIL PROTECTED]>
>> declaimed the following in comp.lang.python:
>>
>>> In 3.0 it has to be rewritten as
>>>
>>> def f(ab):
>>> a,
Dennis Lee Bieber <[EMAIL PROTECTED]> writes:
> On Sat, 04 Oct 2008 13:14:40 +0200, Peter Otten <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>> In 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 exp
Martin Geisler wrote:
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()
Some. The *code* for the body of bar is compiled as part of compiling
the body of foo, but each call o
Peter Otten <[EMAIL PROTECTED]> writes:
> Nick Craig-Wood wrote:
>
>> So just remove the parentheses and you'll be fine.
>
> No, you change the function signature in the process.
>
> f = lambda (a, b): a*b
>
> is equivalent to
>
> def f((a, b)): # double parens
>return a*b
>
> and called as f(
Nick Craig-Wood wrote:
> Martin Geisler <[EMAIL PROTECTED]> wrote:
>
>> I just tried running my code using "python2.6 -3" and got a bunch of
>>
>>SyntaxWarning: tuple parameter unpacking has been removed in 3.x
>>
>> warnings. I've read PEP-3113:
>>
>>http://www.python.org/dev/peps/p
Martin Geisler <[EMAIL PROTECTED]> wrote:
> I just tried running my code using "python2.6 -3" and got a bunch of
>
>SyntaxWarning: tuple parameter unpacking has been removed in 3.x
>
> warnings. I've read PEP-3113:
>
>http://www.python.org/dev/peps/pep-3113/
>
> but I'm still baffle
Martin Geisler:
> 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 slight
Hi,
I just tried running my code using "python2.6 -3" and got a bunch of
SyntaxWarning: tuple parameter unpacking has been removed in 3.x
warnings. I've read PEP-3113:
http://www.python.org/dev/peps/pep-3113/
but I'm still baffled as to why you guys could remove such a wonderful
feature?!
22 matches
Mail list logo
