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 <[EMAIL PROTECTED]> 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 > > _______________________________________________ > [email protected] > http://codespeak.net/mailman/listinfo/pypy-dev > _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
