[Cython] Done with compiler options/pragmas

[Dag Sverre Seljebotn]

Lisandro Dalcin wrote:
> On Tue, Aug 5, 2008 at 9:49 AM, Dag Sverre Seljebotn
> <dagss at student.matnat.uio.no> 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