On Nov 27, 2008, at 12:46 PM, Dag Sverre Seljebotn wrote: > Stefan Behnel wrote: >> Hi, >> >> Dag Sverre Seljebotn wrote: >>> When implementing inlineable functions, I saw that there's code in >>> PxdPostParse to enable this kind of code: >>> >>> cdef int foo(int a, int b): >>> cdef int c >>> cdef int d >>> >>> in a pxd file, in order to set "pxd_locals". As soon as some real >>> code >>> is added the code is disallowed. >>> >>> What is the purpose? It does conflict a bit with the inline >>> syntax (not >>> for real but mentally). I have a feeling Robert added this as a >>> feature >>> for something but what the feature is escapes me... >> >> I think that's for overriding the code in .py files, so that you >> can use >> plain Python code without type declarations, and just add a .pxd >> file next >> to it for efficient C compilation. > > Ahh.
Yes, that's exactly why I introduced it. Python 2.3 doesn't have decorators, so we can't use them in bootstrapping the Cython compiler for instance. > This kind of makes me worry, syntax-wise, as it collides with inline > cdef functions. (And, I must admit, I have now accidentally, through > overlaying my syntax, removed the possibility to specify that a > function > is "inline" in the pyx through the pxd.) > > inline functions in pxd files is something I think comes in *really* > handy, it is part of what the "include" statement is currently used > for > and inline functions are much nicer than include statements. +1 to inline functions. I've wanted these too. > Proposal: New modifier, "proto". I.e. > > cdef proto int foo(int a, int b): > cdef int c > cdef int b > > will embed the signature/variables on a pure > > def foo(a, b): ... > > If the keyword proto is not present, the definition is not allowed > unless it is declared inline. > > Pro: > - Resolve the conflict. > - I think this makes it more obvious what is going on. I think having > the pxd definition transfer to a def in the pyx/py is a bit too > magical > using the current syntax anyway, and that this is an improvement, > conflict or not. > > Con: > - Breaks compatability with Cython 0.10 (but through compiler > errors, no > silently changed behaviour). > > What do you think? I could implement it in roughly five minutes if > it is > accepted, the function modifier part of the parser is nice and > dynamic. I'm generally -1 on adding new syntax, but what I had wasn't very clear either. Would it be enough to accept a locals decorator? - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
