[pypy-dev] Re: [Python-Dev] AST branch update

Neal Norwitz nnorwitz at gmail.com
Sat Oct 22 09:25:40 CEST 2005

On 10/21/05, Armin Rigo <arigo at tunes.org> wrote:
> Hi Neal,
> (CC-ing to pypy-dev, if you don't mind :-)

Of course not!

> > Any interesting ideas that can be used to improve CPython?
> That's an interesting question.  So far PyPy has produced mostly bug
> reports for obscure errors and crashes in CPython -- only today, trying
> the CPython HEAD with the newly merged AST compiler showed 7 of them :-)

Jeez!  I was hoping that was in PyPy, but I see the bug report now. 
At least one was taken care of (lambda became <lambda> again).

I suspect there could be many more corner cases like these.  Thanks!

> Anyway, someone might want to try
> again to scrap Py_INCREF/DECREF and use the Boehm GC with CPython.

I would like to see this happen, but don't think I will have time for
it.  I hope to try to play with speeding up function calls.

> I suppose that we will soon try more experiments.  Coming to mind:
> unboxed integers to see if they help -- I doubt it, but if they have a
> large effect then CPython might consider to use them at least in some
> speed-critical places.  Different locking approaches for threads, though
> it is unclear how much of what we do there would be practical for
> CPython.  Several implementations for app-level string objects, e.g. a
> "string slice" one, a "lazily joined substrings" one, etc., which might
> give interesting speed-ups for some programs.

Yes, I think this is true.  I'm not sure it would be an overall win.  Another
possibility is for lists.  I wonder how many times empty lists are
instantiated, but never used.  It might be possible to make a sort of
copy-on-write empty list that is (are) cached.  Also, list slices are
often used for iteration.  It would be nice if we didn't need to make
a copy of the list.  This becomes difficult since the list could
change during iteration.  But we could make a copy in that case at the
time it was modified.  I'm not sure if that would be easy or difficult
to implement.

> All in all I suspect that it will be some more time before we can go
> past the current state, which is "being a bit like CPython but not quite
> as good".

Best of luck.

If anyone has time it wouldn't hurt to give little status updates on
python-dev from time to time, just so we have more insight into PyPy
and anything interesting you run across.  I don't know how the
experiment will turn out, but it's interesting to watch.  And you have
certainly contributed many bug reports on corner cases which helps
improve Python.


More information about the Pypy-dev mailing list