On Nov 14, 2007 3:38 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Carl Friedrich Bolz wrote: > > Hi Martijn, > > > > let me first note that I agree with a lot of your points, when not > > taking the financial side of things into account. I will ignore the > > financial side of things in this mail (since I don't think anybody > > proposes to focus on something completely different than our Python > > interpreter _without_ major financial incentives). > > > > Martijn Faassen wrote: > > [snip] > > > Again, I'm not trying to criticize what the project has already done. > > > I'm trying to be a voice of pragmatism and the voice of a potential > open > > > source end-user. Listen to me if you like; it's not an enemy voice. > > > There are two PyPy technologies that I can see that are close to > > > pragmatic fruition now: > > > > > > * writing CPython modules in RPython (I completely lost track of what > > > the state of this is since there have been a lot of changes) > > > > It's still working but mostly accidentally. It needs some rethinking and > > a rewrite. We have now better machinery and also ideas how to make it > > really fast, but it's a manpower problem. There isn't anyone interested > > enough in supporting this in the current PyPy team. If somebody outside > > the current PyPy-team really wanted this and were willing to work on it > > we (or at least me personally) would give him all the support we can. > Sorry for jumping in, and I hope this is not too OT, but what is missing > for a 'real' CPython alternative ? > - some bits of the standard library: how much ? Can this be worked > on by people 'outside pypy' (by outside, I mean people who know python, > who are willing to learn rpython, but who cannot work on the whole > translation/gc/JIT/whatever because they are not smart enough, someone > like me :) )
Yes and yest. This is our major problem and it could be worked by people from outside, but I would wait for two things a) completion of app-level ctypes (it's not far, needs only pure-python code) b) separate compilation (hard, but very high on our todo list) > > - some language constructs (my understanding is that the current > language supported is python2.4 ?) ? No, this is perfectly fine. > > - implementation problems (some things too slow, not backward > compatible) ? > Slow, yes. Some things. But this is incremental work all over the place. Recently there has been a lot of improvements in string/unicode area for example. If you feel like profiling certain parts (like regular expressions), would be cool. Cheers, fijal
_______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
