On May 11, 2008, at 1:14 AM, Dag Sverre Seljebotn wrote:
> Given recent developments (Pyrex release with new syntax and Arc's new
> project) I think Cython should make some public website statements on
> language policy and stability. I think these are already present in
> the
> "community spirit", but we should make them very explicit.
This is a very good idea.
> Rough suggestions aimed for starting this thread:
>
> - "Cython want to be a dynamic work in progress and so new language
> features will happen quickly over the next year. *However*, each
> change
> will be related to previously unavailable features and will have a
> backwards-compatible syntax."
I think there is a place for backwards-incompatibility. For example,
the __new__() being renamed to __cinit__() (as __new__() a very
different meaning in Python). However, if there is ever backwards-
compatibility issues, it should be for a *very* good reason. Also, we
might want to add syntax candy, so I'm not sure about the "previously
unavailable features" clause.
> - If we need to break syntax backwards-incompatibly, it will be
> done by
> the scheme discussed earlier: A "#lang: cython-ver" comment header.
> Files without such a header will be compiled with the current ("v0.9")
> syntax.
>
> - Some decision should be made on Pyrex compatability. I think it
> should
> either be flat out "the language looks like Pyrex because of its roots
> but is *not* Pyrex", or, we should aim to correctly compile Pyrex
> (including future changes) but do so only when "#lang: pyrex" is
> specified.
>
> (Of course, any "lang" instruction would be command-line-
> overridable so
> that existing Pyrex code could be built with a "--pyrex-mode" flag)
I don't think supporting multiple versions of the language, and
having a specific Pyrex flag, is a good idea. If one wants a specific
version of Cython, one can download and use that one. If one wants
*exatly* Pyrex syntax, use Pyrex itself. Any difference should be
clearly documented, and be for good reason, but having different
"modes" that we continue supporting seems cumbersome.
> - We need a consistent keyword policy. I'm going to be
> controversial and
> suggest that this will be "figure it out from context", because we aim
> to compile any Python code. I.e.:
>
> * Any Python keywords are also Cython keywords (which exact keywords
> depends on the Python language level we are compiling)
> * Any non-Python keywords are only keywords when used in a context
> where they can mean a keyword instruction. That is, we should start
> supporting Cython code like this:
>
> cdef = 4
> # Created cdef variable, does not alter behaviour of cdef keyword
I would much rather this be a syntax error. It also will make the
parser a lot more complicated (and the code a lot harder to read.)
> We already support
>
> final = 4
>
> anyway...
Final is not a keyword, and I don't think it will ever be. It could
still have a special meaning, but being a keyword is a lot stronger.
> I think any new Cython keywords (over Python) are always used
> in contexts where they could not be a variable name so I think this is
> possible.
>
> This is unusual, but because our aim is to go towards full Python
> support, but still support Cython code, I think such a policy is a
> possible compromise (the important thing is to have a solid,
> dependable
> rule we follow).
>
> Another possibility is to only allow
>
> cdef = 4
>
> when we are in (also on the idea-stage, from the #lang-thread) Python
> mode (compiling a .py-file or having a "#lang: python" header).
Maybe... I really don't like the idea of mixing the two modes, e.g.
cdef cdef x = cdef(3)
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
