# PyPy[summary-2005-11-11]

PyPy[summary-2005-11-11]
news doc contact getting-started EU/project issue

# This Week in PyPy 2

# Introduction

This is the second of what will hopefully be many summaries of what's been going on in the world of PyPy in the last week. I'd still like to remind people that when something worth summarizing happens to recommend if for "This Week in PyPy" as mentioned on:

> http://codespeak.net/pypy/dist/pypy/doc/weekly/

where you can also find old summaries.

There were about 100 commits to the pypy section of codespeak's repository this week.

# pypy-c py.py

Over the weekend (while I was being blown around Wales by the remnants of hurricane Wilma) Armin and a few others worked on trying to get a translated pypy-c to run the interpreted py.py. This resulted in a fixing a welter of small differences between CPython and pypy-c, though at the end of it all "we are still left in the dark of incomprehensible geninterplevel crashes caused by subtle differences between the most internal types of CPython and pypy-c."

# Multiple Spaces

In one of the reports we're currently writing for the end of phase 1 EU review:

> http://codespeak.net/pypy/dist/pypy/doc/draft-low-level-encapsulation.html

we made this claim:

> The situation of multiple interpreters is thus handled automatically: if there is only one space instance, it is regarded as a pre-constructed constant and the space object pointer (though not its non-constant contents) disappears from the produced source, i.e. both from function arguments and local variables and from instance fields. If there are two or more such instances, a 'space' attribute will be automatically added to all application objects (or more precisely, it will not be removed by the translation process), the best of both worlds.

And then we tried to do it, and had to tune the claim down because it doesn't work. This is because the StdObjSpace class has a 'specialized method' -- a different version of the wrap() method is generated for each type it is seen to be called with. This causes problems when there are genuine StdObjSpace instances in the translated pypy because of limitations in our tools. We looked at these limitations and decided that it was time to rewrite the world again, leading in to the next section...

# SomePBC-refactoring

One of the more unusual annotations produced by PyPy's annotator is that of 'SomePBC', short for 'SomePrebuiltConstant'. This annotation means that a variable contains a reference to some object that existed before the annotation process began (key example: functions). Up until now, the annotation has actually explicitly included which prebuiltconstants a variable might refer to, which seems like the obvious thing to do. Unfortunately, not all things that we'd like to annotate as a prebuiltconstant actually exist as unique CPython objects -- in particular the point of specializing a function is that it becomes many functions in the translated result. Also for 'external', i.e. not written in RPython, functions we want to be able to supply annotations for the input and exit args even if there is no corresponding CPython function at all.

The chosen solution is to have the SomePBC annotation refer not to a CPython object but to a more abstracted 'Description' of this object. In some sense, this isn't a very large change but it affects most files in the annotation directory and a fair fraction of those under rpython/ and translator/. We're also cleaning up some other mess while we're there and breaking everything anyway.

# Draft-Dynamic-...

It's not linked from anywhere on the website (yet...) but the report that will become "Deliverable 05.1":

> http://codespeak.net/pypy/dist/pypy/doc/draft-dynamic-language-translation.html

has been reviewed and re-reviewed in the last couple of weeks and is definitely required reading for anyone who has an interest in the more theoretical side of PyPy.

# Gtbg Sprint in December

Hopefully very soon, we'll announce the next PyPy sprint... stay tuned!