[Python-Dev] I'd like list.pop to accept an optional second

Tim Peters tim_one@email.msn.com
Fri, 23 Jul 1999 22:16:16 -0400

> ...
> Hmm, so maybe we're not after lists after all: maybe what
> we need is access to the global interpreter lock in Python,
> so that we can write:
> sys.lock.acquire()
> if list:
>         obj = list.pop()
> else:
>         obj = default
> sys.lock.release()

The thread attempting the sys.lock.acquire() necessarily already owns the
global lock, so the attempt to acquire it is a guaranteed deadlock --
arguably not helpful <wink>.

> Or maybe we need some general lock in the thread module for these
> purposes... don't know. It's been some time since I used
> threads.

Jim could easily allocate a list lock for this purpose if that's what he
wanted; and wrap it in a class with a nice interface too.  He'd eventually
end up with the std Queue.py module, though.

But if he doesn't want the overhead of an exception when the queue is empty,
he sure doesn't want the comparatively huge overhead of a (any flavor of)
lock either (which may drag the OS into the picture).

There's nothing wrong with wanting a fast thread-safe queue!  I just don't
like the idea of adding an otherwise-ugly new gimmick to core lists for it;
also have to wonder about Jim's larger picture if he's writing stuff in
Python that's *so* time-critical that the overhead of an ordinary exception
from time to time is a genuine problem.  The verbosity of the alternative
can be hidden in a lock-free class or function, if it's the clumsiness
instead of the time that's grating.