Ron Adam wrote:
I wonder if you make '*' work outside of functions arguments lists, if
requests to do the same for '**' would follow?
Only if keyword unpacking were to be permitted elsewhere first. That is:
Py data = dict(a=1, b=2, c=3)
Py (a, b, c) = **data
Py print a, b, c
(1, 2, 3)
Cheers,
Michael Chermside wrote:
Guido writes:
I've always wanted to write that as
f(a, b, *args, foo=1, bar=2, **kwds)
but the current grammar doesn't allow it.
Hmm why doesn't the current grammar allow it, and can we fix that?
I don't see that it's a limitation of the
Nick Coghlan wrote:
Ron Adam wrote:
I wonder if you make '*' work outside of functions arguments lists, if
requests to do the same for '**' would follow?
Only if keyword unpacking were to be permitted elsewhere first. That is:
Py data = dict(a=1, b=2, c=3)
Py (a, b, c) = **data
Py
Ron Adam wrote:
I wonder if something like the following would fulfill the need?
Funny you should say that. . .
A pre-PEP propsing itertools.iunpack (amongst other things):
http://mail.python.org/pipermail/python-dev/2004-November/050043.html
And the reason that PEP was never actually created:
Nick Coghlan wrote:
Ron Adam wrote:
I wonder if something like the following would fulfill the need?
Funny you should say that. . .
A pre-PEP propsing itertools.iunpack (amongst other things):
http://mail.python.org/pipermail/python-dev/2004-November/050043.html
And the reason that
Ron Adam wrote:
My concern is if it's used outside of functions, then on the left hand
side of assignments, it will be used to pack, but if used on the right
hand side it will be to unpack.
I don't see why that should be any more confusing than the
fact that commas denote tuple packing on
Guido van Rossum wrote:
BTW, what should
[a, b, *rest] = (1, 2, 3, 4, 5)
do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
Whatever type is chosen, it should be the same type, always.
The rhs could be any iterable, not just a tuple or a list.
Making a special case of preserving one
Greg Ewing wrote:
Guido van Rossum wrote:
BTW, what should
[a, b, *rest] = (1, 2, 3, 4, 5)
do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
Whatever type is chosen, it should be the same type, always.
The rhs could be any iterable, not just a tuple or a list.
Making a special
Nick Coghlan wrote:
For me, it stops when the rules for positional name binding are more
consistent across operations that bind names (although complete consistency
isn't possible, given that function calls don't unpack sequences
automatically).
Oops - forgot to delete this bit once I
Nick Coghlan wrote:
Greg Ewing wrote:
Guido van Rossum wrote:
BTW, what should
[a, b, *rest] = (1, 2, 3, 4, 5)
do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
Whatever type is chosen, it should be the same type, always.
The rhs could be any iterable, not just a tuple or a list.
(my own 2 eurocents)
I do feel that for Python 3 it might be better to make a clean
separation between keywords and positionals: in other words, of the
function definition specifies a keyword argument then a keyword must be
used to present it.
Do you mean it would also be forbidden to
Nick Coghlan wrote:
So my vote would actually go for deprecating the use of square brackets to
surround an assignment target list - it makes it look like an actual list
object should be involved somewhere, but there isn't one.
I've found myself using square brackets a few times for more
Greg Ewing wrote:
Guido van Rossum wrote:
BTW, what should
[a, b, *rest] = (1, 2, 3, 4, 5)
do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
Whatever type is chosen, it should be the same type, always.
The rhs could be any iterable, not just a tuple or a list.
Making a
Reinhold Birkenfeld wrote:
Greg Ewing wrote:
Guido van Rossum wrote:
BTW, what should
[a, b, *rest] = (1, 2, 3, 4, 5)
do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
Whatever type is chosen, it should be the same type, always.
The rhs could be any iterable, not just a tuple or a
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
It also works for situations where the first n items are mandatory, the rest
are optional. This usage was brought up in the context of a basic line
interpreter:
cmd, *args = input.split()
That's a really poor example though. You really
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
cmd, *args = input.split()
These examples also have a reasonable implementation using list.pop(),
albeit one that requires more typing. On the plus side, it does not violate
DRY and is explicit about the error cases.
args = input.split()
Paul Du Bois wrote:
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
cmd, *args = input.split()
These examples also have a reasonable implementation using list.pop(),
albeit one that requires more typing. On the plus side, it does not
violate
DRY and is explicit about the error
Delaney, Timothy (Tim) wrote:
args = input.split()
try:
cmd = arg.pop()
^^^ args ...
except IndexError:
cmd = ''
Can't even get it right myself - does that prove a point? wink
Tim Delaney
___
Delaney, Timothy (Tim) wrote:
Paul Du Bois wrote:
On 10/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
cmd, *args = input.split()
These examples also have a reasonable implementation using list.pop(),
albeit one that requires more typing. On the plus side, it does not
violate
DRY and is
On 10/10/05, Ron Adam [EMAIL PROTECTED] wrote:
The problem is the '*' means different things depending on where it's
located. In a function def, it means to group or to pack, but from the
calling end it's used to unpack. I don't expect it to change as it's
been a part of Python for a long
Guido van Rossum wrote:
I personally think this is adequately handled by writing:
(first, second), rest = something[:2], something[2:]
That's less than satisfying because it violates DRY
three times (once for mentioning 'something' twice,
once for mentioning the index twice, and once for
On Sunday 09 October 2005 22:44, Greg Ewing wrote:
I'm aware of the differences, but I still see a strong
similarity where this particular feature is concerned.
The pattern of thinking is the same: I want to deal
with the first n of these things individually, and the
rest collectively.
Not sure if this has been proposed before, but one thing
I occasionally miss regarding tuple unpack is being able
to do:
first, second, *rest = something
Also in for loops:
for first, second, *rest in iterator:
pass
This seems to match the current meaning for starred
variables in
On 10/7/05, Gustavo Niemeyer [EMAIL PROTECTED] wrote:
Not sure if this has been proposed before, but one thing
I occasionally miss regarding tuple unpack is being able
to do:
first, second, *rest = something
Also in for loops:
for first, second, *rest in iterator:
pass
This
Someone should really write up a PEP -- this was just discussed a week
or two ago.
Heh.. I should follow the list more closely.
I personally think this is adequately handled by writing:
(first, second), rest = something[:2], something[2:]
That's an alternative indeed. But the the
25 matches
Mail list logo
