[Cython] Out of order side effects of argument evaluation in function calls (ticket #654)
robertwb at math.washington.edu
Thu Mar 17 21:57:06 CET 2011
On Thu, Mar 17, 2011 at 1:48 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/3/17 Robert Bradshaw <robertwb at math.washington.edu>:
>> On Thu, Mar 17, 2011 at 6:15 AM, Jason Grout
>> <jason-sage at creativetrax.com> wrote:
>>> On 3/16/11 11:05 PM, Robert Bradshaw wrote:
>>>> On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel<stefan_ml at behnel.de>
>>>>> I'm actually leaning towards not guaranteeing the order of execution if C
>>>>> doesn't do it either. If this is really required, it's easy to work
>>>>> for users, but it's severely hard to fix for Cython in all cases, and the
>>>>> gain is truly small. After all, we'd only make it easier for users to
>>>>> bad code.
>>>> Yep. Lets keep the code in for the above case.
>>> Is there a huge big warning in the docs? Maybe on this page would be a good
>>> place: http://docs.cython.org/src/userguide/limitations.html
>> This doesn't affect Python functions at all, so I'm not sure it
>> belongs on that page. I agree that it should be mentioned that c(p)def
>> functions have C calling semantics, *including* an unspecified order
>> or argument evaluation.
> As you noticed above, how should be handled def function inlining?
> I guess there are restrictions on def function argument type, so
> side-effect isn't issue here.
Yep, or at least not near as much of an issue. (I think the C compiler
can optimize away an, e.g, extra copy of, e.g, int, double and
PyObject* temps in most cases.)
More information about the cython-devel