Rats! vararg assignments don't work

Discussion in 'Python' started by samwyse, May 30, 2007.

  1. samwyse

    samwyse Guest

    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!
     
    samwyse, May 30, 2007
    #1
    1. Advertising

  2. samwyse

    Matimus Guest

    Re: Rats! vararg assignments don't work

    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.
     
    Matimus, May 30, 2007
    #2
    1. Advertising

  3. Re: Rats! vararg assignments don't work

    On May 29, 11:33 pm, Matimus <> 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
     
    George Sakkis, May 30, 2007
    #3
  4. samwyse

    Gary Herron Guest

    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> # 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!
    >
     
    Gary Herron, May 30, 2007
    #4
  5. samwyse

    samwyse Guest

    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)
     
    samwyse, May 30, 2007
    #5
  6. samwyse

    samwyse Guest

    Re: Rats! vararg assignments don't work

    George Sakkis wrote:
    > On May 29, 11:33 pm, Matimus <> 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.
     
    samwyse, May 30, 2007
    #6
  7. Wildemar Wildenburger, May 30, 2007
    #7
  8. Re: Rats! vararg assignments don't work

    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".
     
    Bruno Desthuilliers, May 30, 2007
    #8
  9. Re: Rats! vararg assignments don't work

    samwyse a écrit :
    > George Sakkis wrote:
    >> On May 29, 11:33 pm, Matimus <> 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
     
    Maric Michaud, May 30, 2007
    #9
  10. samwyse <> 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.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
     
    Sion Arrowsmith, May 30, 2007
    #10
  11. Re: Rats! vararg assignments don't work

    samwyse <> wrote:
    ...
    > Actually, I'm surprised that the PEP does as much as it does. If tuples
    > are implemented as S-expressions, then something like this:


    Tuples are implemented as compact arrays of pointer-to-PyObject (so are
    lists, BTW). So, for example, a 10-items tuple takes 40 bytes (plus a
    small overhead for the header) on a 32-bit build, not 80 as it would if
    implemented as a linked list of (pointer-to-object, pointer-to-next)
    pairs; addressing sometuple[N] is O(1), NOT O(N); etc, etc.


    Alex
     
    Alex Martelli, May 30, 2007
    #11
  12. samwyse

    samwyse Guest

    Re: Rats! vararg assignments don't work

    On May 30, 7:29 am, Sion Arrowsmith <>
    wrote:
    > samwyse <> wrote:
    > >>samwysewrote:
    > >>>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())


    Hey, I like that! Thanks!
     
    samwyse, Jul 12, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. xaos
    Replies:
    7
    Views:
    2,119
  2. Replies:
    8
    Views:
    367
  3. Mister B
    Replies:
    5
    Views:
    731
    Kenny McCormack
    May 15, 2009
  4. Jamis Buck

    [RDOC] patch for vararg require

    Jamis Buck, Nov 4, 2004, in forum: Ruby
    Replies:
    2
    Views:
    120
    Jamis Buck
    Nov 4, 2004
  5. Replies:
    3
    Views:
    175
    Phlip
    Jul 25, 2007
Loading...

Share This Page