On May 15, 2008, at 2:09 PM, Lisandro Dalcin wrote: > On 5/15/08, Dag Sverre Seljebotn <[EMAIL PROTECTED]> wrote: >> Lisandro Dalcin wrote: >>> On 5/15/08, Dag Sverre Seljebotn <[EMAIL PROTECTED]> >>> wrote: >>>> I think: >>>> >>>> - The default "Python language level" for the pyx source when >>>> Cython is >>>> run should be that of the interpreter Cython is launched within. >>> >>> I definitelly disagree with you. Cython 'pyx' has the chance of >>> being >>> more backward compatible even that source 'py' files. >> >> >> Do you have a real example where this would be genuinely useful? > > Perhaps I'm just asking for too much magic from Cython's side. But I > already have a working project, wrapping the MPI specification (C API > with more than 500 C definition summing up functions and constants), > and in the current status of cython-devel-py3k I'm able to generate C > source files that are going to compile and run against Python 2.3 to > Python 3.0, > > Moreover, I can distribute a single set of generated C sources (I do > not want users have to install Cython to build my package), and they > build and the final extension module work just fine. > > I would definitely love that this degree of compatibility is > maintained, not only for the easy of maintaining of my project, but > also I'm pretty sure that other developers using Cython for serious > work would also REALLY appreciate that.
If this is possible (and I think it is), I would *very* much like to support this. The behavior of the module should depend mostly on the Cython compilation environment/flags. However, for (unmarked) string literals I think we should decide based on the C compilation stage. This makes things like hasattr much more compatible, as well as accepting/returning string literals objects. >> My very subjective and unfounded feelings: Creating some super- >> language >> which supports both 2 and 3 completely transparently is likely >> going to >> either have too few features to be useful, or be such an effort that >> it's not worth it. > > Well, I would love to see Cython language to be more near Python 3 > language, just because Py3 it is a better languaje. > > Once Cython can parse Py3 sintax, I will readily update my code to > that sintax, but I still would require and work for the generate C > sources work at least on Python 2.4, better if also in 2.3 . I have > users of my code running parallel applications on clusters with dated > systems providing Py2.3; I would really avoid those users to ask them > for building Python from sources (plus other packages they depend on) > just because I like to be in the bleeding-edge Cython, who do not > support C-level compatibility with Python 2.X. Agreed. The only thing one would have to watch out for is using, for example, builtings that have different meanings/don't exist in earlier versions of Python. Related to this, I would like Cython to have good support for the buffer interface, which of course (mostly) won't be available pre Python 2.5. >> Having Cython output Python 3 compileable C code >> (from current Cython/Python 2) is however a great way of enabling >> people >> to write Python 3-specific Cython code before we get to the stage >> where >> there is Python 3 syntax support in Cython itself. > > Indeed. Furthermore, IMHO Cython support for Python 3 syntax could be > even extended. Python 3 does not let you to do u"abc" for an unicode > literal. Should we really have this restriction in Cython? Unless > there is a good reason, I would ask this for being accepted. +1 >> (BTW, can we find some standard terminology for talking about this? >> Something like "Cython": pyx -> c stage; then it is a c-file and not >> Cython, and then "C compilation": c -> executable stage.) > > Agreed, Let's use "Cython compilation" for the pyx -> c stage, and "C > compilation" for the c -> so stage (or whatever extension extension > modules have) Works for me. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
