[Python-Dev] Assertion in _PyManagedBuffer_FromObject() (original) (raw)
Thomas Wouters thomas at python.org
Fri Mar 2 20:11:30 CET 2012
- Previous message: [Python-Dev] Assertion in _PyManagedBuffer_FromObject()
- Next message: [Python-Dev] Compiling Python on Linux with Intel's icc
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Mar 2, 2012 at 05:22, Nick Coghlan <ncoghlan at gmail.com> wrote:
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 - PyObjectGetBuffer 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 Pybuffer. > > 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.
But you should keep in mind that for non-debug builds, asserts are generally off. So the behaviour most people see isn't actually a crash, but silent acceptance.
-- Thomas Wouters <thomas at python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120302/ebc13fc7/attachment.html>
- Previous message: [Python-Dev] Assertion in _PyManagedBuffer_FromObject()
- Next message: [Python-Dev] Compiling Python on Linux with Intel's icc
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]