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

[Ondrej Certik]

I couldn't say it better, completely agree with Martijn. It's fine, if
pypy is going to be a research project, but I was thinking for many
years, that the aim is to get a production interpreter. In fact, there
will be dozens people willing to help out, but pypy first needs to
solve 90% of things for them first. Otherwise they will not join,
that's how it works. So I myself will also invest my time to other
projects, that can solve 90% of things for me now, Cython for example.
Ondrej

On 11/20/07, Martijn Faassen <faassen at startifact.com> wrote:
> 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
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>