Python IS slow ! [was] Re: Python too slow for real world

[Michael Hudson]

Michael Hudson <mwh21 at cam.ac.uk> writes:
> It goes on...
> 
> Christian Tismer <tismer at appliedbiometrics.com> writes:
> > Michael Hudson wrote:
> > > The similarity of the code in xapply.py and in closure.py makes me
> > > think that I should write some general framework for mutilating
> > > codestrings. Support for changing the length of the codestring is
> > > pretty much a must for that.
> > 
> > Maybe, yes. WOuld mean to break the code list into slices,
> > add some lables, and re-resolve them again. Looks like
> > not the big deal, but some work.
> > 
> 
> I've abandonded any hope of doing any real work this evening and
> bashed on this a bit more. There's a new tarball on the starship that
> implements a first attempt at a general code editing framework, and a
> (buggy) implementation of an attribute freezer.
> 
> Comments are very much appreciated! My background isn't in this kind
> of stuff (heck, I'm a mathematician), so if someone knows a better way
> of organising things, I'd certainly like to know
> 
> > Thanks for the fun. 
> > Wondering how far this can continue :-)
> 
> I'm sure there's life in it yet...
> 
> Michael

Well, everyone seems to have ignored that code, which is fair enough
because it sucked. There's yet another tarball on starship (release
early! release often!) - go to http://starship.python.net/crew/mwh and
click the link.

Here's what I've added to the README (which should probably be called
NEWS, but never mind):

-- begin

Thu May  6 11:47:54 BST 1999

Update! I've added a more general code editing packages, in
code_editor.py.

The centerpiece of the module is the CodeString class. This allows one
to treat a code string as a list of instructions. The (auto-generated)
file ops.py contains a class for each opcode, so you can do things
like this:

cs=code_editor.CodeString(<some codestring>)
cs[0:3]=[ops.SET_LINENO(3),ops.LOAD_CONST(0),ops.RETURN_VALUE()]
cs.assemble() => a codestring that can be passed to new.code.

code_editor.py also contains a couple of classes to make editing code
objects (as opposed to code strings) and function easier.

So you can do this:

from bytecodehacks import code_editor,ops

def f():
    return "This function does something really interesting"
    
g=code_editor.Function(f)
g.func_code.co_code[:]=[ops.SET_LINENO(3),
                        ops.LOAD_CONST(len(g.func_code.co_consts)),
                        ops.RETURN_VALUE()]
g.func_code.co_consts.append("Not any more!")
g=g.make_function()
print f()
print g()

to produce:

This function does something really interesting
Not any more!

This is just a toy example, obviously. This package doesn't make
bytecode twiddling *easy*, but it does help not having to worry too
much about recomputing jumps.

To see some more concrete examples of use, look at xapply2.py and
attr_freeze.py.

xapply2.py contains another implementation of xapply (see below).

attr_freeze.freeze_attrs does a similar job to closure.bind below, but
can resolve attribute references too. It can't use the cute
`bind(f,var=value)' interface of bind, but I've made efforts to make
it as painless to use as possible. An example:

from bytecodehacks import attr_freeze
import sys

def ff(x):
    if x:
        print sys.exit
    else:
        print sys.copyright

_=attr_freeze.Ref()

gg=attr_freeze.freeze_attrs(ff,
                            _.sys.exit,sys.exit,
                            _.sys.copyright,sys.copyright)

I hope someone finds these interesting.

Thanks again for taking an interest!

-- end

I have some even more grandiose plans for this project - constant
expression evaluation, maybe, or how about a function inliner?

Revise, Michael, revise!

Michael