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 16 Jun '03

16 Jun '03

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 and re-implemented it to >actually work like that. > > >Armin Is it living someplace on the Wiki now? or in our doc directory? Laura

2 1

Re: [pypy-dev] reorganized Wiki
by Laura Creighton 16 Jun '03

16 Jun '03

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 from today's point of view, >because they are mostly organizational stuff. Thanks Holger. > >The "winter Trillke-Gut" picture is here > > http://www.trillke.net/images/trillke_schnee.png Ah, pretty. > >and today's is here > > http://www.trillke.net/images/trillke-front.jpg Pretty today, too. >We should have one person writing summaries of each >sprint. They should be the main documents when refering >to "old" sprints. You want to write up Hildesheim and I will write up Gothenburg? Also, do we have a 'how this came to be' document? I'd like 1 paragraph for the OSCON talk, but I cannot write it, because I wasn't there ... > >greetings, > > holger Thanks very much, Holger ... Laura

1 0

Did Armin or Michael log the conversation they had on Friday on irc?
by Laura Creighton 16 Jun '03

16 Jun '03

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 16 Jun '03

16 Jun '03

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 16 Jun '03

16 Jun '03

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 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/

2 1

PyPy -- Lua
by Christian Tismer 16 Jun '03

16 Jun '03

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 Lua. I was looking for a fast, and small language. When you have a library which has about 500kb, you can't embed a large interpreter to extend the functionality, otherwise you'd be extending the interpreter, not the library. One might think that the interpreter library would be in the system anyway, so that wouldn't be a real problem. Unfortunately, that doesn't apply to APT-RPM, since it is used in small systems, and in installer environments. The current Lua interpreter is still under 100kb, and is very fast if compared to other interpreters. I really think the Lua interpreter has no current competitors in that specific area. """ How is this related to PyPy? Well, you guessed it. PyPy still has a particular branch of thought in it: Minimal Python. That is, as one target of PyPy, we should eventually be able to spit out some very tiny embeddable interpreter, that can compete with, say, Lua. cheers - chris -- 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/

1 0

Re: [pypy-svn] rev 810 - pypy/trunk/src/pypy/interpreter/test
by Michael Hudson 16 Jun '03

16 Jun '03

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 go away. Cheers, M. -- > I'm a little confused. That's because you're Australian! So all the blood flows to your head, away from the organ most normal guys think with. -- Mark Hammond & Tim Peters, comp.lang.python

1 1

Re: [pypy-svn] rev 809 - pypy/trunk/src/pypy/objspace/std
by Christian Tismer 16 Jun '03

16 Jun '03

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 understood this as just an idea, posted for discussion. Am I missing something from the last messages? Otherwise I would like to ask this admittedly anarchical group, to define *how* anarchical it is planning to be in the future. ... > - remaining is "intobject.py" because test/test_intobject.py > uses the intobject.* names directly instead of going through > the StdObjSpace. Actually, at first i also changed intobject > and test_intobject but i didn't understand the "OverflowError" > handling so i reverted my changes to not destroy anything > > could someone explain the r_int / int / long / overflow business > on pypy-dev? You have been pondering about intobject in another mail to pypy-dev as well. I would like to remind you that this was implemented by me on the first sprint, as one of the very first, really complete implementations of anything not faked. It is therefore in the style of that time, which has changed in the between, of course. Most probably, you are unaware of this, or you would surely have asked me, directly. On your questions concerning restricted integers: Please see http://codespeak.net/moin/pypy/moin.cgi/RestrictedPython and the chapter there named "Example: Integer Types", which I also wrote on that sprint. If you need any information in extent of this, please let me know. Maybe there are some bigger omissions. ciao - chris -- 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/

2 2

Objects and types in the stdobjspace
by Armin Rigo 14 Jun '03

14 Jun '03

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 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.

3 13

dis.dis(dis.dis)
by Armin Rigo 13 Jun '03

13 Jun '03

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