Mailman 3 June 2003 - pypy-dev

Re: [pypy-dev] Very relevant stuff (was: [pypy-svn] rev 812 - in pypy/trunk/src/pypy:interpreter objspace/std objspace/std/test)
by Laura Creighton June 16, 2003

June 16, 2003

In a message of Mon, 16 Jun 2003 16:16:07 +0200, Armin Rigo writes: >Hello Christian, > >On Mon, Jun 16, 2003 at 02:47:41AM +0200, Christian Tismer wrote: >> I thought it would make sense to post the most relevant >> text of this check-in to the list. >> >> >Added: pypy/trunk/src/pypy/objspace/std/mm_notes.txt >> >... > >Done. This was a design document for me, I wrote it to clear out how >delegation should cleanly work before I went out … [View More]

2 1

Re: [pypy-dev] reorganized Wiki
by Laura Creighton June 16, 2003

June 16, 2003

In a message of Mon, 16 Jun 2003 17:04:49 +0200, holger krekel writes: >[Laura Creighton Mon, Jun 16, 2003 at 04:55:33PM +0200] >> where did the rest of the things about the Hildesheim and Gothenburg >> Sprints go? I want to refer to them for the OSCON talk. Where's the >> picture of TrilkeGut? > >Most of them can be found under the TitleIndex (letter "S") > > http://codespeak.net/moin/pypy/moin.cgi/TitleIndex > >but they are pretty uninteresting … [View More]

1 0

Did Armin or Michael log the conversation they had on Friday on irc?
by Laura Creighton June 16, 2003

June 16, 2003

Jacob read it and thought it was wonderful, and I would like to read it if one of you logged it -- or if anybody else was there and logged it. Should we ask Moshez for a bot? Laura

2 2

reorganized Wiki
by Laura Creighton June 16, 2003

June 16, 2003

where did the rest of the things about the Hildesheim and Gothenburg Sprints go? I want to refer to them for the OSCON talk. Where's the picture of TrilkeGut? Laura

2 1

Very relevant stuff (was: [pypy-svn] rev 812 - in pypy/trunk/src/pypy:interpreter objspace/std objspace/std/test)
by Christian Tismer June 16, 2003

June 16, 2003

Howdy, I thought it would make sense to post the most relevant text of this check-in to the list. It also would make sense to add this to the PyPy Wiki. arigo(a)codespeak.net wrote: > Added: pypy/trunk/src/pypy/objspace/std/mm_notes.txt > ============================================================================== Notes on Multimethods ********************* Interpreter-level classes correspond to implementations of application-level types. Several implementations can be given for … [View More]the same type (e.g. several ways to code strings or dictionaries), and conversely the same implementation can cover several types (e.g. all instances of user-defined types currently share the same implementation). The hierarchy among the classes used for the implementations is convenient for implementation purposes. It is not related to any application-level type hierarchy. Dispatch -------- Multimethods dispatch by looking in a set of registered functions. Each registered function has a signature, which defines which object implementation classes are accepted at the corresponding argument position. The name 'W_ANY' is a synonym for 'W_Object' (currently, possibly 'object' later). As it accepts anything, it is the only way to guarantee that the registered function will be called with exactly the same object as was passed originally. ATTENTION: in all other cases the argument received by the function may have been converted in some way. It must thus not be considered to be 'id'entical to the original argument. For example it should not be stored in a data structure, nor be queried for type, nor be used for another multimethod dispatch -- the only thing you should do is read and write its internal data. For example, 'getattr(obj, attr)' is implemented with a W_StringObject second argument when all it needs is just the name of the attr, and with a W_ANY when the 'attr' object could be used as a key in obj.__dict__. Delegation ---------- Delegation is a transparent convertion mechanism between object implementations. The convertion can give a result of a different type (e.g. int -> float) or of the same type (e.g. W_VeryLongString -> str). There is a global table of delegators. We should not rely on the delegators to be tried in any particlar order, or at all (e.g. the int -> float delegator could be ignored when we know that no registered function will accept a float anyway). Delegation is also used to emulate inheritance between built-in types (e.g. bool -> int). This is done by delegation because there is no reason that a particular implementation of a sub-type can be trivially typecast to some other particular implementation of the parent type; the process might require some work. Types ----- Types are implemented by the class W_TypeObject. This is where inheritance and the Method Resolution Order are defined, and where attribute look-ups are done. Instances of user-defined types are implementated as W_UserObjects. A user-defined type can inherit from built-in types (maybe more than one, although this is incompatible with CPython). The W_UserObject delegator converts the object into any of these "parent objects" if needed. This is how user-defined types appear to inherit all built-in operator implementations. Delegators should be able to invoke user code; this would let us implement special methods like __int__() by calling them within a W_UserObject -> int delegator. Specifics of multimethods ------------------------- Multimethods dispatch more-specific-first, left-to-right (i.e. if there is an exact match for the first argument it will always be tried first). Delegators are automatically chained (i.e. A -> B and B -> C would be combined to allow for A -> C delegation). Delegators do not publish the class of the converted object in advance, so that the W_UserObject delegator can potentially produce any other built-in implementation. This means chaining and chain loop detection cannot be done statically (at least without help from an analysis tool like the translator-to-C). To break loops, we can assume (unless a particular need arises) that delegators are looping when they return an object of an already-seen class. Registration ------------ The register() method of multimethods adds a function to its database of functions, with the given signature. A function that raises FailedToImplement causes the next match to be tried. 'delegate' is the special unary multimethod that should try to convert its argument to something else. For greater control, it can also return a list of 2-tuples (class, object), or an empty list for failure to convert the argument to anything. All delegators will potentially be tried, and recursively on each other's results to do chaining. A priority ordering between delegators is used. See objspace.PRIORITY_*. Translation ----------- The code in multimethod.py is not supposed to be read by the translator-to-C. Special optimized code will be generated instead (typically some kind of precomputed dispatch tables). Delegation is special-cased too. Most delegators will be found to return an object of a statically known class, which means that most of the chaining and loop detection can be done in advance. Multimethod slicing ------------------- Multimethods are visible to user code as (bound or unbound) methods defined for the corresponding types. (At some point built-in functions like len() and the operator.xxx() should really directly map to the multimethods themselves, too.) To build a method from a multimethod (e.g. as in 'l.append' or 'int.__add__'), the result is actually a "slice" of the whole multimethod, i.e. a sub-multimethod in which the registration table has been trimmed down. (Delegation mechanisms are not restricted for sliced multimethods.) Say that C is the class the new method is attached to (in the above examples, respectively, C=type(l) and C=int). The restriction is based on the registered class of the first argument ('self' for the new method) in the signature. If this class corresponds to a fixed type (as advertized by 'statictype'), and this fixed type is C or a superclass of C, then we keep it. Some multimethods can also be sliced along their second argument, e.g. for __radd__(). -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ [View Less]

2 1

PyPy -- Lua
by Christian Tismer June 16, 2003

June 16, 2003

Hi all, just by chance, I stumbled over a post from Gustavo Niemeyer on the python list: "Python articles". He mentioned his website, which an article "- Why Lua was embedded in APT-RPM". https://moin.conectiva.com.br/GustavoNiemeyer Here that particular excerpt: """ Why Lua? One might think I've used Lua just because I live in the same country as its core developers (Brazil), but that's not the case. Indeed, I've done a pretty intensive research about embeddable languages before choosing … [View More]

1 0

Re: [pypy-svn] rev 810 - pypy/trunk/src/pypy/interpreter/test
by Michael Hudson June 16, 2003

June 16, 2003

hpk(a)codespeak.net writes: > Author: hpk > Date: Sat Jun 14 19:38:55 2003 > New Revision: 810 > > Modified: > pypy/trunk/src/pypy/interpreter/test/test_interpreter.py > Log: > fixed test_raise test checking for wrong error message > This will break the test when run under the trivial object space. I'm hoping that soon we'll be able to write all these tests in application space, and so some of the bizarre hacks in (particularly) test_interpreter will be able to … [View More]

1 1

Re: [pypy-svn] rev 809 - pypy/trunk/src/pypy/objspace/std
by Christian Tismer June 16, 2003

June 16, 2003

hpk(a)codespeak.net wrote: > Author: hpk > Date: Sat Jun 14 19:15:16 2003 > New Revision: 809 > > Modified: 19 modified source files. > Log: > revised multimethod registration machinery > > - now functions whose name is of the form "X__Y1_Y2_..." > are registered on the multimethod "X" on StdObjSpace or > (if that doesn't exist) on an alternatively provided namespace's > multimethod. Etc. I don't recall that this change has been agreed upon. I … [View More]

2 2

Objects and types in the stdobjspace
by Armin Rigo June 14, 2003

June 14, 2003

Hello everybody, Here is a technical note for the way Samuele and I implemented objects and types based on multimethods. In objspace/std/ you will find for each type xxx two files: xxxobject.py and xxxtype.py. The former defines a class W_XxxObject. Each instance of W_XxxObject is seen by the user (i.e. the person using the language, i.e. application-level) as an object of type xxx. The xxxtype.py file, on the other hand, defines a class W_XxxType, which is expected to have exactly one … [View More]instance, which is what the user sees as the xxx type object (e.g. the single instance of W_IntType is what the user sees as 'types.IntType' or 'int'). The same applies to the type 'object': it has a objectobject.py file defining the class W_ObjectObject, whose instances are the direct instances of 'object', i.e. what the user can have by writing 'object()'. These are pretty featureless. There is also objecttype.py with the class W_ObjectType whose single instance is seen as 'object', the type. The same for type objects: the file typeobject.py defines the class W_TypeObject, whose instances are types. That's why all other W_XxxType classes actually inherit (at interpreter-level) from W_TypeObject. And there is W_TypeType in typetype.py whose single instance is the 'type' type. The situation for user-defined types and instances of these types is more problematic. Right now, all user-defined type object are instances of W_UserType, found in usertype.py, and instances of these user-defined types are instances of W_UserObject from userobject.py. Application-level inheritance is not visible at all as inheritance among these interpreter-level classes; there is some look-up mecanism in W_TypeObject that is responsible for emulating it. (This is necessary, otherwise we would be stealing the underlying inheritance mecanism of CPython, which is not what we want to do for user-defined types with possibly multiple inheritance and method resolution orders that depend on the CPython version!). There is a problem, however, which is related to how we hack to let a W_UserObject pass for some other W_XxxObject class for some other parts of the stdobjspace. Try for example: >>> class specialtype(type): ... pass ... >>> specialtype('L', (list,), {}) <specialtype object at 138362900> >>> L = _ >>> L([1,2,3]) File ".../userobject.py", line 51, in getsinglebuiltintype mro = list(w_type.getmro()) AttributeError: W_UserObject instance has no attribute 'getmro' (I'm going to try to fix this right now.) This is because w_type contains the 'L' object, which the interpreter expects to be a W_TypeObject, but which is actually a W_UserObject because it is an instance of the W_UserType named 'specialtype'. We'll have to sort this out, and a proper solution probably means starting with the following: in CPython, if say C inherits from the built-in class D, then instances of C are implemented as a structure which starts with the same fields as a D structure. This is so that the PyObject* pointer can pass for a pointer to the structure can pass for a pointer to a C or a D object, for the interpreter. In PyPy, we can emulate this behavior in W_UserObject: an instance of W_UserObject could pass for an instance of some other dynamically-determined W_XxxObject using some __getattr__ hacks. This can be written in such a way that it is RPython-friendly, so that the C translator knows that it is expected to produce compatible structure layouts and do pointer typecasts. Interestingly, we could also later add other implementations of W_UserType that don't suffer from this restriction. A bientôt, Armin. [View Less]

3 13

dis.dis(dis.dis)
by Armin Rigo June 13, 2003

June 13, 2003

Hello everybody, The profiling data Michael posted to this list is a result of some work we did to get dis-goal.py working (i.e. dis.dis(dis.dis)). It still doesn't work, but a pre-version does, checked in in dis-pregoal.py, which reads: dis.disassemble(dis.dis.func_code) which takes a good few minutes to complete :-) Armin

1 0