Mailman 3 March 2004 - pypy-dev

Of interest, eventually? (IBM opening ppc h/w design)
by Bengt Richter April 2, 2004

April 2, 2004

Here is IBM's announcement: http://www-306.ibm.com/chips/news/2004/0331_power.html and Wired's blurb on it: http://www.wired.com/news/infostructure/0,1377,62885,00.html?tw=wn_tophead_2 What would you do if you could design ideal h/w support for python or a python VM? For memory allocation/garbage collection? Monitoring/detecting dynamic conditions triggering recompilation/re-optimization etc? Position-independent code and structures? Threading/context switching/timeouts/atomic queue stuff/etc? Profiling support at the hardware level? Crypto stuff? Sandboxing/capability support/etc? How would pypy adapt-to/have-an-advantage-in-exploiting the existence of such a configurable h/w platform? Anyway, just thought I'd pass on an interesting blurb maybe to keep in mind. Regards, Bengt Richter

4 3

PyCON bits
by Armin Rigo March 30, 2004

March 30, 2004

Hello! As promized, here are a few bits of news from PyCON... This isn't a complete report (there are blogs out there for that). It's just a few PyPy-oriented notes. The sprints: I participated in the Python Core sprint. There was some lack of a concrete objective, Guido and Tim Peters didn't show up a lot (I know Guido was ill). So people just formed loose groups, changing over the days, doing a wide range of small stuff. I did a few bits on performance in CPython and some core stuff, mostly with Martin von Loewis, who embarked on the cruisade against start-up time. Mitchell Kapor's keynote (Using Python to Develop a Large-Scale Open Source Application: A Report from the Field): the two main points stressed by Mitchell is that Python needs (1) more performance and (2) more security. Looks familiar? IronPython (Jim Hugunin): Python for .NET. Seems to be very fast, up to 40% better than CPython. The trick is to contrieve as much as possible (and more!) the Python semantics so that they fit into existing .NET built-in operations. .NET itself is then able to optimize them extremely agressively. The result is generally significantly faster than CPython. What we could learn from IronPython is how the common cases are speeded up by a lot of boilerplate "fast-path" code (i.e. there is a 8x8 table for calling a function with 0 to 7 arguments when the function expects 0 to 7 arguments). The other thing we could learn is how to use .NET as a PyPy target platform, what the tricks and the main limitations are. But Jim doesn't release code before he thinks it is finished :-( Starkiller (Michael Salib): this is a purely static source-to-source Python-to-C++ translator, which does type inference. It works by analysing a graph which closely mirrors the Python source code. As expected, it has some trouble with the most dynamic features like exec/eval, but it is relatively advanced in some directions like OO. Some control structures (like 'for') are not implemented. Bob Ippolito came up with an incredibly cool idea: we can already generate control flow graphs, which give a low-level pre-processed version of a Python source; so we should just feed that into Starkiller, which would analyse it and translate it into C++. Starkiller shouldn't try to parse the source and analyse at the source syntax level -- we can do better with the control flow graphs. But we shouldn't try to reimplement type inference -- Starkiller does a better job at that. Starkiller is precisely the component we are missing in our translation project! Starkiller isn't released yet, as far as I know. I'll talk to Michael about it. Hopefully we can get the core of Starkiller under a non-GPL license (some old web pages from 2001 talk about an upcoming GPL release of Starkiller). Bob Ippolito talked about attending the PyPy sprint at EuroPython. (He was at the Stackless sprint.) We should talk to Michael as well. Guido's keynote (Python 3000): some directions for the next major rewrite of Python. I have a rant against both issues in the language evolution that he talked about: a syntax for types, and much more iterators. As far as I can see, both are essentially a way to improve the performance and reduce the simplicity of the language. I'm ok with performance tricks that don't show up on the user, but not with the ones that require him to learn new ways of getting the job done when there is already one. Particularly when we have the theory to recover most of that performance automatically. """Q: Will python 3k be built in python? A: Ask Armin (Rigo) and Laura (Creighton). If they succeed it's possible for Pypy to be the base for Python 3K. Guido thinks it's about as likely as Python 3K being written on top of Parrot...""" Let's prove him wrong! A bientot, Armin.

4 5

status of PyPy
by holger krekel March 28, 2004

March 28, 2004

hi pypy-dev, just wanted to drop some information about what is currently going on with PyPy. Our last sprint took place in Amsterdam late december and since then most of us were quite busy with lots of other stuff and/or with negotiating with the European Union regarding our accepted PyPy proposal. Now the negotiations are still dragging on and we have to plan and commit ourselves for two years which is no easy task. So we are to invest all the time we can into that because we could still loose the contract. During the last three month codng mostly took place in peripheral parts of pypy, one of them a new testing framework with some surprising features but more about that later :-) These three month already feel like an eternity ... The next big challenge for PyPy is translation into low level code. We had some small breakthroughs (producing efficient low-level code for a sieve of erasthosthenes python implementation) but getting it to work for more complex programs like PyPy itself remains an open challenge. The next sprint should bring us a lot closer. Speaking of which, i guess we definitely will hold a one-week sprint before EuroPython, probably starting on 30th of June. Please mark that in your calendar. And make sure that you don't miss out yet another great python conference after Pycon :-) Btw, expect some nice report from Armin from Pycon with special respect to pypy-related topics (he promised it because us other people have to deal with EU details). I can't wait :-) There also is the idea that we try to do a sprint around Python UK 2004 in April. No concrete planning has taken place, though, because all of us were so insanely busy. If someone could help with organizing a PyPy sprint there that would be wonderful! so much, for now, have fun, holger krekel

2 2

OSCON turned down my proposal for a PyPy interim report
by Laura Creighton March 21, 2004

March 21, 2004

Said there were too many good proposals this year. Maybe we need a larger Python section, then. Laura

2 1

Multimethods again
by Armin Rigo March 7, 2004

March 7, 2004

Hello everybody, I just found out a neat way to do simple multimethods in Python, so I thought I'd share it with you :-) The following is only for dispatching over two arguments. The idea is to use a pair(a,b) object that is just like a tuple (a,b), but with methods. Any (regular Python) method that you put in the class of pair(a,b) works like a multimethod dispatching on both a and b. The metaclass hack is only a syntactic convenience. I don't know if this is relevant to PyPy. It's probably one of the shortest multimethod implementations for Python, whereas PyPy's is probably one of the longest :-) Armin # ______________________________________________ class extendabletype(type): """A type with a syntax trick: 'class __extend__(t)' actually extends the definition of 't' instead of creating a new subclass.""" def __new__(cls, name, bases, dict): if name == '__extend__': return bases[0] # return existing base else: return type.__new__(cls, name, bases, dict) def __init__(self, name, bases, dict): if name == '__extend__': for key, value in dict.items(): setattr(self, key, value) def pair(a, b): """Return a pair object.""" tp = typeofpair(a.__class__, b.__class__) return tp((a, b)) # tp is a subclass of tuple pairtypecache = {} def typeofpair(cls1, cls2): """type(pair(a,b)) is typeofpair(a.__class__, b.__class__).""" try: pair = pairtypecache[cls1, cls2] except KeyError: name = 'typeofpair(%s, %s)' % (cls1.__name__, cls2.__name__) bases1 = [typeofpair(base1, cls2) for base1 in cls1.__bases__] bases2 = [typeofpair(cls1, base2) for base2 in cls2.__bases__] bases = tuple(bases1 + bases2) or (tuple,) # 'tuple': ultimate base pair = pairtypecache[cls1, cls2] = extendabletype(name, bases, {}) return pair # ____________________________________________________________ class A(object): pass class B(object): pass class C(A): pass class D(B): pass a = A() b = B() c = C() d = D() assert isinstance(pair(a,b), typeofpair(A, B)) class __extend__(typeofpair(A, B)): def add((a, b)): print "a+b" def sub((a, b)): print "a-b" class __extend__(typeofpair(C, B)): def add((c, b)): print "c+b" # alternate less magic syntax def sub((a, d)): print "a-d" typeofpair(A, D).sub = sub pair(a,b).add() pair(a,b).sub() pair(c,d).add() pair(c,d).sub()

3 3