Mailman 3 January 2003 - pypy-dev

smalltalk as a model?
by Stephan Diehl 05 Feb '03

05 Feb '03

Hello, during the last days I got a little bit interested in smalltalk (article in c't 2/2003). Since smalltalk is already about 30 years old and shares some similarities to Python, some aspects of smalltalk might ease the effort to implement Python in Python. Here are some smalltalk faclets that makes it interesting: - Everything is an object (even classes and code blocks for example) - All actions are performed by invoking an object method (even loops) - there are only 5 keywords and only a couple of "special" characters - the smalltalk VM is implemented in smalltalk - smalltalk comes with "batteries included" With smalltalk in mind, one could write a kind of ProtoPython that has much less overhead than the existing Python. Possible features of a ProtoPython (very incomplete): - smaller set of reserved words ("print","import",etc. shouldn't be reserved words) - no operators, '+','-',... will be methods - at least the for loop could be a method of a (to be defined) list class. Even if this approach is absolutely ridiculous, just looking at smalltalk might give some ideas/hints how to construct a self describing language. Some Links: Squeak (open source smalltalk runtime): http://www.squeak.org smalltalk 80 :The Language and Its Implementation (contains details about the VM): http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_imp_toc.html [Python-Dev] Classes and Metaclasses in Smalltalk: Guido about a mail from Jim Althoff, inventor of smalltalk metaclasses http://mail.python.org/pipermail/python-dev/2001-May/014508.html smalltalkish python: http://squeak.cs.uiuc.edu/mail/squeak/msg04577.html Stephan

3 3

List Summary Volunteer
by Troy Melhase 04 Feb '03

04 Feb '03

Hi Folks: I've been lurking on pypy-dev since the original announcement, and I'd like to help out in some way. I'm not a compiler writer, nor a C coder, but I think I can write a summary for the list traffic once a week. I assume that simply volunteering is enough to be given this responsibility. Sometime Saturday, I'll summarize the traffic from the last three weeks and send them to the list and to c.l.p for group review. Comments? -troy

4 7

Re: [pypy-dev] Is the mailing list out of order? has it moved?
by roccomoretti＠netscape.net 31 Jan '03

31 Jan '03

Christian Tismer <tismer(a)tismer.com> wrote: >That's it. Many ideas have been spread on this >list, much has been said, but we don't have >a summary. What we need instead of the list >is now a Wiki, where we can begin to build a >project plan, summaries of (also different) >concepts, and first existing demo code snippets. There seemed to be a lot of support for a python-dev style mailing list summary. Was there any brave soul who actually agreed to write it? (As opposed to the lazy/busy among us [and I include myself here] who thought that "someone else" should do it.) - Rocco __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

2 1

Builtin types
by Scott Fenton 30 Jan '03

30 Jan '03

Hello all. While trying to mix up some more stuff for __builtin__, I came up with an interesting problem. The solution I found for classmethod (using google on c.l.python, since I couldn't figure it out myself) requires that classes that use it must derive from object. That made me wonder, could we just automatically derive everything from object in Minimal? The big problem with doing this in CPython, as I understand it, is extensions that need to be converted, but we don't have that problem here, obviously. So would it be alright if I went ahead and used this code as if everything derived from object? -Scott -- char m[9999],*n[99],*r=m,*p=m+5000,**s=n,d,c;main(){for(read(0,r,4000);c=*r; r++)c-']'||(d>1||(r=*p?*s:(--s,r)),!d||d--),c-'['||d++||(*++s=r),d||(*p+=c== '+',*p-=c=='-',p+=c=='>',p-=c=='<',c-'.'||write(1,p,1),c-','||read(2,p,1));}

10 32

Re: [pypy-dev] Builtin types
by Bengt Richter 28 Jan '03

28 Jan '03

At 00:21 2003-01-28 +0100, Christian Tismer wrote: >Armin Rigo wrote: >>Hello Holger, >>On Mon, Jan 27, 2003 at 08:03:40PM +0100, Samuele Pedroni wrote: >> >>>>how do you intend to use any of the existing C-libraries, then? >>>>Rely on CPython to provide the binding? >>> >>>The point was whether you want your builtin types "abstractions" to be directly >>>ctypes based. >> >>Yes, sorry. I was thinking about that, i.e. how we internally represent the >>built-in types. Being able to call external C code is another matter. >> >>>>I think that progressing in the ctypes direction can happen in >>>>parallel with Python-Core pythonifications. Beeing able to make >>>>C-library calls (like File-IO) without specialized intermediate C-code >>>>does seem like an important feature. >> >>Yes, although I have another potential objection here. It might not be a >>problem to have specialized intermediate C code if this code is generated, >>just like -- after all it's the goal -- most of the rest of the final C code >>of the interpreter. Then what we need is a way to *describe* calls to a C >>function rather than a way to actually *do* the calls. So ctypes is a good Warning: preliminary thoughts, not implemented ;-) This focuses here on calling into C, but it is really a generic abstract approach, if you look at it that way ;-) meta_eval(i386_call_thunk_representation_as_bitstruct) where meta_eval expects a single structured Bits instance as an argument, and expects that to have info for extracting a type header first of all, and various other structure depending on that. I.e., it needs structure info as well as data bits, meaning the whole arg is really an arg list in packed form, composed of two args: a type name, and the data itself. For meta_eval use, I think a single name signifying the type of data would be enough. Thus the encoding viewed as a Python string could be '\x02\x04i386\x??dddddddd' to signify a list of two bitstrings in byte- chunked format, the first having 4 chars and the second however many required for the machine code. Another way to spell that data as bits might be (sketching in the air here, don't take too literally, despite 386 code ;-) codebits = Bits(bytes=(0,8); argbits = Bits() # make space to pack C args representation retbits = Bits() # make space for C return value representation # ... prepare args by stuffing representations into argbits slices # ... prepare return space as zeroes or whatever thunk=I386Code() thunk.append(I386Inst('push ebp')) thunk.append(I386Inst('mov ebp, esp')) thunk.append(I386Inst('mov eax, DWORD PTR %s' % argbits.addr())) thunk.append(I386Inst('push eax')) thunk.append(I386Inst('call %s' % some_env.getaddr('_foo'))) thunk.append(I386Inst('add esp, 4')) thunk.append(I386Inst('mov DWORD PTR %s, eax' % retbits.addr())) thunk.append(I386Inst('xor eax, eax')) thunk.append(I386Inst('pop ebp')) thunk.append(I386Inst('ret 0')) map(bits.bytes.append, [2, 4, 'i386', len(thunk), thunk.to_string()]) # the thunk is a complete subroutine that meta_eval's i386 interpreter # can call without arguments. meta_eval(bits) # ... (pick up results in retbits) I.e., meta_eval is a generalization of Python eval, which only knows how to eval Python strings and code objects. meta_eval here must get a single bits (instance of Bits) argument encoded with type name and following binary data (e.g., probably located at id(bits)+8) for CPython). Once seeing the type name, meta_eval can dispatch to i386 or make a system call or run an interpreter, but that's a matter of having appropriate callables registered for the type name giving the type of that bits image being passed. Note that it could be a relocatable object file or info for loading a dll and finding somthing therein, etc. The bits as above were actually a packed argument-by-value list with an arg count at the beginning, and expected length-prefixed string as the first arg, and length-prefixed bytes as the second arg (assuming lengths >=128 would get two or four byte length codes, but this is a representation detail). Note that this all seems very hardware-oriented, but it can be viewed as abstract bit sequences and structures, and it just happens that there is (some) hardware that matches some things nicely. There are details about injecting bytes into the current process virtual memory as instructions and data etc, but this work can be encapsulated by the 'i386'-code "evaluator" used by meta_eval for 'i386' type bits data. The solutions must already be part of psyco, IWT. They must also be part of low level debuggers. These things would be very platform-specific, but hopefully meta_eval could stay mostly generic. At the lowest level, IWT meta_eval would often be optimized away. I.e., if at the byte code level, there were a META_EVAL instruction, you can see the abstraction expressed at that level, etc. I think something like this could be used to express other foreign function and data interfaces too. Presumably the pattern would be to define an ordinary python function or method, and inside it use Bits and meta_eval etc. to build special interfaces. meta_eval('DOS_BIOS', bits_for_int16_representation) or meta_eval('LINUX_SYS_CALL', ...) might also call on special "evaluators" but meta_eval itself would stay generic. IOW, you could also generate linux system call ints or PC BIOS ints, since we're talking about arranging bits with Bits methods and arranging to have those bits seen by the CPU by way of meta_apply. Of course you could also get executable bytes by reading the output of special tools. I'm just trying to get concepts worked out re expressing creation of low level stuff and then getting it used by low level mechanisms, but all expressed in the higher level. meta_eval really ought to be viewed in abstract terms, though we are concentrating on CPU and machine language instructions and raw memory here. IOW, "meta_apply('byte_code_interp', bytecode_representation)" might be very close to the functionality of "eval(byte_code_representation)." Whereas "meta_eval('gcc', c_source)" also has the abstract idea of applying some function to interpret some input. What's the difference from just having a bunch of functions to do these things? Well, it seeks to unify the principle and identify an abstraction that can reasonably be implemented at each level in some form, whether it is a META_EVAL CPython byte code or in-lined machine code calling other machine code. I confess to a bit of handwaving, but if I hold back, there's no chance of making any contribution to early discussions. You can always ignore it if it doesn't fit into your views ;-) >>way to express such a description, but it is not necessary to rely on >>libffi-style machine-code hackery to actually perform the calls; all we need >>to do is statically emit the specialized C code into the produced interpreter >>and obtain something close to the original CPython source. > >Hmm! >It seems that I could have saved my last longer post. >We agree that we need to describe primitive types. >It is much less urgent to actually implement them. I was going to write a long answer to that, but this got kind of long, so maybe this will do. Just pick out anything useful and ignore the rest ;-) Cheers, Bengt

2 1

Re: [pypy-dev] Builtin types
by logistix 28 Jan '03

28 Jan '03

> > Whereas "meta_eval('gcc', c_source)" also has the abstract idea of > applying some function to interpret some input. What's the difference > from just having a bunch of functions to do these things? Well, it seeks > to unify the principle and identify an abstraction that can reasonably > be implemented at each level in some form, whether it is a META_EVAL > CPython byte code or in-lined machine code calling other machine code. > I confess to a bit of handwaving, but if I hold back, there's no chance > of making any contribution to early discussions. You can always ignore > it if it doesn't fit into your views ;-) > In general I agree but why not an ABC instead of a dispatch function? Something like: class evaluator: """Interface for all evaluators""" def loadData(self): pass def compile(self): pass def evaluate(self): pass And then have subclasses add more specific load_ methods: i386 = I386evaluator() i386.loadInstruction('push ebp') i386.loadInstruction('mov ebp, esp') ... i386.compile() i386.evaluate() Where exec and eval would perform "if not compiled then compile; eval;" on any evaluator.

1 0

(ad)WebRobot, Mail ID Extractor, Web Stress Tester: Free Download
by mailer＠ns1.nabitel.com 28 Jan '03

28 Jan '03

1 0

__builtin__ module
by Scott Fenton 27 Jan '03

27 Jan '03

Hello all. Due to the fact that there's no way in hell for me to get out of the US by March, and due to the fact that I love this concept, I've hacked up some basic replacements for various functions in __builtin__. The code resides at http://fenton.baltimore.md.us/pypy.py Take a look at it and tell me what you think. Currenty, this code implements everything BUT: * the exceptions (seperate concept) * builtin types (not sure how to handle them) * callable (not sure how to test) * classmethod (ditto) * coerce (tritto) * compile (needs an actual compiler, and the AST module scares me) * dir (not sure how to get current scope) * eval (not my job(TM)) * execfile (ditto(TM)) * hex, oct (lazyness, it'll be in version 2) * id (lower level than I can handle) * intern (didn't understand the docstring) * isinstance, issubclass (see classmethod) * globals, locals (not sure how to get ahold of them) * raw_input (really complex) * staticmethod (ugly hackery) * super (see classmethod) * type (need more info, dammit!) * unichr (given chr, unichr frightens me) * xrange (sorta builtin type) -Scott Fenton -- char m[9999],*n[99],*r=m,*p=m+5000,**s=n,d,c;main(){for(read(0,r,4000);c=*r; r++)c-']'||(d>1||(r=*p?*s:(--s,r)),!d||d--),c-'['||d++||(*++s=r),d||(*p+=c== '+',*p-=c=='-',p+=c=='>',p-=c=='<',c-'.'||write(1,p,1),c-','||read(2,p,1));}

9 37

Questions for Armin
by Edward K. Ream 27 Jan '03

27 Jan '03

My long posts were intended, in part, to expose my assumptions for correction if needed. Here are what I conceive to be the key questions about psyco: 1. How often and under what circumstances does psyco_compatible get called? My _guess_ is that it gets called once per every invocation of every "psycotic" function (function optimized by psyco). Is this correct? 2. True or false: the call to psyco_compatible would be equivalent to runtime code that discovers special values of certain particular variables. 3. True or false: adding more state information to psyco (in order to discover more runtime values) will slow down psyco_compatible. 4. Are these the most important questions to ask about psyco? If not, what _are_ the key questions? Thanks very much. Edward -------------------------------------------------------------------- Edward K. Ream email: edream(a)tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html --------------------------------------------------------------------

9 19

New __builtin__
by Scott Fenton 27 Jan '03

27 Jan '03

Yes, everyone, it is the moment you have all dreaded. A new version of pure python __builtin__s. This version contains nudity, sexual references, chr implemented using '%c'%i, an optimized ord, multiarg map and zip, and the new functions unichr, oct, hex, staticmethod, *attr (for * in (get,has,set)), isinstance, issubclass, and slice. I did not include classmethod as this seems to warrent further discussion. Stuff I think can be easily done in python that haven't been yet: dir, raw_input, reload, round, and xrange. thinks-python-can-be-faster-than-c-ly yours, -Scott -- char m[9999],*n[99],*r=m,*p=m+5000,**s=n,d,c;main(){for(read(0,r,4000);c=*r; r++)c-']'||(d>1||(r=*p?*s:(--s,r)),!d||d--),c-'['||d++||(*++s=r),d||(*p+=c== '+',*p-=c=='-',p+=c=='>',p-=c=='<',c-'.'||write(1,p,1),c-','||read(2,p,1));}

6 11