[pypy-dev] Work plan for PyPy

[Christian Tismer]

Hi Armin,

On 16.06.2007, at 19:10, Armin Rigo wrote:

> Hi Simon,
>
> (This is also a follow-up on concerns raised by Christian on #pypy
> today)

Well, reacting a bit to it, here...

The reason why this stuff kept me busy thinking since
the meeting was the fact that we are about to trash
exactly the little stuff people are actually using.
We do have very little users, and most of them are
involved right here.

So if we are going to trasg stuff, then we should
go and offer help to those few users, to not getting
distracted from PyPy.
<please assume that I could insert all of Martijn's text, too>

So my thoughts were around these ideas:

- Try to extend CTypes to support primitive-enough concepts
   that do translate to RPython

or

- offer support to our users, to make transition to rffi
   smooth and easy.

I think both ways are possible, I also guess the latter
woulod be supported even if we asked for help or some funding
for this necessary work.

Whatever way we choose, I think it would be best for PyPy
if we try to be as user-friendly as possible, saying like
"""we believe we must change this and that immediately, but
we will not leave you in the rain, but actively help porting
your stuff."""

This also relates a bit to my former thoughts about things
which we have donated to the open source. We can, physically,
just trash anything, of course. But from a point of view
of users and our growing community, this is a matter of belief
and trust that we should be careful about.

I'm not saying that we don't care, these are just my thoughts
and feelings about what I want to be not questionable.

> On Fri, Jun 15, 2007 at 05:44:54PM -0700, Simon Burton wrote:
>> I hope we can do all this with rffi, but there are two really
>> cool things about rctypes:
>> 1) it runs on cpython (our main app takes 30minutes+ to compile)
>> 2) it has an automatic code generator (ctypes can autogenerate
>> python wrappers from C header files)
>
> For 1), this would actually be possible with rffi too.  The trick  
> would
> be to have two implementations of the lltypesystem objects (array,
> structures, etc.).

I think the idea is not bad, but unless I'm missing something,
don't we exactly loose the testing feature by this, by having
to have two different implementations, the benefit of simple
CPython testing for lltypesystem would be gone?

> The existing implementation would only be used when
> ctypes is not available; if ctypes can be imported, then the other
> implementation could systematically be used.  With a bit of effort it
> could have a fully compatible interface, but be internally implemented
> as ctypes objects (e.g. lltype.malloc(S) would build a ctypes  
> structure
> type corresponding to S, and internally instantiate that).  Then we
> could really call rffi functions, by turning it internally into a  
> ctypes
> function and calling it with the ctypes objects underlying the  
> passed-in
> arguments.

Not sure that I immediately get it.
You would use CTypes to emulate rffi functions if we are in Python,
and use them directly when you are in RPython?

How would the memory ownership problem be handled?

Ah, the problem is circumvented by doing all this stuff on
app-level, dropping high efficiency constraints?
No I am confused.

> This might even not be completely insane - in my opinion, less than
> implementing and maintaining rctypes itself.  It's also something that
> can be done by someone not deeply into the code base, as long as he
> knows the lltype interface and how to use ctypes.

By 'it', you mean the CTypes implementation, at app-level, based
upon rffi? I hope I'm not completely lost, here :-)

ciao - chris