A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-December/031155.html below:

[Python-Dev] PEP 298

[Python-Dev] PEP 298Martin v. Löwis martin@v.loewis.de
14 Dec 2002 08:56:30 +0100
Scott Gilbert <xscottg@yahoo.com> writes:

> > # Retrieving a buffer from an object puts this object in a locked
> > # state during which the buffer may not be freed, resized, or
> > # reallocated.
> 
> The wording may not be specific enough, but the idea is that you can lock a
> buffer object and should (must) unlock it later.  

That is the flaw. It shouldn't tell me what I have to do, but instead
it should tell me what happens if I don't. If I don't unlock the
buffer, I would expect that it stays locked. Now it turns out that the
buffer can actually go away while being locked.

> > If it is just the interface, I'm -1. You don't need a PEP to define an
> > interface in Python - just establish an interface in the types you
> > care about. 
> 
> There are several types I care about which are out of my control: string,
> array, mmap, Numeric.array.

I see. So this is more than just the interface: your requirement is
that these types also implement it. Of course, Numeric.array is
somewhat out of control of the PEP.

If that is so, I'm -0: I still would like to see it become useful on
the Python level, i.e. the buffer object should somehow expose it.

Regards,
Martin




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4