<br><br><div class="gmail_quote">On Fri, Mar 2, 2012 at 05:22, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Mar 2, 2012 at 10:55 PM, Stefan Krah <<a href="mailto:stefan@bytereef.org">stefan@bytereef.org</a>> wrote:<br>
> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>> However, given the lack of control, an assert() isn't the appropriate<br>
>> tool here - PyObject_GetBuffer itself should be *checking* the<br>
>> constraint and then reporting an error if the check fails. Otherwise a<br>
>> misbehaving extension module could trivially crash the Python<br>
>> interpreter by returning a bad Py_buffer.<br>
><br>
> I'm not so sure. Extension modules that use the C-API in wrong or<br>
> undocumented ways can always crash the interpreter. This assert()<br>
> should be triggered in the first unit test of the module. Now, if<br>
> the module does not have unit tests or they don't test against a<br>
> new Python version is that really our problem?<br>
<br>
</div>Crashing out with a C assert when we can easily give them a nice<br>
Python traceback instead is unnecessarily unfriendly.</blockquote><div><br></div><div>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.</div>
<div><br></div></div>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!<br>