Robert Bradshaw wrote: > On Oct 2, 2008, at 2:45 PM, Lisandro Dalcin wrote: > >> On Thu, Oct 2, 2008 at 5:58 PM, Dag Sverre Seljebotn >> <[EMAIL PROTECTED]> wrote: >>> My five cents: I'm -1 on making emulating later Python versions in >>> earlier ones in most cases, and definitely this one. We are >>> developing >>> Cython for the present and future, and Python 2.3 is starting to >>> belong >>> to the past. >> Me to, -1 on this... > > Some stuff (for example buffers, the with statement, and the b"byte > string" syntax) I believe are worth backporting. Python 2.3 will > continue to be a target for us (at least) as long as it is a target > for NumPy.
BTW: This changed a few days ago, when 1.2.0 was released: "Please note that NumPy 1.2.0 requires Python 2.4 or greater." (I'm still +1 on Py2.3 compatability, just noting it.) > 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. 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. We do currently require C >= B (which means that any Py3-only builtins are plain unavailable). 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) and it would fix the issue with accessing Py3-builtins for free, but I don't care very much. > > Letting set be defined no matter what violates this principle. Thus > if they have a Python 2.3 toolchain, they can (too easily) produce > code that they cannot use. Furthermore, the error will be some > obscure (to most people at least) message in the C compile. Much > better to raise an error during the Cython run. That way if Cython > succeeds, the C compile will succeed and the module will work (modulo > any bugs of course). You can guard against typing "zpi", but not (currently at least) against typing "os.path.exitst". I guess I tend to think of those as about the same thing -- i.e. accessing a builtin is just making use of the __builtin__ run-time module, it is just that we hacked some of them for speed purposes (as we in future may be able to do with os.path.exists too through the use of inline code in pxd files). That was the opposing view. But I see that this is non-trivial, and as I said this is not an important matter to me, so I might as well end this mail with agreeing with you that what you present is the best course of action for now :-) -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
