On Fri, 01 Mar 2013 17:44:27 +0100, Armin Rigo wrote: Le 01 Mar 2013 17:44:27 +0100, Armin Rigo a écrit: > Hi Gabriel, > > On Fri, Mar 1, 2013 at 4:22 PM, Gabriel de Perthuis <g2p.c...@gmail.com> > wrote: >> Packages using CFFI should be able to install-require CFFI whatever the >> interpreter is, including requiring newer versions than the one the >> interpreter ships. > > (...) > > Even so, more generally, I think that requiring users to install a newer > version of the interpreter is actually feasible, when we are talking > about PyPy and not CPython. A "newer version" of PyPy is just an > internal improvement, but not a language change --- it's always 2.7. I > think that so far, our users are (or should be) ready to deal with this > minor annoyance; if they are not and really want a completely stable, > never-changing interpreter, then they're going to stick with CPython > anyway. > > In other words, I regard this as similar to: "this program requires PyPy > 2.0 and not a lower version because otherwise its usage of greenlets is > going to be a huge performance hit".
I don't mind terribly if CFFI is version-locked on PyPy, because PyPy is currently installed manually by people who know what they are doing, and they can upgrade it if necessary. Also, CFFI is great for me because it makes it easy to access just about any feature a C library exposes, and does so portably. I can gladly trade off CPU speed for improvements to CFFI in featurefulness or usability. So my previous message was actually a reaction to the "CFFI in stdlib" inclusion proposal. There are enormous advantages to sharing stdlib implementation between the interpreters, and using CFFI for stdlib implementation makes sense. It will make the stdlib better maintained, and improve both PyPy and CPython. But speaking as an external user, targetting CPython which is on anything but a rolling release, *exposing* the preinstalled version is not particularly useful (the bundled version will either be obsolete or not widely packaged), and harmful if it interferes at the level of eggs or import. I'll admit this makes me indifferent to expanding the stdlib with anything but a built-in pip, necessarily-shared resources like a mainloop or data types used in API signatures, or de-facto standard libraries that have become mature vergeing on stagnant; everything else is better served by a blessed subset of PyPI libraries, the way haskell-platform works. It looks like Stefan Behnel asked the right questions on the more appropriate thread (plus some stuff about making compiler invocation deterministic that I also care about). _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
