classification
Title: pop multiple elements of a list at once
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.2
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: epsilon_da, eric.araujo, jacobidiego, mark.dickinson, rhettinger, terry.reedy
Priority: normal Keywords:

Created on 2010-07-10 19:30 by jacobidiego, last changed 2010-07-23 19:51 by terry.reedy. This issue is now closed.

Messages (6)
msg109912 - (view) Author: Diego Jacobi (jacobidiego) Date: 2010-07-10 19:30
I am currently working with buffer in an USB device and pyusb.
So when i read from a buffer endpoint i get an array.Array() list.
I handle this chunk of data with a thread to send a receive the information that i need. In this thread i load a list with all the information that is read from the USB device, and another layer with pop this information from the threads buffer.

The thing i found is that, to pop a variable chunk of data from this buffer without copying it and deleting the elements, i have to pop one element at the time.

    def get_chunk(self, size):
        for x in range(size):
            yield self.recv_buffer.pop()

I guess that it would be improved if i can just pop a defined number of elements, like this:

pop self.recv_buffer[:size]
or
self.recv_buffer.pop(,-size)

That would be... "pop from the last element minus size to the last element"
in that way there is only one memory transaction.
The new list points to the old memory address and the recv_buffer is advanced to a new address. Data is not moved.

note that i like the idea of using "pop" as the "del" operator for lists

thanks.
Diego
msg109919 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-10 19:51
The python-ideas mailing list might be a better place to discuss this.  Note that it's too late for new features in the 2.x series, so I'm changing the version to 3.2

> pop self.recv_buffer[:size]

I don't think this'll fly, even if you spell it pop(self.recv_buffer[:size]).  It's not worth a new built-in function, let alone a grammar change.

> self.recv_buffer.pop(,-size)

Something like this seems more reasonable, especially if it can be done without introducing new syntax and in a fully backwards-compatible way.

One idea that seems fairly natural to me would be to allow list.pop and friends to support slices, so you could do:

  last2 = slice(None, -2)
  self.recv_buffer.pop(last2)

or even

  penultimate, ultimate = self.recv_buffer.pop(last2)

It would require some work to implement and debug this, though.
msg110027 - (view) Author: Diego (epsilon_da) Date: 2010-07-11 16:54
Help me. I cant find this list. I guessed that it would be a part of
the issue tracker and someone would label it right.

2010/7/11 Éric Araujo <report@bugs.python.org>:
>
> Changes by Éric Araujo <merwok@netwok.org>:
>
>
> ----------
> nosy: +merwok
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue9218>
> _______________________________________
>
msg110028 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-07-11 17:14
python.org → community → mailing lists
http://mail.python.org/mailman/listinfo/python-ideas
msg110072 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-07-12 06:53
-1 on multi-popping.  The semantics aren't obvious -- is the order the same as s[-n:] or the same as a [s.pop() for i in range(n)] ?

Also, this is an unnecessary extension of the list API, one that has not been previously requested, nor is the extension something that other languages find it necessary to implement.  Besides, it already suffices to write:

  result = s[-n:]; del s[-n:]

I recommend that this be rejected in favor of keeping the API relatively small and clean.
msg111378 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-07-23 19:51
I agree with Raymond, as did, I believe, most of the participants in the thread beginning with
http://mail.python.org/pipermail/python-ideas/2010-July/007563.html
History
Date User Action Args
2010-07-23 19:51:02terry.reedysetstatus: open -> closed

nosy: + terry.reedy
messages: + msg111378

resolution: rejected
stage: resolved
2010-07-12 06:53:16rhettingersetnosy: + rhettinger
messages: + msg110072
2010-07-11 17:14:33eric.araujosetmessages: + msg110028
2010-07-11 16:54:05epsilon_dasetnosy: + epsilon_da
messages: + msg110027
2010-07-11 10:24:41eric.araujosetnosy: + eric.araujo
2010-07-10 19:51:22mark.dickinsonsetversions: + Python 3.2, - Python 2.6
nosy: + mark.dickinson

messages: + msg109919

components: + Interpreter Core
type: performance -> enhancement
2010-07-10 19:30:08jacobidiegocreate