Since PEP 3132 gives us:
x = [1,2,3] a, *b = x a 1 b [2, 3]
it seems natural that we should be able to do it the other way too: (doesn't actually work)
a, b = 1, [2,3] x = [a,*b] x [1, 2, 3]
This is essentially itertools.chain, but of course it isn't nearly as much fun:
[n for n in itertools.chain([1],[2,3])] [1, 2, 3]
Now you might be thinking, "yeah, that's cool, but you don't really need it" but this actually came up in practice: I have a function that has a certain behavior for standard types, but when it sees a type it doesn't recognize, it calls a protocol function (like __iter__ or __next__) and expects to receive an iterable whose 0th element is a string. Now I'm probably not going to use itertools.chain because the only members of itertools I can reliably remember are count() and izip(), so my next alternative (which is perfectly acceptable) is
a, b = 1, [2,3] x = [a] + b
This isn't too bad, but it is slightly less clear than x = [a,*b] and much less efficient when b is long. It seems so simple...makes me think it came up before and I missed it. David
On 26 Jun 2008, at 05:36, David Pokorny wrote:
Since PEP 3132 gives us:
x = [1,2,3] a, *b = x a 1 b [2, 3]
it seems natural that we should be able to do it the other way too:
(doesn't actually work)
a, b = 1, [2,3] x = [a,*b] x [1, 2, 3]
This is essentially itertools.chain, but of course it isn't nearly as much fun:
[n for n in itertools.chain([1],[2,3])] [1, 2, 3]
Now you might be thinking, "yeah, that's cool, but you don't really need it" but this actually came up in practice: I have a function that has a certain behavior for standard types, but when it sees a type it doesn't recognize, it calls a protocol function (like __iter__ or __next__) and expects to receive an iterable whose 0th element is a string. Now I'm probably not going to use itertools.chain because the only members of itertools I can reliably remember are count() and izip(), so my next alternative (which is perfectly acceptable) is
a, b = 1, [2,3] x = [a] + b
This isn't too bad, but it is slightly less clear than x = [a,*b] and much less efficient when b is long.
What makes you think it is much less efficient? -- Arnaud
There is even a patch for this. http://bugs.python.org/issue2292
It is a very complex piece of code though and due to lack of time will
not make it into 3.0. (And no, if someone picks up the work now I
still won't let it into 3.0 -- we need to stabilize the release. There
will always be 3.1.)
On Wed, Jun 25, 2008 at 9:36 PM, David Pokorny
Since PEP 3132 gives us:
x = [1,2,3] a, *b = x a 1 b [2, 3]
it seems natural that we should be able to do it the other way too:
(doesn't actually work)
a, b = 1, [2,3] x = [a,*b] x [1, 2, 3]
This is essentially itertools.chain, but of course it isn't nearly as much fun:
[n for n in itertools.chain([1],[2,3])] [1, 2, 3]
Now you might be thinking, "yeah, that's cool, but you don't really need it" but this actually came up in practice: I have a function that has a certain behavior for standard types, but when it sees a type it doesn't recognize, it calls a protocol function (like __iter__ or __next__) and expects to receive an iterable whose 0th element is a string. Now I'm probably not going to use itertools.chain because the only members of itertools I can reliably remember are count() and izip(), so my next alternative (which is perfectly acceptable) is
a, b = 1, [2,3] x = [a] + b
This isn't too bad, but it is slightly less clear than x = [a,*b] and much less efficient when b is long.
It seems so simple...makes me think it came up before and I missed it.
David _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Jun 25, 11:06 pm, Arnaud Delobelle
What makes you think it is much less efficient?
AFAIK the intermediate list is discarded immediately after being constructed. I think the main thing the generalized star expression has going for it is aesthetic value, "cool" factor, and less keyboard typing. David
participants (4)
-
Arnaud Delobelle -
David Pokorny -
dbpokorny＠gmail.com
-
Guido van Rossum