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) = *
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 o
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)
Che
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 r
Steve Holden writes:
> 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.
>
> This would allow users to provide an arbitr
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:
Steve Holden wrote:
> But don't forget that at present unpacking can be used at several levels:
>
> >>> ((a, b), c) = ((1, 2), 3)
> >>> a, b, c
> (1, 2, 3)
> >>>
>
> So presumably you'd need to be able to say
>
>((a, *b), c, *d) = ((1, 2, 3), 4, 5, 6)
>
> and see
>
>a, b, c, d == 1,
Steve Holden wrote:
> So presumably you'd need to be able to say
>
>((a, *b), c, *d) = ((1, 2, 3), 4, 5, 6)
Yes.
>a, *b = [1]
>
> to put the empty list into b, or is that an unpacking error?
Empty sequence in b (of whatever type is chosen).
> does this mean that you'd also like to b
Nick Coghlan wrote:
> I'm also trying to figure out why you would ever write:
>[a, b, c, d] = seq
I think the ability to use square brackets is a
holdover from some ancient Python version where you had
to match the type of the thing being unpacked with
the appropriate syntax on the lhs. It wa
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 itera
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.
>
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
comp
(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:
> 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 iterabl
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 r
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.
>
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
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
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 lo
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
>>v
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?
Tim Delaney
___
Python-
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
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(
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
Fred L. Drake, Jr. wrote:
> 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 indi
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 collective
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
> 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 pr
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:
> pa
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 othe
30 matches
Mail list logo
