> Also, I really like the fact that "test" is a plain byte string in Cython that > can directly be converted to a C char*, depending on its use. This shouldn't > change, even if Py3 dictates that this literal becomes a Unicode string. > What exactly are the consequences here... if it is just about the runtime object used then I suppose it can be inferred from context? (I.e., coercion to char* deals with it...) Or does it mean that string literals converted to char* should be UTF-8 strings or something?
What is the current behaviour for string literals anyway..probably that the encoding of the Cython source gets carried through to the strings in C source? > Having a separate Cython frontend (cython3? or a command line option "-3"?) > and a distutils Extension option for compiling Python3 code with Python3 > semantics might be a way to deal with the syntax issue. But I would actually > prefer a different source file extension (.cy3) or a special comment in the > first code line, or something like that. The language level is an integral > part of the source file, not so much of the build system. Even > +1 for comment in first lines; Python already has "encoding:". Something like "lang:". This way, one could in the future also have different Cython syntax levels if one needs to break Cython backwards compatability (though let's hope not), or to specify that extensions to Cython++ (or whatever) is used. Also it could be nice (though not at all a priority!) to have a mode that actually gave a syntax error on "cdef", if one is strictly compiling Python code because one wants to be Python compatible and not "slip up" into writing some Cython. Probably this can be triggered by .py extension. (This is not as much a suggestion, as it is just brainstorming in order to see what kind of syntax levels one could have in order to sort Stefan's question out.) One could even load Cython plugins (that modify Cython syntax) this way. Perhaps a free-form comma-seperated list of keywords like this that operate along different "axes" of language choices: #lang: cython, py2, martins-macro-goodies I.e. "cython" would enable any Cython-specific syntax like "cdef" and types, pyX would set the Python level support for the Python part of the syntax, and anything else could load a plugin with the same name if found. Loading the plugin from the source file itself makes sense because the syntax in the source file is inherently linked to which plugins can parse it; it's a way of saying that "I'll use "deftrans" in this file". Using #lang: py2 it would still be compileable in Cython, but Cython extensions to syntax like "cdef" etc. would be disallowed. If we need to break Cython backwards-compatability, one could do it by only enabling the changes if writing "cython2" instead. The #lang statement would override anything, but without it one would look at the file extension (pyx could mean "cython, py2" while py would mean "py2"). Also, there's the question of input and output. This has all been about input, however it seems like code generation is partially independent of this. Probably least confusing will be outputting 2.6 input to 2.3+, while outputting 3 in 3; that might be an assumption already? Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
