On Thu, Mar 17, 2011 at 1:48 PM, Vitja Makarov <[email protected]> wrote: > 2011/3/17 Robert Bradshaw <[email protected]>: >> On Thu, Mar 17, 2011 at 6:15 AM, Jason Grout >> <[email protected]> wrote: >>> On 3/16/11 11:05 PM, Robert Bradshaw wrote: >>>> >>>> On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel<[email protected]> >>>> 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 _______________________________________________ cython-devel mailing list [email protected] http://mail.python.org/mailman/listinfo/cython-devel
