bytecodehacks-discuss Mailing List for bytecodehacks
Status: Alpha
Brought to you by:
mwh
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 |