The Hildesheim Sprint provided a chance to meet and decide several crucial design considerations. A #pypy irc channel provided communication among participants between sprints. The sourcecode was loaded into subversion and participants given commit rights.
At the Sprint: Some folks did lots of handwaving and created really kewl concepts. Other pairs concentrated on coding, testing, builtin functions etc etc. We gathered for goalsetting meetings several times during the sprint, then split up to work on tasks. Half of the work was done by pair programming. Pairs were informal, developing and changing as tasks were discovered and completed. Sprints varied in amount of "discuss as a group" and "just do it" time. We spent lots of intense time together, not just coding but also social time, (meals, spending a day playing tourist, etc), which enhanced the building of relationships and understanding among sprinters.
Some discoveries: Plan on the first morning for hardware setup and fixing system issues, (wireless is great!) Built-in private time is necessary for the sprint. Whiteboards and projectors are both necessary, as is coffee and tea. Bringing in/providing food is fine but getting people away for lunch is good to clear their minds. Leadership varied throughout the sprints and throughout the day.
The following was written down at the first Sprint to understand each other's motivations and ideas. It's not very sorted but might still be interesting to skim.
loads bytecode
delegates/dispatches to ObjectSpaces to implement operations on the objects
define/implement a class that emulates the Python Execution Frame
use the main-loop of the interpreter to do a lot of things (e.g. do type inference during running the bytecode or not even run the bytecodes, but interpret various attributes of the code)
working together, producing something real
saving interpreter state to an image (following the smalltalk model) process-migration / persistence
looking at the entire code base (living in an image), browsing objects interactively
interactive environment, trying code snippets, introspection
deploying python made easy, integrate version control systems
integrate the various technologies on the web site, issue tracking, Wiki...
seperate exception handling from the mainline code, avoid peppering your code with try :-), put exception handling into objects.
import python code from the version control store directly, give imported code also a time dimension
combining python interpreters from multiple machines (cluster) into a virtual sandbox (agent space?)
get a smaller (maybe faster) python with very few C-code
(hoping for Psyc) to render fast code from Python code (instead of hard-c)
go to a higher level python core (and write out/generate interpreters in different languages), e.g. the former P-to-C resolved the evalframe-loop but still called into the Python-C-library which is statically coded
very far fetched: PyPython becomes a/the reference implementation
have enough flexibility to make a separate stackless obsolete
have a language that is high-level/easy enough to program but with the same performance as statically compiled languages (e.g. C++)
f = bytecode interpreter p = program a = arguments
c = compiler
assert f(p, a) == c(p)(a) == r
import the cpython distribution so we can use parts of it in our repository, make it easy to follow the cpython development
finish the python to byte code compiler in python project (this is already part of the cpython distribution, needs a python lexer)
doing other things than interpreting byte code from the python interp loop, for example generate C code, implement other object spaces in our terminlogy other far fetched things with execution
how to enter c ysystem calls into the python object space (ctypes)