> > I don't like where this is going. Let's not add locking to the buffer > > protocol. > > Do you still object to it even in the form I proposed in > my last message? (I.e. no separate "lock" call, locking > is implicit in the getxxxbuffer calls.) Yes, I still object. Having to make a call to release a resource with a function call is extremely error-prone, as we've seen with reference counting. There are too many cases where some early exit from a piece of code doesn't make the release call. > It does make the protocol slightly more complicated to > use (must remember to make a release call when you're > finished with the pointer) but it seems like a good > tradeoff to me for the flexibility gained. I'm not sure I see the use case. The main data types for which I expect this will be used would be strings and the new 'bytes' type, and both have fixed buffers that never move. > > probably nothing that could possibly invoke the Python interpreter > > recursively, since that might release the GIL. This would generally > > mean that calls to Py_DECREF() are unsafe while holding on to a buffer > > pointer! > > That could be fixed by incrementing the Python refcount as > long as a pointer is held. That could be done even without > the rest of my locking proposal. Of course, if you do that you > need a matching release call, so you might as well implement > the locking while you're at it. I think you misunderstand what I wrote. A py_DECREF() for an *unrelated* object can invoke Python code (if it ends up deleting a class instance with a __del__ method). --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