Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Rats! vararg assignments don't work

Reply
Thread Tools

Rats! vararg assignments don't work

 
 
samwyse
Guest
Posts: n/a
 
      05-30-2007
I'm a relative newbie to Python, so please bear with me. After seeing
how varargs work in parameter lists, like this:
def func(x, *arglist):
and this:
x = func(1, *moreargs)
I thought that I'd try this:
first, *rest = arglist
Needless to say, it didn't work. That leaves me with two questions.

First, is there a good way to do this? For now, I'm using this:
first, rest = arglist[0], arglist[1:]
but it leaves a bad taste in my mouth.

Second, is there any good reason why it shouldn't work? It seems like
such an obvious idiom that I can't believe that I'm the first to come up
with the idea. I don't really have the time right now to go source
diving, so I can't tell if it would be wildly inefficient to implement.

Thanks!
 
Reply With Quote
 
 
 
 
Matimus
Guest
Posts: n/a
 
      05-30-2007
Your attemtp:

Code:
first, rest = arglist[0], arglist[1:]
Is the most obvious and probably the most accepted way to do what you
are looking for. As for adding the fucntionality you first suggested,
it isn't likely to be implemented. The first step would be to write a
PEP though. Remember, in Python "there is only one way to do it". So,
unless you can come up with a valid use case where that syntax allows
you to do something that wasn't possible before, I wouldn't count on
getting much support.


 
Reply With Quote
 
 
 
 
George Sakkis
Guest
Posts: n/a
 
      05-30-2007
On May 29, 11:33 pm, Matimus <(E-Mail Removed)> wrote:

> Your attemtp:
>
>
Code:
> first, rest = arglist[0], arglist[1:]
>
>
> Is the most obvious and probably the most accepted way to do what you
> are looking for. As for adding the fucntionality you first suggested,
> it isn't likely to be implemented. The first step would be to write a
> PEP though.


The time machine did it again: http://www.python.org/dev/peps/pep-3132/.

George

 
Reply With Quote
 
Gary Herron
Guest
Posts: n/a
 
      05-30-2007
samwyse wrote:
> I'm a relative newbie to Python, so please bear with me. After seeing
> how varargs work in parameter lists, like this:
> def func(x, *arglist):
> and this:
> x = func(1, *moreargs)
> I thought that I'd try this:
> first, *rest = arglist
> Needless to say, it didn't work. That leaves me with two questions.
>
> First, is there a good way to do this? For now, I'm using this:
> first, rest = arglist[0], arglist[1:]
> but it leaves a bad taste in my mouth.
>

Well, your moreargs parameter is a tuple, and there are innumerable ways
to process a tuple. (And even more if you convert it to a list.)

If you are just interested in extracting only the first arg, then your
code is quite Pythonic. However, if you are going to do that in a loop
to successively process each arg, the you have several better options:

For instance:
for arg in moreargs: # Loop through each arg
<do something with arg>

or

for i in range(len(moreargs)):
<do something with morergs[i]> # Extract ith arg

or

argslist = list(moreargs)
while argslist:
firstarg = argslist.pop(0) # Extract first arg
<do something with firstarg>

Gary Herron

> Second, is there any good reason why it shouldn't work? It seems like
> such an obvious idiom that I can't believe that I'm the first to come up
> with the idea. I don't really have the time right now to go source
> diving, so I can't tell if it would be wildly inefficient to implement.
>
> Thanks!
>


 
Reply With Quote
 
samwyse
Guest
Posts: n/a
 
      05-30-2007
Gary Herron wrote:
> samwyse wrote:
>
>>I'm a relative newbie to Python, so please bear with me. After seeing
>>how varargs work in parameter lists, like this:
>> def func(x, *arglist):
>>and this:
>> x = func(1, *moreargs)
>>I thought that I'd try this:
>> first, *rest = arglist
>>Needless to say, it didn't work. That leaves me with two questions.
>>
>>First, is there a good way to do this? For now, I'm using this:
>> first, rest = arglist[0], arglist[1:]
>>but it leaves a bad taste in my mouth.
>>

>
> Well, your moreargs parameter is a tuple, and there are innumerable ways
> to process a tuple. (And even more if you convert it to a list.)


My use-case is (roughtly) this:
first, *rest = f.readline().split()
return dispatch_table{first}(*rest)
 
Reply With Quote
 
samwyse
Guest
Posts: n/a
 
      05-30-2007
George Sakkis wrote:
> On May 29, 11:33 pm, Matimus <(E-Mail Removed)> wrote:
>
>
>>Your attemtp:
>>
>>
Code:
>>first, rest = arglist[0], arglist[1:]
>>
>>
>>Is the most obvious and probably the most accepted way to do what you
>>are looking for. As for adding the fucntionality you first suggested,
>>it isn't likely to be implemented. The first step would be to write a
>>PEP though.

>
>
> The time machine did it again: http://www.python.org/dev/peps/pep-3132/.


Thanks! Now I just need to wait for Py3K and all of my problems will be
solved.

Actually, I'm surprised that the PEP does as much as it does. If tuples
are implemented as S-expressions, then something like this:
car, *cdr = tuple
while leaving cdr a tuple would be trivial to implement. Of course, I'm
an old-school LISPer, so what I consider surprising behavior doesn't
always surprise anyone else, and vice versa.
 
Reply With Quote
 
Wildemar Wildenburger
Guest
Posts: n/a
 
      05-30-2007
George Sakkis wrote:
> The time machine did it again: http://www.python.org/dev/peps/pep-3132/.
>
>


Uhm, John Swartzwelder, right?


/W
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      05-30-2007
Matimus a écrit :
(snip)
> Remember, in Python "there is only one way to do it".


Actually, it's :
"There should be one-- and preferably only one --obvious way to do it.".

.... Which is quite different. Please notice the "should", "preferably"
and "obvious".
 
Reply With Quote
 
Maric Michaud
Guest
Posts: n/a
 
      05-30-2007
samwyse a écrit :
> George Sakkis wrote:
>> On May 29, 11:33 pm, Matimus <(E-Mail Removed)> wrote:
>>
>>
>>> Your attemtp:
>>>
>>>
Code:
>>> first, rest = arglist[0], arglist[1:]
>>>
>>>
>>> Is the most obvious and probably the most accepted way to do what you
>>> are looking for. As for adding the fucntionality you first suggested,
>>> it isn't likely to be implemented. The first step would be to write a
>>> PEP though.

>>
>> The time machine did it again: http://www.python.org/dev/peps/pep-3132/.

>
> Thanks! Now I just need to wait for Py3K and all of my problems will be
> solved.
>
> Actually, I'm surprised that the PEP does as much as it does. If tuples
> are implemented as S-expressions, then something like this:
> car, *cdr = tuple
> while leaving cdr a tuple would be trivial to implement. Of course, I'm
> an old-school LISPer, so what I consider surprising behavior doesn't
> always surprise anyone else, and vice versa.


Remember all these are copies of the original sequence, the lisp
equivalent to car/cdr is feasible with an iterator :

it = iter(seq)
car, cdr = it.next(), it

 
Reply With Quote
 
Sion Arrowsmith
Guest
Posts: n/a
 
      05-30-2007
samwyse <(E-Mail Removed)> wrote:
>> samwyse wrote:
>>>I thought that I'd try this:
>>> first, *rest = arglist
>>>Needless to say, it didn't work.

> [ ... ]
>My use-case is (roughtly) this:
> first, *rest = f.readline().split()
> return dispatch_table{first}(*rest)


first, rest = f.readline().split(None, 1)
return dispatch_table{first}(*rest.split())

--
\S -- http://www.velocityreviews.com/forums/(E-Mail Removed) -- http://www.chaos.org.uk/~sion/
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Detecting mismatch of format string & parameters to vararg function Mister B C Programming 5 05-15-2009 02:10 PM
Inheritance of overloaded vararg methods RobertEstelle@gmail.com C++ 8 12-17-2007 12:06 AM
Ruby extension with vararg function woes. alterego@sdf.lonestar.org Ruby 3 07-25-2007 05:12 PM
[RDOC] patch for vararg require Jamis Buck Ruby 2 11-04-2004 03:09 PM
why doesn't this work? final assignments and switches xaos Java 7 04-18-2004 08:35 PM



Advertisments