On Oct 3, 2008, at 3:18 AM, Dag Sverre Seljebotn wrote: > Dag Sverre Seljebotn wrote: >> Robert Bradshaw wrote: >>> Let X <= Y. If you run Cython with Python X, then it should compile >>> against and run under Python Y. However, if you run Cython with >>> Python Y, it may not compile against or run under Python X >>> (depending >>> on if you have used features introduced after X). Without >>> backporting >>> every new feature back to 2.3, this is the best we can hope to do. >> >> I don't follow the logic here.
Sorry I wasn't very clear, thanks for splitting things up more below. >> Please bear with me, this is important: One consequence is that >> there is >> currently no way to get access to Py3-only builtins from pyx files >> without using getattr (like "memoryview", unless it was added to >> Python2.6 last minute, I didn't fetch the release yet. But even if it >> was, I don't think there's any rule that all new Python 3.x builtins >> will be backported to 2.x?). >> >> In my mind there's three different Python versions involved: >> >> - A: The version of Python the user targets in the pyx file (when it >> comes to library and builtins; keeping the language part out of >> this). >> - B: The version of Python that imports the compiled module. The user >> just has to make sure that this matches A in a reasonable fashion >> (the >> rules are non-trivial and not a simple >= or <=, as Py3 removes >> builtins, but Python lays these down for us). >> - C: The version that runs Cython. >> >> This discussion was about A and B -- that Cython won't allow users to >> code for Py2.4 and run under Py2.3. >> >> You seem to be talking about C, which is something different. Cython >> just transforms code and could run on any Turing-machine, there's no >> natural reason it has to be connected with A or B. Theoretically, C is orthogonal. However, for a given user, it is likely that there is strong correlation between all of A, B, and C. >> We do currently require C >= B (which means that any Py3-only >> builtins >> are plain unavailable). No, we require that C >= A. Often C = B, and obviously B >= A, so this is reasonable. >> In my opinion, ideally C should be orthogonal to A and B because that >> seems to be less complicated from a release and bugfinding >> perspective >> (one less version to worry about in the mix) On the other hand, violating C < A results in a nice cython-compile error, whereas violating B < A is either a (perhaps not easily hit) runtime error or a c-compile error. Which would you rather debug? It's also reassuring to say "if it compiles under C, it runs under C +" because A is often implicit rather than explicit. >> and it would fix the issue >> with accessing Py3-builtins for free, but I don't care very much. Is this because Cython doesn't run under Py3? (I thought it did.) Or is there something I'm not seeing here? > To be more concrete, the problems you mention could be fixed with a > simple compiler flag (or directive) to Cython: --target- > platform=3.0 or > similar, to control the builtins. But, "there's no lack of good > ideas". I think inspecting __builtins__ at runtime is a more elegant (and safe) approach than manually keeping lists for every version. A possible exception is the builtins that disappeared in Py3, in which case I would lean towards "forwardporting" them by importing from the right place, as they are still there somewhere). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
