[pypy-dev] Removal of RCTypes, the extension compiler, support for PyObjects

[Martijn Faassen]

Carl Friedrich Bolz wrote:
> Martijn Faassen wrote:
>> I'll just note what this might mean to you in terms of project
>> perception and perception of commitment:
>>
>> You're replacing one of the few areas of PyPy that at least *seemed* to
>> be useful in the near term for production use (even though it evidently
>> wasn't really) with "the extension compiler can be reimplemented with
>> rffi if someone is interested in doing that".
>>
>> I.e. you're removing your implicit commitment (in the form of code that
>> more or less worked) and replacing it with an explicit lack of
>> commitment or interest in making this work.
> 
> I really thought we were through with that. 

I said I wasn't objecting. I'm not objecting. I'm just pointing out what 
it means to me. I'm also asking the next question: CPython extensions 
are definitely off the table. so what's up with the Python interpreter?

I thought that a way to make cool Python bindings with RPython might be 
a way to get PyPy to practical use. So I told people that they should 
seriously consider putting some effort behind this feature (whatever 
form it might take), as this seemed the closest to real-world use.

I asked a set of questions in june. Back then, I got two answers to my 
questions. One from Maciek and one from Bea. Both said, we'll discuss 
this at EuroPython.

At EuroPython I got the impression there was little interest in making 
this work and that people wanted to work on making PyPy mature first. It 
wasn't very clear, but that's my impression. Okay, the interpreter 
first, that's my understanding.

As an aside, it's now after EuroPython, so I'll try answering these 
questions myself now:

* what are the reasons this change is going to be made?

[some answers were given on another thread back then. Basically, the 
current way is broken.]

* would this benefit just core PyPy or would it benefit extension module
writers too?

[Only core PyPy. If some work is done by volunteers, by extension module 
writers too as the rewrite is cleaner]

* when do you expect the new way to be finalized?

[For the core PyPy stuff: in November 2007. The core PyPy thing is more 
or less done now, I understand, being cleaned up now. For the extension 
module compiler: this depends on other people, we are not going to do it]

* will you make a real commitment to make the "Test in CPython first"
feature work again? Or is did you just sketched out possible ways to
implement this in the new system and you hope some contributor is going
to do the work?

[I'm not sure about this one. Can you write a CTypes module and test it 
in CPython before running it with PyPy, or not anymore?]

* will you make a commitment to make this new way useful and supported
for extension module writers, or should they invest their time in some
other technology? I.e. what are the changes a future shift will make me
change things again?

[We won't make any such commitment, and they should make an investment 
in some other technology like CTypes or Pyrex or do it themselves with 
PyPy with the knowledge the core team isn't very interested themselves]

* How well documented will this be for CPython extension developers?
Will you market this feature to developers? Things like this indicate
your commitment in another way.  :)

[This question is irrelevant, as there is no commitment]

Are my answers correct? I understand that there's no commitment to make 
it work, and that you'll just have this feature go away. It was broken 
in the first place. That's fine - I have no objections, as I said. I'm 
just telling you what it means for me.

> For these reasons removing this piece of code is not showing lack of
> commitment or lack of leadership or sending a wrong signal in my
> opinion. It is just getting rid of a failed implementation idea.

It's fine that you don't commit to this feature. I'd preferred better 
communication, but that's not a major complaint. It was clear enough to 
me already that this feature was in limbo.

What worries me is that I don't see any commitment to make *any* feature 
work for production-use. Not the extension compiler, obviously. So that 
brings me to the rest of the email: it leaves the other potential 
practical feature that was discussed at EuroPython: the production 
interpreter. People preferred focusing on that as it wasn't considered 
to be that far off, and it was more central to the goal of the project 
than an extension compiler for CPython.

So, please let me know whether you have a commitment to make a 
production ready interpreter work.

Here are some questions that people might ask about the production 
Python interpreter:

* Does the project have any commitment towards producing a 
production-usable Python interpreter, for whatever value of 
'production'? I.e. is the project interested in these questions at all, 
or do they consider these questions beside the point?

* If the project does make a commitment, does the project commit to 
release management to churn out new versions of the production 
interpreter at a regular basis?

* If the project does make a commitment, when do you expect the 
production PyPy interpreter to be ready for early adopters? When do you 
think it will be solid enough to reach lots of people? Is there some 
form of timeline?

* What platform will you focus on first? (JVM, .net, C, something else?)

* Will the production interpreter contain JIT technology? If not, when 
is this expected?

If this is to be a research project with no concrete plans for a 
production Python interpreter that's fine. I'll certainly stop bugging 
you about these topics. If the plan is to start serious work on 
Smalltalk or Ruby interpreters first before finishing the Python 
interpreter, or if the plan is to work on all three at the same time, 
forgive me when I adjust my expectations downwards for a Python 
interpreter. I will wish you luck.

I hope that all this was already discussed and clear within the project, 
and just not communicated widely yet. If so, please let us know the 
answers. If it wasn't discussed yet, then please discuss this kind of 
stuff at the sprint. It seems like a good opportunity. If you do aim to 
finish the Python interpreter, I'd expect to see a list of concrete 
goals and date estimates, and then please share it with us if you'd like?

I feel a bit like I'm asking crazy unrealistic impossible questions, but 
  I don't think I am? Wasn't the project supposed to come up with a plan 
for these things in the post-EU phase?

All these questions are from an interested bystander who may want to 
commit some time on this project (more than reading and writing emails) 
in the next year if he does see some idea that the project is indeed 
sharing some of his goals. I think there are more people like me you 
could attract if you give us a bit of hope.

Regards,

Martijn