On Aug 5, 2008, at 5:49 AM, Dag Sverre Seljebotn wrote: > Feedback welcome on the below set of conventions -- I just picked some > conventions to get going and implemented them as they are easily > changeable. So feel free to comment on all choices of names, > letters etc. > > Terminology first -- I don't really like the word pragma... "code > generation options" are perhaps better? I've called them "(compiler) > options" below and in the code base, while calling what is options > today > "arguments" (as it is command line arguments they really are). > > Anyway, the system is this: Options.py contains a list of compiler > options to be controlled through this system. Currently this is only a > boolean "boundscheck". > > ALL options we define can then consistently be toggled in the four > ways > listed below. During a transform step, ALL nodes in the parse tree > has a > node.options dictionary added giving all options (with defaults filled > in) in effect for that exact node (this only adds a reference of > course, > so consider that dict immutable). > > IndexNode then simply checks self.options['boundscheck']. > > Ways to set options: > > a) > > #cython: boundscheck=True, other=False > #cython: third = no > > before any code in the file (but whitespace is allowed, I'm using > Plex/the parser). The boolean value is case-insensitive and > true/false/yes/no is allowed (is this too much? The thing is, for > command-line arguments "True" is rather unfriendly and I'd like it > to be > consistent).
I think we should follow a similar format as in PEP 0263. Specifically, I'm not even sure the "cython" is necessary--the compiler directives are arbitrary key-value pairs, and they are looked up as needed. The ones that Cython uses/supports will be documented. For the command line, we should be flexible, but a constant literal for the values of the directives (not all of them may be booleans). > b) A command line argument "cython -O boundscheck=False,other=tRUe -O > third=yes". This overrides the #cython comments, but NOT c) and d) > listed below. +1, except for -X as mentioned. > The syntax of the string passed to -O is the same as the one passed to > #cython, which is why I allowed yes/no in it. (For instance, ssh has > options like this: ssh -o ForwardX11=no). > > c) A decorator works on function-scope: > > cimport cython > @cython.boundscheck(True) > def f(): > ... > > The decorator is stripped away before the decorator transform. > There is > not really such symbol as cython.boundscheck in the scope, it is a > magic > option only. So of course you cannot do > > a = cython.boundscheck > @a > ... > d) A with statement: > > cimport cython > with cython.boundscheck(False): > ... > > The entire with statement is then stripped out of the source prior to > the with transformation. These are fine, though it does start to sound like a lot of ways to do the same thing (they all have valid use cases though). I also like these in the sense that a fake "cython" object could be provided whose __getattr__ always returns an object which (1) returns the identity on __call__ and (2) implements a trivial __enter__/__exit__ so these would be valid in Python too. > > > BTW, on "cimport cython": This is magic as well. I.e. it always is in > front of the include path, and there will be no way to have a pxd file > named "cython.pxd" imported. Is this OK? (I can change it but it would > be less simple in more than one place, and people really should always > have the cython scope available.) I think that's sensible. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
