Is there any reason why something like this would not be a good idea?
a_list = [1, 2, 3, 4, 5] a, b, *c = a_list
You could then do things like this:
lol = [[1, 2], [3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13]] for a, b *c in lol: ...
- Dave -- http://www.object-craft.com.au
Dave Cole wrote:
Is there any reason why something like this would not be a good idea?
a_list = [1, 2, 3, 4, 5] a, b, *c = a_list
You could then do things like this:
lol = [[1, 2], [3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13]] for a, b *c in lol: ...
- Dave
As opposed to:
for a, b, c in ((x[0], x[1], x[2:]) for x in lol): print a, b, c
With generator expressions around, I don't know that this case is common enough for special casing. . . Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268
Nick Coghlan wrote:
Dave Cole wrote:
Is there any reason why something like this would not be a good idea?
a_list = [1, 2, 3, 4, 5] a, b, *c = a_list
You could then do things like this:
lol = [[1, 2], [3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13]] for a, b *c in lol: ...
- Dave
As opposed to:
for a, b, c in ((x[0], x[1], x[2:]) for x in lol): print a, b, c
Yes, as opposed to.
With generator expressions around, I don't know that this case is common enough for special casing. . .
This begs the question; do you prefer:
args = [4, 5, 6] a_func(1, *args)
or this:
args = [4, 5, 6] apply(a_func, [1] + args)
- Dave -- http://www.object-craft.com.au
Dave Cole wrote:
This begs the question; do you prefer:
args = [4, 5, 6] a_func(1, *args)
or this:
args = [4, 5, 6] apply(a_func, [1] + args)
- Dave
Oh, I certainly prefer the variable argument format, rather than having to use apply. The difference is that I've found that useful on several occasions, mainly because keyword arguments let you get around the 'only at the end' problem. As far as I know, the new syntax was to able to *completely* replace the functionality of 'apply' (I've certainly never needed to use it, no matter how complex the variable argument list games got). Whereas the list assignment proposal gives special synactic sugar to *one* form of slicing (x[0], ..., x[n], x[(n+1):]). As soon as the form of your slice changes, you're going to have to switch to a generator expression anyway. Hence the question about whether or not this special case was special enough to be given its own syntax, given that the comparable generator expression really isn't that complicated. *shrug* I'm not implacably opposed or anything - although I'd be interested in hearing from those around hear who teach Python as to whether they think it would be beneficial or not. Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268
Nick Coghlan <ncoghlan@iinet.net.au>:
Whereas the list assignment proposal gives special synactic sugar to *one* form of slicing (x[0], ..., x[n], x[(n+1):]).
It's a comparatively common one, though, I think. When doing things like parsing input, it's often natural to want to peel off the first few items of a list and leave the rest for processing later, based on what the initial items turn out to be. Having to explicitly slice off the part you want to unpack not only seems inefficient (constructing an intermediate list or tuple just to immediately unpack it and throw it away) it also tends to obfuscate what is going on. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Greg Ewing wrote:
Nick Coghlan <ncoghlan@iinet.net.au>:
Whereas the list assignment proposal gives special synactic sugar to *one* form of slicing (x[0], ..., x[n], x[(n+1):]).
It's a comparatively common one, though, I think. When doing things like parsing input, it's often natural to want to peel off the first few items of a list and leave the rest for processing later, based on what the initial items turn out to be.
Having to explicitly slice off the part you want to unpack not only seems inefficient (constructing an intermediate list or tuple just to immediately unpack it and throw it away) it also tends to obfuscate what is going on.
So I suppose you could avoid the unnecessary tuple construction by doing something like this:
a_list = [1, 2, 3, 4, 5] a, b, * = a_list
lol = [[1, 2], [3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13]] for a, b, * in lol: ...
But that looks a bit bogus - but does avoid having to create the extra tuple. - Dave -- http://www.object-craft.com.au
Greg Ewing wrote:
Having to explicitly slice off the part you want to unpack not only seems inefficient (constructing an intermediate list or tuple just to immediately unpack it and throw it away) it also tends to obfuscate what is going on.
Of course, the proposed syntax does not change this. Compare a,b,c = foo()[:3] to a,b,c,*_ = foo() In either case, the extra fields obfuscate things, and in either case, a second tuple is created. In the latter case, the tuple is even stored in a variable. Regards, Martin
Martin v. Löwis wrote:
Greg Ewing wrote:
Having to explicitly slice off the part you want to unpack not only seems inefficient (constructing an intermediate list or tuple just to immediately unpack it and throw it away) it also tends to obfuscate what is going on.
Of course, the proposed syntax does not change this. Compare
a,b,c = foo()[:3]
That is not really the use case for the feature. What I would really like is a nice way to avoid doing this:
lol = [[1, 2], [3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13]] for tmp in lol: ... a, b = tmp[:2] ... c = tmp[2:]
I think that the original is a nicer looking syntax, and is fairly consistent with the existing "varargs" handling in function signatures.
lol = [[1, 2], [3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13]] for a, b, *c in lol: ...
to
a,b,c,*_ = foo()
In either case, the extra fields obfuscate things, and in either case, a second tuple is created. In the latter case, the tuple is even stored in a variable.
That is not really the use case for the feature. What I would really like is a nice way to avoid doing this:
lol = [[1, 2], [3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13]] for tmp in lol: ... a, b = tmp[:2] ... c = tmp[2:]
Maybe the case of not caring about the rest could be addressed explicitly, e.g. a, b, c, ... = stuff Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
For the record, let me just say that I'm -1 on adding this feature now. It's only a minor convenience while it's a fairly big change to the parser and code generator, but most of all, Python's growth needs to be reduced. If we were to add every "nice" feature that was invented (or present in other languages), Python would lose one of its main charms, which is that it is really a rather simple language that can be learned and put to production quickly. So while I appreciate the idea (which BTW has been proposed before) I think it's not worth adding now, and if you don't hear from me again on this topic it's because I haven't changed my mind... --Guido van Rossum (home page: http://www.python.org/~guido/)
For the record, let me just say that I'm -1 on adding this feature now. It's only a minor convenience while it's a fairly big change to the parser and code generator ...
That is a strong reason to deny the feature request.
... but most of all, Python's growth needs to be reduced. If we were to add every "nice" feature that was invented (or present in other languages), Python would lose one of its main charms, which is that it is really a rather simple language that can be learned and put to production quickly.
However, IMO this reason does not apply to the *arg feature request. Whenever a concept is already in a language, applying the same idea in other places does not make the language fatter or harder to learn. For instance, since generator expressions grow naturally from list comprehensions and regular generators, they are not likely to present a learning challenge.
... I appreciate the idea (which BTW has been proposed before)
IIRC, the conversation for the original proposal fizzled out without reaching a conclusion. So, resuming the discussion was probably a good idea. But now it has been officially zapped. Raymond
Raymond Hettinger wrote:
[Guido]
... I appreciate the idea (which BTW has been proposed before)
IIRC, the conversation for the original proposal fizzled out without reaching a conclusion. So, resuming the discussion was probably a good idea. But now it has been officially zapped.
Actually, it was shot down by Guido last time as well: http://www.python.org/dev/summary/2002-11-16_2002-11-30.html#half-baked-prop... History has spoken! The power of the python-dev Summary and Google's 'site' functionality strikes again! =) -Brett
On Aug 3, 2004, at 2:44 AM, Dave Cole wrote:
a_list = [1, 2, 3, 4, 5] a, b, *c = a_list
While you're proposing expanding the domain of the * construct of function calling to other parts of python, I'd also like to suggest the following features, to make the ** construct also applicable to the rest of the language. To be read with an 70% wink. (I wouldn't be *un*happy if these were in python, but I am not seriously proposing these features for inclusion): Dict unpacking, parallels current sequence unpacking:
d = {'foo': 1, 'bar': 2} {'foo': x, 'bar': y} = d x, y (1, 2)
Dict interpolation, similar to sequence interpolation and keyword interpolation in function calls:
d = {'foo': 1, 'bar': 2} d2 = {'baz': 3, **d} d2 {'baz': 3, 'foo': 1, 'bar': 2}
Combining the two:
d = {'foo': 1, 'bar': 2, 'baz': 3} {'foo': x, 'bar': y, **d2} = d x, y, d2 (1, 2, {'baz': 3})
James
participants (8)
-
"Martin v. Löwis" -
Brett C. -
Dave Cole -
Greg Ewing -
Guido van Rossum -
James Y Knight -
Nick Coghlan -
Raymond Hettinger