On Thu, Mar 17, 2011 at 1:48 PM, Vitja Makarov <vitja.maka...@gmail.com> wrote: > 2011/3/17 Robert Bradshaw <rober...@math.washington.edu>: >> On Thu, Mar 17, 2011 at 6:15 AM, Jason Grout >> <jason-s...@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...@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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
