> I would like to use (again) the buffer interface, > and I have some suggestions/questions. > > - Only extension types can implement the buffer interface, > no way for a python class. Maybe a magic method __buffer__(self) > could be invented for this purpose? How could it be made safe? The buffer interface makes raw memory addresses available. Letting a Python class decide on what addresses to use opens a big hole for abuse. > - Why does the builtin function buffer() always return > readonly buffers, even for read/write objects? Shouldn't > there also be a readwrite_buffer() function, or should > buffer() return read/write buffers for read/write objects? It's a lifetime issue. You can hold on to the object returned by buffer() long after the actual memory it points to is recycled for some other purpose, and while *reading* that memory is not such a big deal (assuming it is still part of your address space, you'll just get garbage), allowing it to be *written* is again an invitation to disaster. > - My bug report 216405 on sourceforge is still open > (well, it is marked as closed, but it went into PEP 42) > http://sourceforge.net/tracker/index.php?func=detail&aid=216405&group_id=5470&atid=105470 I still feel that your bug report is based on the wrong assumption about what the buffer API should do. Thomas, please first explain what you want to *do* with the buffer interface. Some of the buffer API was a mistake. It *appears* to be an interface for allocating and managing buffers, while in actuality it is only intended to provide access to buffered data that is managed by some C code. You're probably better off using the array module to manage buffers. --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