bytecodehacks-discuss Mailing List for bytecodehacks
Status: Alpha
Brought to you by:
mwh
Menu
▾
▴
bytecodehacks-discuss
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
|---|
|
From: Michael H. <mw...@ca...> - 2000-10-12 21:57:09
|
On Tue, 10 Oct 2000, Toby Dickenson wrote: > On Fri, 6 Oct 2000 13:11:54 +0100 (BST), Michael Hudson > <mw...@ca...> wrote: > > >Very nice. I've checked in your changes, plus a few things I'd been > >working on intermittently over the last few months. It passes the tests, > >but I'd appreciate it if you could give it a spin! > > That passes all my tests. Wahay. Cool. (Just to let you know I'm still here). BTW, you're now a developer of bytecodehacks. All I ask is that you ensure all the tests pass before making any changes. If you feel inspired I particularly recommend: 1) adding more test cases 2) adding more support for python 2.0 opcodes Cheers, M. |
|
From: Toby D. <mb...@di...> - 2000-10-10 13:40:42
|
On Fri, 6 Oct 2000 13:11:54 +0100 (BST), Michael Hudson <mw...@ca...> wrote: >Very nice. I've checked in your changes, plus a few things I'd been >working on intermittently over the last few months. It passes the tests, >but I'd appreciate it if you could give it a spin! That passes all my tests. Wahay. Toby Dickenson tdi...@ge... |
|
From: Michael H. <mw...@ca...> - 2000-10-06 12:11:59
|
On Fri, 6 Oct 2000, Toby Dickenson wrote: > > > (If anyones interested, Ive been experimenting with > > allowing file-like > > > objects to choose their own character encoding when a unicode string > > > is printed) > > > > Cool. How does bytecodehacks help, out of curiosity? > > The regular print converts stuff using str() - which will raise an exception > in a unicode object that contains non-ascii characters. > > Python 2.0 adds two new instructions in support of the new sytax that lets > you > specify the file to which stuff gets printed (print >> file, stuff). Im > converting > those instructions into method calls into the file object. [snip] Very nice. I've checked in your changes, plus a few things I'd been working on intermittently over the last few months. It passes the tests, but I'd appreciate it if you could give it a spin! Cheers, M. PS: Do you have a sourceforge ID? (Careful - if you tell me you're likely to get added as a developer...). |
|
From: Toby D. <tdi...@ge...> - 2000-10-06 08:28:36
|
> > (If anyones interested, Ive been experimenting with
> allowing file-like
> > objects to choose their own character encoding when a unicode string
> > is printed)
>
> Cool. How does bytecodehacks help, out of curiosity?
The regular print converts stuff using str() - which will raise an exception
in a unicode object that contains non-ascii characters.
Python 2.0 adds two new instructions in support of the new sytax that lets
you
specify the file to which stuff gets printed (print >> file, stuff). Im
converting
those instructions into method calls into the file object.
def hook_print_to(function):
func = Function(function)
cs = func.func_code.co_code
i = 0
while i < len(cs):
if cs[i].__class__ == PRINT_ITEM_TO:
cs[i:i+1] =
[LOAD_ATTR('print_item_to'),ROT_TWO(),CALL_FUNCTION(1),POP_TOP()]
i=i+4
elif cs[i].__class__ == PRINT_NEWLINE_TO:
cs[i:i+1] =
[LOAD_ATTR('print_newline_to'),CALL_FUNCTION(0),POP_TOP()]
i=i+1
else:
i=i+1
return func.make_function()
|
|
From: Michael H. <mw...@ca...> - 2000-10-05 17:54:39
|
On Thu, 5 Oct 2000, Toby Dickenson wrote: > On Thu, 5 Oct 2000 13:28:46 +0100 (BST), Michael Hudson > <mw...@ca...> wrote: > > >> Is anyone looking at adding support for the new instructions in python > >> 2.0? > > > >I've been meaning to do it for a while. If you beat me to it, I certainly > >won't hold it against you! > > Heres a patch for the two instructions that I am using (PRINT_ITEM_TO > and PRINT_NEWLINE_TO), and which raises a NotImplemented error for all > of those other new ones that I dont yet care about. Cool. I'll check it in, as they say, momentarily. Tests fail at the moment, basically due to the "from x import y as z" patch. I'm on the case (but going to the theatre in an hour, and haven't eaten yet...). > (If anyones interested, Ive been experimenting with allowing file-like > objects to choose their own character encoding when a unicode string > is printed) Cool. How does bytecodehacks help, out of curiosity? > Ive also been niggled by the way bytecodehacks imports its sibling > modules.... it assumes that the bytecodehacks package is installed as > a root package (Its more convenient for me to install it as a > sub-package below my package) Would you accept a patch to change all > of the > from bytecodehacks.ops import * > into > from ops import * > ? Now I've actually read http://www.python.org/doc/essays/packages.html properly, yes. Cheers! M. |
|
From: Toby D. <mb...@di...> - 2000-10-05 16:11:49
|
On Thu, 5 Oct 2000 13:28:46 +0100 (BST), Michael Hudson
<mw...@ca...> wrote:
>> Is anyone looking at adding support for the new instructions in python
>> 2.0?
>
>I've been meaning to do it for a while. If you beat me to it, I certainly
>won't hold it against you!
Heres a patch for the two instructions that I am using (PRINT_ITEM_TO
and PRINT_NEWLINE_TO), and which raises a NotImplemented error for all
of those other new ones that I dont yet care about.
(If anyones interested, Ive been experimenting with allowing file-like
objects to choose their own character encoding when a unicode string
is printed)
Ive also been niggled by the way bytecodehacks imports its sibling
modules.... it assumes that the bytecodehacks package is installed as
a root package (Its more convenient for me to install it as a
sub-package below my package) Would you accept a patch to change all
of the
from bytecodehacks.ops import *
into
from ops import *
?
Index: stack_bump_methods
===================================================================
RCS file:
/cvsroot/bytecodehacks/bytecodehacks/bytecodehacks/code_gen/stack_bump_methods,v
retrieving revision 1.5
diff -c -6 -r1.5 stack_bump_methods
*** stack_bump_methods 2000/04/01 11:02:52 1.5
--- stack_bump_methods 2000/10/05 15:30:00
***************
*** 22,33 ****
--- 22,34 ----
STOP_CODE:
pass
POP_TOP:
pop()
ROT_TWO:
ROT_THREE:
+ ROT_FOUR:
pass
DUP_TOP:
push()
UNARY_POSITIVE:
UNARY_NEGATIVE:
UNARY_NOT:
***************
*** 76,87 ****
--- 77,92 ----
DELETE_SUBSCR:
pop(2)
PRINT_EXPR:
PRINT_ITEM:
pop()
PRINT_NEWLINE:
+ PRINT_ITEM_TO:
+ pop(2)
+ PRINT_NEWLINE_TO:
+ pop()
BREAK_LOOP:
pass
LOAD_LOCALS:
push()
RETURN_VALUE:
pop()
***************
*** 153,159 ****
--- 158,183 ----
num_regular_args = self.arg&0x00FF
pop(2*num_keyword_args + num_regular_args)
MAKE_FUNCTION:
pop(1 + self.arg)
BUILD_SLICE:
pop(self.arg - 1)
+ INPLACE_ADD:
+ INPLACE_SUBTRACT:
+ INPLACE_MULTIPLY:
+ INPLACE_DIVIDE:
+ INPLACE_MODULO:
+ INPLACE_LSHIFT:
+ INPLACE_RSHIFT:
+ INPLACE_AND:
+ INPLACE_XOR:
+ INPLACE_OR:
+ INPLACE_POWER:
+ IMPORT_STAR:
+ UNPACK_SEQUENCE:
+ DUP_TOPX:
+ CALL_FUNCTION_VAR:
+ CALL_FUNCTION_KW:
+ CALL_FUNCTION_VAR_KW:
+ EXTENDED_ARG:
+ raise NotImplementedError('execute for this python 2.0
instuction is not yet implemented')
Index: execute_methods
===================================================================
RCS file:
/cvsroot/bytecodehacks/bytecodehacks/bytecodehacks/code_gen/execute_methods,v
retrieving revision 1.2
diff -c -6 -r1.2 execute_methods
*** execute_methods 2000/03/15 20:55:42 1.2
--- execute_methods 2000/10/05 15:30:00
***************
*** 26,37 ****
--- 26,43 ----
stack[-2:]=[stack[-1],stack[-2]]
ROT_THREE:
stack[-3:]=[
stack[-1],
stack[-3],
stack[-2]]
+ ROT_FOUR:
+ stack[-4:]=[
+ stack[-1],
+ stack[-4],
+ stack[-3],
+ stack[-2]]
DUP_TOP:
stack.append(stack[-1])
UNARY_POSITIVE:
UNARY_NEGATIVE:
UNARY_NOT:
UNARY_CONVERT:
***************
*** 77,88 ****
--- 83,98 ----
del stack[-2:]
PRINT_EXPR:
PRINT_ITEM:
stack.pop()
PRINT_NEWLINE:
pass
+ PRINT_ITEM_TO:
+ del stack[-2:]
+ PRINT_NEWLINE_TO:
+ del stack[-1:]
BREAK_LOOP:
raise "No jumps here!"
LOAD_LOCALS:
stack.append(self)
RETURN_VALUE:
stack[:] = []
***************
*** 152,157 ****
--- 162,186 ----
num_regular_args=self.arg&0xFF
stack[-2*num_keyword_args-num_regular_args-1:]=[self]
MAKE_FUNCTION:
stack[-self.arg-1:]=[self]
BUILD_SLICE:
stack[-self.arg:]=[self]
+ INPLACE_ADD:
+ INPLACE_SUBTRACT:
+ INPLACE_MULTIPLY:
+ INPLACE_DIVIDE:
+ INPLACE_MODULO:
+ INPLACE_LSHIFT:
+ INPLACE_RSHIFT:
+ INPLACE_AND:
+ INPLACE_XOR:
+ INPLACE_OR:
+ INPLACE_POWER:
+ IMPORT_STAR:
+ UNPACK_SEQUENCE:
+ DUP_TOPX:
+ CALL_FUNCTION_VAR:
+ CALL_FUNCTION_KW:
+ CALL_FUNCTION_VAR_KW:
+ EXTENDED_ARG:
+ raise NotImplementedError('stack_manipulate for this python 2.0
instuction is not yet implemented')
Toby Dickenson
tdi...@ge...
|
|
From: Michael H. <mw...@ca...> - 2000-10-05 12:28:52
|
On Thu, 5 Oct 2000, Toby Dickenson wrote: > All is quiet on the bytecodehacks list..... Yep. > Is anyone looking at adding support for the new instructions in python > 2.0? I've been meaning to do it for a while. If you beat me to it, I certainly won't hold it against you! If for some reason you care about it, that might well provoke me into actually doing it, too. Cheers, M. |
|
From: Toby D. <mb...@di...> - 2000-10-05 11:01:40
|
All is quiet on the bytecodehacks list..... Is anyone looking at adding support for the new instructions in python 2.0? Toby Dickenson tdi...@ge... |
|
From: Michael H. <mw...@ca...> - 2000-04-13 12:59:07
|
Greetings brave souls, I've been playing with Neil Schemenauer's gc patch for Python. It enables me to remove some of the scary hackery that prevents cycles forming. This has made the code sufficiently simpler that I've also cleaned up some of the interfaces. Anyway, if you want a look, it's on a branch on CVS; you can get it by doing: cvs -z3 -d:pserver:ano...@cv...:/cvsroot/bytecodehacks co -r GC_FUN bytecodehacks I'll probably move the cleanups back on to the trunk at some point. Cheers, M. |
|
From: Michael H. <mw...@ca...> - 2000-04-01 14:39:37
|
The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.
Well, it's April the first, so what better time than this to announce
the release of a new version of bytecodehacks?
Not all that much has changed in the code; a bug fix here and there.
* The mechanism for calculating the co_stacklevel attribute of code
objects actually gets it right (at least in cases I have tested).
* xapply.xapply has gotten *much* cleverer, and much hairier. It now
supports such delights as keyword arguments, trimming the default
argument list correctly, assignments to arguments and handling
**-style arguments (but not *-style, yet). It's approaching the
point of being actually useful (scary!).
* there's the beginnings of a test suite.
Administrivia-wise, there's much more shaking up.
* bytecodehacks now live on sourceforge; start here to find the
tarballs and updated docs.
http://bytecodehacks.sourceforge.net
There's a mailing list, which I don't envision being very high
volume:
http://lists.sourceforge.net/mailman/listinfo/bytecodehacks-discuss
but I invite anyone who's interested to join for banter about the
internal structures of Python and how to (ab)use them.
* bytecodehacks now has a license, based on the deliberately liberal
Python license; please read the file LICENSE for details.
* Documentation is now being distributed separately; a tarball of the
HTML can be found on the project homepage.
As ever, all comments are welcome!
Cheers,
Michael
PS: I haven't sent this to python-announce, as that list appears to be
entirely dead. News to the contrary will be gratefully accepted.
--
well, take it from an old hand: the only reason it would be easier
to program in C is that you can't easily express complex problems
in C, so you don't. -- Erik Naggum, comp.lang.lisp
|
