Lisandro Dalcin wrote: > On Tue, Aug 5, 2008 at 9:49 AM, Dag Sverre Seljebotn > <[EMAIL PROTECTED]> wrote: >> >> 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). > > It is not to much at all. I would even ask for '1' and '0' also being > accepted for booleans.
I'm going to side with Stefan here and tighten it up: "here should be one and preferably only one obvious way to do it." So so far it stands +2 to True/False in source and allow yes/no on command line as well, and +1 for keeping it as it is but add 1 and 0 as well. I want to mention another alternative though: #cython: boundscheck(True) some_other(False) because this makes things consistent within the pyx file and leaves the way open for multiple arguments (but = on the command line is fine because () is such a problem to input using a shell...) >> 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. > > Well, '-O' smells to 'optimization' for me. True. Then again, most of the options will be optimization-related. Any other suggestions? -d or -D for directive perhaps, if they are not taken. -D means #define in C of course... >> c) A decorator works on function-scope: >> >> cimport cython >> @cython.boundscheck(True) >> def f(): >> ... >> >> d) A with statement: >> cimport cython >> with cython.boundscheck(False): >> ... > > I really prefer the decorator form. The 'with' form could require a > lot of identation if you want to set a lot for options. Well, then you use the decorator form in your code. The with form is useful if you really need to optimize a single line within a big function, without requiring you to create a new function. In my buffer test case I am switching back and forth from bounds checking within a function and it works excellently... Hopefully we can have class decorators as well though. > If it is too magic, then perhaps 'cimport' should not be the way to > access the options. What about 'cython' being a sort or 'reserved > global'. Furthermore, perhaps 'cython' is not a good name. Perhaps in > the near future Pyrex can take some of your ideas. So perhaps is > better to find a 'neutral' name. As I am against tainting the global namespace with no-Python names that is not going to get my support, so this is +2 for requiring the cimport (me and Stefan) and -1 (from you) so far. As for Pyrex compatability -- in general, I'm not very up for going into discussions about keeping compatability with "what Pyrex might do". If you have a lot of Python code that you try to modify and compile in Cython, it is much more obvious what @cython.X is about that @options.X (which options? Something in Python?) If Greg asks for it I'll definitely reconsider my vote though. Perhaps "compile", but there's a lot of other stuff we want to have in the cython namespace that doesn't fit with compile. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
