[pypy-dev] Re: Comments from an observer
Ben.Young at risk.sungard.com
Ben.Young at risk.sungard.com
Fri Dec 9 11:22:23 CET 2005
pypy-dev-bounces at codespeak.net wrote on 08/12/2005 22:09:09:
> This reply is solely to make a couple of points that I don't think
> have been made yet -- I don't want to give the impression that those
> points were less important that the ones I mention here.
> Ben.Young at risk.sungard.com writes:
> > Also, most people on #pypy seem to ask about using pypy to compile
> > simple python programs to c. Now, this doesn't seem like a great deal
> > work away (better error messages etc), but they are (politely) told
> > this is not what rpython is for. Now if rpython is not for this, why
> > you write PyPy in it?
> Because we needed a description of the Python language that is amenable
> to analysis. I hope this isn't a new answer to you...
I do understand that. It's just that as PyPy is a relatively complicated
program it follows that rpython is good for making a lot of python
programs amenable to analysis. (Yes as a by-product, but in my opinion an
incredibly powerfull and usefull one)
> > I don't want to come across like a moaner (and indeed, that's why I
> > writing on #pypy as felt I couldn't be enough of a positive voice),
> > the only reason I'm writing this is because I think so much of the
> > and think it has so much potential. The last thing I want to see is
> > PyPy to become a great implemention with many powerful features, but
> > find that it had missed its time by not being "results driven" enough.
> What results do you want?
Sorry, I guess "results driven" came across slightly differently from how
I meant it. I guess I meant that PyPy has many parts that with a bit of
polish could be useable now in production based scenarios, as people keep
asking about in IRC. I.e if people could write extensions, and PyPy was
itself a bit faster and more polished then people could start using it
now, and upgrade to a JIT version/different backend/thread model etc
> > The world doesn't need another powerful research/university
> > language, it needs a great production language and with PyPy I think
> > Python could be that language.
> Yes, but I want *Python* to be that language, with its multitude of
> existing libraries and useful dyanmism and all the rest. Have you
> read this blog post:
> ? I think I agree with his point that supporting 80% of the language
> is of much less than 80% of the value.
> If you have new code to write, then fine, writing it in RPython isn't
> that bad. But it's the people who want to, e.g., use urllib2 or some
> old code they wrote last year that I personally am interested in
> helping, i.e. every single user Python has today. This is why I'm
> most interested in the JIT and the standard interpreter end of things,
> not productizing an RPython compiler. Now I'm not and wouldn't want
> to be speaking for the project as a whole, and I agree that
> productizing RPython would be a very worthwhile project -- but I'm not
> going to do it, sorry.
> I hope that this has at least convinced you that I have no intention
> of PyPy being a research/university language, either.
You have convinced me, and I'm glad that you are all so passionate about
the project. Again, I didn't want to come across as moaning, and I want to
thank you for all the work you have done so far.
> I never disputed the Perl hacking skill of the Slashdot creators.
> My objections are to the editors' taste, the site's ugly visual
> design, and the Slashdot community's raging stupidity.
> -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq
> pypy-dev at codespeak.net
More information about the Pypy-dev