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. Now that classes can derive from builtin types, perhaps there is less of a need for this, but I still think we would want it. There are times when you want inheritance, and others when you want containment. With a slight modification to the PyObject_*Buffer functions (in the failure branches), an instance of a class could use containment of a PyBufferProcs supporting object and publish the buffer interface as its own. 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?). (Maybe Todd Miller will comment on this and whether it's useful to him.) If this is worthwhile, it could be added to PEP 298 or as a new mini PEP. In either case, I'm willing to do the work. Cheers, -Scott __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
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?).
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. Todd
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/)
participants (3)
-
Guido van Rossum -
Scott Gilbert -
Todd Miller