Hi, I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made it fairly straightforward to add direct threaded code and superinstructions for the various permutations of LOAD_CONST, LOAD_FAST, and most of the two-argument VM instructions. Sources: http://svirfneblin.org/stuff/VPython-0.1.tar.gz Pybench output: Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 104ms 126ms -17.3% 110ms 128ms -14.0% BuiltinMethodLookup: 98ms 136ms -27.9% 100ms 139ms -28.1% CompareFloats: 59ms 121ms -51.1% 60ms 123ms -50.7% CompareFloatsIntegers: 67ms 121ms -45.0% 73ms 136ms -46.7% CompareIntegers: 57ms 157ms -63.7% 58ms 161ms -64.1% CompareInternedStrings: 55ms 143ms -61.6% 57ms 161ms -64.5% CompareLongs: 56ms 122ms -54.0% 61ms 141ms -56.7% CompareStrings: 71ms 126ms -43.6% 72ms 131ms -44.7% CompareUnicode: 82ms 123ms -33.5% 83ms 131ms -36.7% ConcatStrings: 119ms 146ms -18.4% 129ms 158ms -18.4% ConcatUnicode: 90ms 109ms -17.2% 97ms 121ms -19.8% CreateInstances: 116ms 124ms -6.6% 118ms 127ms -7.0% CreateNewInstances: 109ms 119ms -7.9% 113ms 121ms -6.6% CreateStringsWithConcat: 97ms 162ms -40.3% 99ms 169ms -41.5% CreateUnicodeWithConcat: 90ms 116ms -22.8% 97ms 122ms -20.8% DictCreation: 87ms 122ms -28.6% 91ms 127ms -28.0% DictWithFloatKeys: 98ms 139ms -29.5% 105ms 148ms -29.3% DictWithIntegerKeys: 71ms 133ms -46.7% 74ms 136ms -46.0% DictWithStringKeys: 62ms 126ms -51.0% 64ms 128ms -50.3% ForLoops: 68ms 135ms -49.2% 69ms 136ms -49.2% IfThenElse: 63ms 130ms -51.6% 64ms 134ms -51.9% ListSlicing: 122ms 123ms -0.9% 126ms 125ms +0.8% NestedForLoops: 89ms 149ms -40.2% 93ms 152ms -38.9% NormalClassAttribute: 88ms 132ms -33.1% 95ms 134ms -29.5% NormalInstanceAttribute: 72ms 116ms -37.9% 77ms 118ms -34.8% PythonFunctionCalls: 90ms 122ms -26.1% 94ms 125ms -24.7% PythonMethodCalls: 117ms 144ms -18.8% 121ms 147ms -17.8% Recursion: 121ms 180ms -32.6% 124ms 184ms -32.4% SecondImport: 144ms 139ms +3.5% 150ms 143ms +4.8% SecondPackageImport: 151ms 145ms +3.9% 156ms 149ms +4.3% SecondSubmoduleImport: 178ms 168ms +5.8% 186ms 176ms +5.4% SimpleComplexArithmetic: 71ms 112ms -36.7% 76ms 123ms -38.3% SimpleDictManipulation: 77ms 139ms -44.3% 78ms 140ms -44.3% SimpleFloatArithmetic: 61ms 124ms -50.7% 63ms 126ms -50.2% SimpleIntFloatArithmetic: 61ms 121ms -49.4% 62ms 123ms -49.5% SimpleIntegerArithmetic: 61ms 121ms -49.5% 62ms 123ms -49.8% SimpleListManipulation: 58ms 116ms -50.0% 58ms 117ms -50.2% SimpleLongArithmetic: 89ms 121ms -26.3% 91ms 124ms -27.0% SmallLists: 79ms 116ms -31.8% 82ms 122ms -32.6% SmallTuples: 91ms 117ms -22.6% 93ms 122ms -23.6% SpecialClassAttribute: 84ms 132ms -36.4% 93ms 134ms -30.4% SpecialInstanceAttribute: 111ms 153ms -27.6% 114ms 155ms -26.2% StringMappings: 102ms 115ms -11.1% 104ms 117ms -10.9% StringPredicates: 100ms 136ms -26.7% 101ms 137ms -26.1% StringSlicing: 79ms 114ms -30.2% 84ms 119ms -29.9% TryExcept: 68ms 145ms -53.2% 69ms 148ms -53.6% TryRaiseExcept: 106ms 104ms +2.7% 109ms 106ms +2.8% TupleSlicing: 108ms 126ms -14.4% 113ms 130ms -13.0% UnicodeMappings: 150ms 150ms -0.4% 152ms 154ms -1.7% UnicodePredicates: 106ms 130ms -18.3% 108ms 133ms -18.3% UnicodeProperties: 94ms 111ms -15.2% 97ms 115ms -15.5% UnicodeSlicing: 101ms 130ms -22.5% 105ms 136ms -22.6% ------------------------------------------------------------------------------- Totals: 4750ms 6788ms -30.0% 4929ms 7035ms -29.9% ``other'' is vanilla Python 2.5.2. For details, see README, TODO, and PYBENCH which come with the sources. Feedback is, of course, very welcome and it'd be great to have some pybench results from different machines. Cheers, -jakob
2008/10/22 J. Sievers
I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made it fairly straightforward to add direct threaded code and superinstructions for the various permutations of LOAD_CONST, LOAD_FAST, and most of the two-argument VM instructions. [...] Totals: 4750ms 6788ms -30.0% 4929ms 7035ms -29.9%
``other'' is vanilla Python 2.5.2. For details, see README, TODO, and PYBENCH which come with the sources. Feedback is, of course, very welcome and it'd be great to have some pybench results from different machines.
Am I reading this right? You got a 30% speed improvement over CPython??? (I never read pybench results right, so if this is actually 30% slower than CPython, let me know and I'll shut up :-)) If so, what (if any) limitations are there to the implementation? Paul.
On 2008-10-22 14:16, J. Sievers wrote:
Hi,
I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made it fairly straightforward to add direct threaded code and superinstructions for the various permutations of LOAD_CONST, LOAD_FAST, and most of the two-argument VM instructions.
I suppose you get most of the speedup by using threaded code. Unfortunately, that is only supported by gcc. Do you get similar results for the switch based method that appears to be available in VMgen ? http://www.complang.tuwien.ac.at/anton/vmgen/html-docs/VM-engine.html Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 22 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
On Oct 22, 2008, at 10:16 AM, J. Sievers wrote:
Hi,
I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made it fairly straightforward to add direct threaded code and superinstructions for the various permutations of LOAD_CONST, LOAD_FAST, and most of the two-argument VM instructions.
Is it complete? I don't want to be rude or anything, but the idea I seem repeated a lot is that it is really easy to do a very fast VM that supports 95% of the language. How much of the standard python tests your VM pass? What is missing, and why? But besides that, it is always very cool to see another vm project starting, Good Luck -- Leonardo Santagada santagada at gmail.com
J> I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made J> it fairly straightforward to add direct threaded code and superinstructions for J> the various permutations of LOAD_CONST, LOAD_FAST, and most of the two-argument J> VM instructions. J> Sources: J> http://svirfneblin.org/stuff/VPython-0.1.tar.gz Very interesting. Trying to build with your changes on my Mac (OS X 10.5.5) I get an error caused by a definition in code.h: ... gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/opt/local/include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c In file included from /System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/ControlDefinitions.h:36, from /System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/HIToolbox.h:201, from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:29, from Include/pymactoolbox.h:10, from Python/mactoolboxglue.c:27: /System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/Lists.h:50: error: conflicting types for 'Cell' Include/code.h:15: error: previous declaration of 'Cell' was here make: *** [Python/mactoolboxglue.o] Error 1 Note that I'm not actually doing a Framework build. Any way you can easily rename your macros to avoid obvious name clashes like this? Thanks, -- Skip Montanaro - skip@pobox.com - http://www.webfast.com/~skip/
J> I implemented a variant of the CPython VM on top of Gforth's Vmgen; J> this made it fairly straightforward to add direct threaded code and J> superinstructions for the various permutations of LOAD_CONST, J> LOAD_FAST, and most of the two-argument VM instructions. Skip> Trying to build with your changes on my Mac (OS X 10.5.5) I get an Skip> error caused by a definition in code.h: I renamed Cell to _PyV_Cell and Inst to _PyV_Inst and got it to build. I get this pybench output on my Mac: ------------------------------------------------------------------------------- PYBENCH 2.0 ------------------------------------------------------------------------------- * using Python 2.5.3a0 * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.time ------------------------------------------------------------------------------- Benchmark: py25t.pybench ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID: Darwin-9.5.0-i386-32bit Processor: i386 Python: Executable: /Users/skip/src/python/release25-maint/python.exe Version: 2.5.3a0 Compiler: GCC 4.0.1 (Apple Inc. build 5465) Bits: 32bit Build: Oct 22 2008 13:12:03 (#release25-maint:66444M) Unicode: UCS2 ------------------------------------------------------------------------------- Comparing with: py25.pybench ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID: Darwin-9.5.0-i386-32bit Processor: i386 Python: Executable: /Users/skip/local/bin/python2.5 Version: 2.5.3a0 Compiler: GCC 4.0.1 (Apple Inc. build 5465) Bits: 32bit Build: Sep 13 2008 09:17:06 (#release25-maint:66444) Unicode: UCS2 Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 119ms 133ms -10.6% 121ms 141ms -14.1% BuiltinMethodLookup: 107ms 113ms -5.2% 108ms 116ms -6.5% CompareFloats: 67ms 92ms -27.7% 68ms 95ms -28.4% CompareFloatsIntegers: 75ms 92ms -17.9% 76ms 94ms -19.1% CompareIntegers: 53ms 89ms -39.8% 54ms 91ms -40.6% CompareInternedStrings: 78ms 102ms -24.3% 78ms 109ms -28.3% CompareLongs: 64ms 85ms -24.2% 65ms 85ms -23.5% CompareStrings: 60ms 77ms -22.0% 62ms 80ms -22.5% CompareUnicode: 91ms 106ms -13.8% 93ms 111ms -16.0% ConcatStrings: 140ms 141ms -0.3% 144ms 144ms +0.0% ConcatUnicode: 83ms 82ms +2.4% 91ms 85ms +6.6% CreateInstances: 138ms 145ms -5.1% 140ms 148ms -5.2% CreateNewInstances: 123ms 128ms -3.7% 125ms 129ms -3.5% CreateStringsWithConcat: 104ms 111ms -7.0% 105ms 258ms -59.1% CreateUnicodeWithConcat: 81ms 93ms -13.2% 83ms 158ms -47.7% DictCreation: 104ms 96ms +9.1% 106ms 102ms +4.0% DictWithFloatKeys: 88ms 104ms -15.9% 92ms 110ms -16.4% DictWithIntegerKeys: 79ms 111ms -29.2% 81ms 113ms -28.4% DictWithStringKeys: 77ms 90ms -13.8% 84ms 93ms -9.8% ForLoops: 66ms 78ms -15.2% 67ms 79ms -14.8% IfThenElse: 57ms 91ms -37.4% 57ms 91ms -37.4% ListSlicing: 119ms 120ms -0.4% 121ms 121ms -0.3% NestedForLoops: 86ms 98ms -12.0% 87ms 99ms -12.5% NormalClassAttribute: 113ms 111ms +2.1% 118ms 113ms +4.0% NormalInstanceAttribute: 89ms 102ms -12.5% 91ms 104ms -12.6% PythonFunctionCalls: 89ms 106ms -15.8% 91ms 108ms -15.0% PythonMethodCalls: 141ms 158ms -11.0% 149ms 161ms -6.9% Recursion: 122ms 137ms -11.2% 123ms 140ms -11.7% SecondImport: 90ms 91ms -0.3% 91ms 91ms -0.3% SecondPackageImport: 95ms 95ms +0.9% 97ms 96ms +0.9% SecondSubmoduleImport: 124ms 124ms +0.5% 126ms 125ms +0.7% SimpleComplexArithmetic: 96ms 103ms -7.2% 97ms 105ms -6.8% SimpleDictManipulation: 85ms 101ms -15.6% 90ms 103ms -12.3% SimpleFloatArithmetic: 90ms 98ms -8.1% 92ms 101ms -8.3% SimpleIntFloatArithmetic: 64ms 78ms -17.2% 65ms 79ms -18.0% SimpleIntegerArithmetic: 60ms 78ms -23.3% 60ms 79ms -24.3% SimpleListManipulation: 71ms 85ms -16.3% 73ms 87ms -16.3% SimpleLongArithmetic: 103ms 114ms -9.8% 106ms 116ms -8.1% SmallLists: 121ms 128ms -5.5% 122ms 131ms -6.9% SmallTuples: 107ms 114ms -6.2% 109ms 116ms -6.0% SpecialClassAttribute: 100ms 110ms -9.7% 102ms 111ms -7.8% SpecialInstanceAttribute: 175ms 182ms -3.7% 178ms 184ms -3.5% StringMappings: 172ms 177ms -2.8% 175ms 178ms -1.6% StringPredicates: 147ms 146ms +0.7% 149ms 147ms +1.0% StringSlicing: 112ms 112ms +0.2% 116ms 120ms -3.5% TryExcept: 55ms 77ms -28.3% 56ms 78ms -27.7% TryRaiseExcept: 105ms 104ms +1.2% 106ms 105ms +1.0% TupleSlicing: 110ms 107ms +3.2% 113ms 112ms +0.7% UnicodeMappings: 106ms 108ms -1.5% 108ms 109ms -1.6% UnicodePredicates: 106ms 113ms -5.4% 109ms 115ms -5.6% UnicodeProperties: 102ms 113ms -9.7% 104ms 116ms -10.2% UnicodeSlicing: 93ms 98ms -5.1% 95ms 102ms -7.1% ------------------------------------------------------------------------------- Totals: 5106ms 5645ms -9.5% 5221ms 5985ms -12.8% (this=py25t.pybench, other=py25.pybench) this == your threaded VM, other == the 2.5.3a0 VM. Skip
On Wed, Oct 22, 2008 at 5:16 AM, J. Sievers
I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made it fairly straightforward to add direct threaded code and superinstructions for the various permutations of LOAD_CONST, LOAD_FAST, and most of the two-argument VM instructions.
Hey Jakob, This is very interesting (at this point I'm just lurking), but has anyone pointed out yet that there already is something else called VPython, which has a long standing "right" to the name? http://www.vpython.org/ -- "3D Programming for Ordinary Mortals". I hope you can find a better name for your project, otherwise there will be no end of confusion... -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 23 Oct, 10:42 pm, greg.ewing@canterbury.ac.nz wrote:
Guido van Rossum wrote:
there already is something else called VPython
Perhaps it could be called Fython (Python with a Forth-like VM) or Thython (threaded-code Python).
I feel like I've missed something important, but, why not just call it "Python"? ;-) It's a substantial patch, but from what I understand it's a huge performance improvement and completely compatible, both at the C API and Python source levels. Is there any reason this should be a separate project rather than just be rolled in to the core? Obviously once issues like the 'Cell' macro are dealt with.
glyph@divmod.com wrote:
Is there any reason this should be a separate project rather than just be rolled in to the core?
Always keep in mind that one of the important characteristics of CPython is that its implementation is very straightforward and easy to follow. Replacing the ceval loop with machine generated code would be a step away from that. -- Greg
Greg Ewing wrote:
glyph@divmod.com wrote:
Is there any reason this should be a separate project rather than just be rolled in to the core?
Always keep in mind that one of the important characteristics of CPython is that its implementation is very straightforward and easy to follow. Replacing the ceval loop with machine generated code would be a step away from that.
Funny to hear that from the author of a well-known code generator. ;-) I haven't looked at the specific Vmgen code in question, but I tend to find a short DSL description of repetitive functionality much more straightforward than the same thing implemented in custom, hand-optimised code in a general purpose language like C. Just think of the switch split that MAL described in one of his comments. Having two switch statements and a couple of separate special cases for a single eval loop might look pretty arbitrary and not straight forward at all to a reader who doesn't have enough background regarding the performance characteristics of Python's VM statements. Stefan
Stefan Behnel wrote:
Funny to hear that from the author of a well-known code generator. ;-)
I've never claimed that anything about the implementation of Pyrex is easy to follow. :-)
Having two switch statements and a couple of separate special cases for a single eval loop might look pretty arbitrary and not straight forward at all to a reader who doesn't have enough background regarding the performance characteristics of Python's VM statements.
Maybe not, but at least you can follow what it's doing just by knowing C. Introducing vmgen would introduce another layer for the reader to learn about. I'm not saying this is a bad enough problem to stop it being done, just that it's something to consider that isn't necessarily on the positive side. -- Greg
On Sat, Oct 25, 2008 at 04:33:23PM +1300, Greg Ewing wrote:
Maybe not, but at least you can follow what it's doing just by knowing C. Introducing vmgen would introduce another layer for the reader to learn about.
A stray thought: does using a generator for the VM make life easier for the Stackless Python developers in any way? Does it make it possible for stock CPython to become stackless? --amk
At 07:50 AM 10/25/2008 -0400, A.M. Kuchling wrote:
On Sat, Oct 25, 2008 at 04:33:23PM +1300, Greg Ewing wrote:
Maybe not, but at least you can follow what it's doing just by knowing C. Introducing vmgen would introduce another layer for the reader to learn about.
A stray thought: does using a generator for the VM make life easier for the Stackless Python developers in any way? Does it make it possible for stock CPython to become stackless?
Dunno about that, but I do know that having stack effect info for the bytecode could help with things like bytecode verification (without having to define a bunch of magic constants that duplicate information from the innards of ceval.c).
A.M. Kuchling wrote:
A stray thought: does using a generator for the VM make life easier for the Stackless Python developers in any way? Does it make it possible for stock CPython to become stackless?
I doubt it. A major barrier to stacklessness is that a lot of extension modules would need to be rewritten in a completely different way. Just changing the VM isn't going to make a difference to that. -- Greg
Greg Ewing wrote:
A.M. Kuchling wrote:
A stray thought: does using a generator for the VM make life easier for the Stackless Python developers in any way? Does it make it possible for stock CPython to become stackless?
I doubt it. A major barrier to stacklessness is that a lot of extension modules would need to be rewritten in a completely different way. Just changing the VM isn't going to make a difference to that.
That's obviously a problem, but it only answers the second question, not the first one. Stefan
Stefan Behnel wrote:
That's obviously a problem, but it only answers the second question, not the first one. [does using a generator for the VM make life easier for the Stackless Python developers in any way?]
The Stackless Python developers themselves would have to answer that one, but my guess is that it would help about the same amount as it would help non-Stackless Python, i.e. there's not much about stacklessness per se that makes it particularly beneficial to have a generated VM. -- Greg
glyph@divmod.com wrote:
It's a substantial patch, but from what I understand it's a huge performance improvement and completely compatible, both at the C API and Python source levels.
I have not seen any Windows test yet. The direct threading is gcc-specific, so there might be degradation with MSVC.
On Fri, Oct 24, 2008 at 7:18 AM, Terry Reedy
I have not seen any Windows test yet. The direct threading is gcc-specific, so there might be degradation with MSVC.
erlang uses gcc to compile a single source file on windows and uses MS VC++ to compile all others. They also need the gcc labels-as-values extension and the file in question seems to be their bytecode interpreter (beam_emu.c). - Ralf
Terry> I have not seen any Windows test yet. The direct threading is Terry> gcc-specific, so there might be degradation with MSVC. Not if a compiler #ifdef selects between two independent choices: #ifdef __GCC__ /* or whatever the right incantation is */ #include "ceval-threaded.c" #else #include "ceval-switched.c" #endif and so on... BTW, as to the implementation of individual VM instructions I don't believe the Vmgen stuff affects that. It's just the way the instructions are assembled. Skip
skip@pobox.com writes:
BTW, as to the implementation of individual VM instructions I don't believe the Vmgen stuff affects that. It's just the way the instructions are assembled.
Vmgen handles the pushing and popping as well. E.g. ROT_THREE becomes: rot_three ( a1 a2 a3 -- a3 a1 a2 ) BINARY_POWER is: binary_power ( a1 a2 -- a dec:a1 dec:a2 next:a ) a = PyNumber_Power(a1, a2, Py_None); (Here I have abused Vmgen a bit by declaring, in addition to the actual value stack, some dummy stacks with different stack prefixes and using the ``push'' instructions generated for those to do reference counting.) I should mention that some of the more involved instructions have no declared effect (i.e. ( -- ) ) with stack manipulation still being done by hand. Cheers, -jakob
glyph@divmod.com writes:
On 23 Oct, 10:42 pm, greg.ewing@canterbury.ac.nz wrote:
Guido van Rossum wrote:
there already is something else called VPython
Perhaps it could be called Fython (Python with a Forth-like VM) or Thython (threaded-code Python).
I feel like I've missed something important, but, why not just call it "Python"? ;-)
It's a substantial patch, but from what I understand it's a huge performance improvement and completely compatible, both at the C API and Python source levels.
Is there any reason this should be a separate project rather than just be rolled in to the core? Obviously once issues like the 'Cell' macro are dealt with.
While it seems to work reliably, I don't think the current implementation is really ``core-ready'' as it stands. I consider it more of a prototype to demonstrate the potential impact on these kinds of low-level dispatch optimizations (and for me personally an opportunity to familiarize myself with the CPython VM). IMO the main issues are: - Right now, CPython's bytecode is translated to direct threaded code lazily (when a code object is first evaluated). This would have to be merged into compile.c in some way plus some assorted minor changes. - The various things mentioned in TODO. - Finally, the core developers probably won't want to depend on Gforth (required to run Vmgen), so one might have to re-implement Vmgen (not a huge deal; I know that there are a number of unpublished versions of Vmgen floating around and IIRC one of them is even written in Python; even if not Vmgen isn't really that difficult to implement). Once that's done, however, I'd consider readability to have _increased_ if anything (compare the switch statement in vanilla Python 2.5.2's ceval.c to the patchset's ceval.vmg). Note that none of the above are really show stoppers from a user's point of view. It's about conforming to CPython's standards of neatness. Cheers, -jakob
At 10:47 AM 10/24/2008 +0200, J. Sievers wrote:
- Right now, CPython's bytecode is translated to direct threaded code lazily (when a code object is first evaluated). This would have to be merged into compile.c in some way plus some assorted minor changes.
Don't you mean codeobject.c? I don't see how the compiler relates, as Python programs can generate or transform bytecode. (For example, Zope's Python sandboxing works that way.)
"Phillip J. Eby"
At 10:47 AM 10/24/2008 +0200, J. Sievers wrote:
- Right now, CPython's bytecode is translated to direct threaded code lazily (when a code object is first evaluated). This would have to be merged into compile.c in some way plus some assorted minor changes.
Don't you mean codeobject.c? I don't see how the compiler relates, as Python programs can generate or transform bytecode. (For example, Zope's Python sandboxing works that way.)
Also good :). (I was thinking about the superinstruction selection code which should perhaps go into optimize_code() since it's a kind of peephole optimization. The bytecodes->addresses part might even stay in ceval.c I guess). -jakob
Guido> This is very interesting (at this point I'm just lurking), but Guido> has anyone pointed out yet that there already is something else Guido> called VPython, which has a long standing "right" to the name? I believe Jakob has already been notified about this. How about TPython? A quick google-check suggests that while there is at least one instance of that name in use as related to Python, it seems to be fairly obscure and is perhaps only used internally at CERN. Skip
skip@pobox.com writes:
Guido> This is very interesting (at this point I'm just lurking), but Guido> has anyone pointed out yet that there already is something else Guido> called VPython, which has a long standing "right" to the name?
I believe Jakob has already been notified about this. How about TPython? A quick google-check suggests that while there is at least one instance of that name in use as related to Python, it seems to be fairly obscure and is perhaps only used internally at CERN.
TPython it is! Cheers, -jakob
participants (14)
-
A.M. Kuchling -
cadr4u＠gmail.com -
glyph＠divmod.com -
Greg Ewing -
Guido van Rossum -
Jakob Sievers
-
Leonardo Santagada -
M.-A. Lemburg -
Paul Moore -
Phillip J. Eby -
Ralf Schmitt -
skip＠pobox.com -
Stefan Behnel -
Terry Reedy