--- Thomas Heller <thomas.heller@ion-tof.com> wrote: > From: "Scott Gilbert" <xscottg@yahoo.com> > > --- Thomas Heller <thomas.heller@ion-tof.com> wrote: > > > What if we would 'fix' the buffer interface? > > > > > For one I, and people more significant than me, would still need a > > type that implemented the bytes object behavior. > > Sure, the extension of the buffer interface is only part of the > picture. The bytes type is still needed as well. > > The extension I proposed is motivated by these thoughts: > > It would enable some of Python's builtin objects to > expose the interface extension by supplying two > trivial functions for each in the extended tp_as_buffer slot. > > The new functions expose a 'safe buffer interface', where > there are guarantees about the lifetime of the pointer. So > your bytes object can be a view of these builtin objects > as well. > > It dismisses the segment count of the normal buffer interface. > [...] > > > > I've been trying to keep the proposal as unintrusive as possible while > > still implementing the functionality needed. Adding more flags/members > > to PyObjects and modifying string, unicode, mmap, ... feels like a more > > intrusive change to me. I'm open to the idea, but I'm not ready to > > retract the current proposal. Then there is still the problem of > > needing something like a bytes object as mentioned above. > > The advantage (IMO) is that it defines a new protocol to get the > pointer to the internal byte array on objects instead of > requiring that these objects are instances of a special type > or subtype thereof. > I like your idea for adding the flags and methods to create a "safe buffer interface". As you note, string, unicode, mmap, and possibly other things could implement these methods and return a (possibly large) pointer that could be manipulated after the GIL is released. Of course the pickleable bytes object falls into that category too. It seems to me that we have two independant proposals. Do you see any reason why they shouldn't be two separate PEPs? I don't see any reason to piggyback them into one. They're related in topic, but neither seems to rely on the other in any way. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
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