PyAsm

[Stefan Behnel]

Hi!

What about an interface like this:

------------------------------
@pyasm
def hello_world(*some_args):
"""
!CHARS hello_str 'Hello world!\n\0'

!PROC hello_world PYTHON
!ARG self
!ARG args

PUSH hello_str
CALL PySys_WriteStdout
ADD ESP, 0x4
MOV EAX,PyNone
ADD [EAX],1
!ENDPROC
"""

hello_world(1,2,3)
------------------------------

Meaning: Put the assembler into the doc-string of a function. Then use a
decorator to run the assembler on the function's __doc__ string and build an
assembly function that takes the same arguments to make the assembly function
directly callable.

Maybe the decorator line has to look like this:
@pyasm(globals())
or something like that, I can't tell. I don't think it would be much work to
implement this.

Stefan

 

[Roger Binns]

Meaning: Put the assembler into the doc-string of a function.

That has several issues. One is that you can't do string operations with
it. Say you wanted some %d, %s etc in the string. If you use a documentation
generator (eg epydoc) then the code becomes the API documentation for the
function. Finally it bloats binary distributions. For example BitPim
is 7-10MB binary distribution, full compressed with all doc strings
removed. Including doc strings adds another 3MB to the compressed binary
size!

Instead I would suggest looking at the compile/eval/exec builtins in Python
for inspiration. You can give a string to compile and it gives you something
you can execute later in varying contexts.

Roger

 

[olsongt]

Hey Roger,

I didn't realize that Stefan replied to the list and sent a private
email reply. There seemed to be a lag in google groups today. I
basically told him that I might be crazy enough to write an assembler
in python, but I'm not crazy enough to start using those function
decorators.

I'm working more on the backend stuff now but I was considering adding
the hook. I never realized that you couldn't use string interpolation
on a docstring, so that's probably the showstopper. I don't want to
take that functionality away.

I was thinking that the decorator could cheat and just swallow the
originating docstring when returning the assembly function.
Introspection based tools (which I'm assuming epydoc is) would only see
the new docstrings on the assembly function. Not that I have docstring
functionality built in yet but it's on the todo list. Size also isn't
an issue because I'm currently using a string anyway. But lack of
string interpolation is an issue.

-Grant

P.S. Where'd you get that cool source code formatter for BitPim ;-)

 

[Stephen Thorne]

Hey Roger,

I didn't realize that Stefan replied to the list and sent a private
email reply. There seemed to be a lag in google groups today. I
basically told him that I might be crazy enough to write an assembler
in python, but I'm not crazy enough to start using those function
decorators.

I'm working more on the backend stuff now but I was considering adding
the hook. I never realized that you couldn't use string interpolation
on a docstring, so that's probably the showstopper. I don't want to
take that functionality away.

I was thinking that the decorator could cheat and just swallow the
originating docstring when returning the assembly function.
Introspection based tools (which I'm assuming epydoc is) would only see
the new docstrings on the assembly function. Not that I have docstring
functionality built in yet but it's on the todo list. Size also isn't
an issue because I'm currently using a string anyway. But lack of
string interpolation is an issue.

Have you seen PyPy? They already have the ability to turn a native
python function into pyrex and compile it on the fly.

Stephen.

 

[Fuzzyman]

Won't docstrings be removed in optimised bytecode ? that would stuff
things up.

Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

 

[olsongt]

I haven't checked PyPy out lately. I was under the impression the
Pyrex/C backend was still doing static compilation. Guess I'll have to
take a look.