Hi, I missed the end of this discussion, but here is a comment anyway.
Dag Sverre Seljebotn wrote: > Robert Bradshaw wrote: >> I think we should follow a similar format as in PEP 0263. I do not think that PEP 263 provides a suitable example here, as the syntax was specifically chosen as the lowest common divisor of a number of existing encoding hints for different editors, each of which has an explicit syntax that isn't quite compatible with any other syntax. >> 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. > > You can now do > > # boundscheck = True > # boundscheck = False The problem with this is that users who are not aware of directives can end up breaking their code by commenting out an assignment. Even if that's unlikely, it is not immediately clear from the syntax that it is /not/ just an assignment that was removed from the code by commenting it out, but something that actually changes the way things work. A compiler directive should be clearly recognisable as such, especially when it invades the privacy of the user's comments. > at the beginning of the file, with whitespace variations only. > Everything else is ignored (except using something else than True or > False on rhs, which raises an error). I like the fact that this only works at the very beginning of the source file (preferably after the encoding hint), and I also like that it only works with True/False and looks like a keyword argument. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
