> Scott Gilbert wrote: > > >Tonight, I remember another thought that I've had for a while. > > > >There isn't currently a way for a class object created from Python script > >to indicate that it wishes to implement the buffer interface. In the > >Numeric source, I've seen them use self.__buffer__ for this purpose, but > >this isn't actually an officially sanctioned magic name. > > > > > >I'm thinking one of: > > > > class OneWay(object): > > def __init__(self): > > self.__buffer__ = bytes(1000) > > > >Or: > > > > class SomeOther(object): > > def __init__(self): > > self._private = bytes(1000) > > def __buffer__(self): > > return self._private > > > >I believe the first one is the way it's done in Numeric (Numarray too?). [Todd Miller] > The numarray C-API essentially supports both usages, although we only > use the __buffer__ name in the second case. > > > > >(Maybe Todd Miller will comment on this and whether it's useful to him.) > > > Yes, it is useful for prototyping. Numarray calls a __buffer__() > method to support python class wrappers around mmap. We use our class > wrappers around mmap to add the ability to chop a file up into > non-overlapping resizeable slices. Each slice can be used as the buffer > of an independent memory mapped array. This would be easy enough to add, I suppose, but (a) I don't think it's got much to do with PEP 298, and (b) let's wait until we have a real use case, so perhaps we can decide which form it should take. Until then, I call YAGNI. --Guido van Rossum (home page: http://www.python.org/~guido/)
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