[Cython] Out of order side effects of argument evaluation in function calls (ticket #654)

Robert Bradshaw 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>
>>>>  wrote:
>>>>>
>>>>> 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
>>>>> around
>>>>> 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
>>>>> write
>>>>> 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.)

- Robert


More information about the cython-devel mailing list