[pypy-dev] curses_cffi and others

[Gabriel de Perthuis]

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.code at 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).