> All this talk of common backends for Python, Perl, and Ruby goaded me into > revisiting the Rattlesnake stuff I laid aside several years ago. Assuming I > ever get anywhere with it, it would be nice if code objects could > distinguish instruction sets based on a flag in the PyCodeObject struct. > The co_flags field seems to have some room and be more-or-less the right > place for this stuff. I'm wondering whether this is a good idea, there are some tools (at least inspect) in the std lib that depend on code objects to just contain the old good pvm bytecode, PyChecker also needs that (but we could have a flag to avoid generating strange code for its use...) As marginal note: for this reason they fail miserably under Jython, but that's clearly Jython fault. My point is that the above examples are perfectly meaningful and legitimate, and it is a good tradition and practice (Self, Smalltalk) even if you're seeking for speed, to present and accept code in a uniform manner, trough just one bytecode fortmat. Yes this way you waste memory, but ir is just the typical trade-off flexibility and speed vs. memory, if you have few memory you will simply disable your optimizer. A different point is to define and always use a new bytecode format. Or to banish code that rely on bytecode format for introspection ... I imagine that at some point someone will regret that. We should consider that AFAIK Psyco don't really produce in one shot a new stream of bytecode and on the other hand uses and keeps around a fairly complicated graph structure together with the chunks of bytecode (that's why it can probably be applied only to hot spots). I wonder if that fits in the old PyCodeObject model anyway. regards, Samuele Pedroni.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4