On Fri, Mar 2, 2012 at 10:55 PM, Stefan Krah <stefan at bytereef.org> wrote: > Nick Coghlan <ncoghlan at gmail.com> wrote: >> However, given the lack of control, an assert() isn't the appropriate >> tool here - PyObject_GetBuffer itself should be *checking* the >> constraint and then reporting an error if the check fails. Otherwise a >> misbehaving extension module could trivially crash the Python >> interpreter by returning a bad Py_buffer. > > I'm not so sure. Extension modules that use the C-API in wrong or > undocumented ways can always crash the interpreter. This assert() > should be triggered in the first unit test of the module. Now, if > the module does not have unit tests or they don't test against a > new Python version is that really our problem? Crashing out with a C assert when we can easily give them a nice Python traceback instead is unnecessarily unfriendly. As Stefan Behnel pointed out, by tightening up the API semantics, we're already running the risk of breaking applications that relied on looking at what the old code *did*, since it clearly deviated from both spec (the PEP) and the documentation (which didn't explain how ReleaseBuffer works at all). > Modules do need to be recompiled anyway due to the removal of > Py_buffer.smalltable, otherwise they will almost certainly crash. > Perhaps an addition to whatsnew/3.3 would be sufficient. That, updating the 2.7 and 3.2 docs with a reference to the fleshed out 3.3 semantics and converting the assert() to a Python exception should cover it. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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