Tim wrote: > Sorry, Chris! Just a case of "no time" here. Of *course* you > should continue, and Guido should pop in with an encouraging word > too -- or a "forget it". I think this design opens the doors to a > world of interesting ideas, but that's based on informed prejudice > rather than careful study of your code. Cheer up: if everyone > thought you were a lame ass, we all would have studied your code > intensely by now <wink>. No time here either... I did try to have a quick peek and my first impression is that it's *very* tricky code! You know what I think of that... Here's what I think we should do first (I've mentioned this before but nobody cheered me on :-). I'd like to see this as the basis for 1.6. We should structurally split the Python Virtual Machine and related code up into different parts -- both at the source code level and at the runtime level. The core PVM becomes a replaceable component, and so do a few other parts like the parser, the bytecode compiler, the import code, and the interactive read-eval-print loop. Most object implementations are shared between all -- or at least the interfaces are interchangeable. Clearly, a few object types are specific to one or another PVM (e.g. frames). The collection of builtins is also a separate component (though some builtins may again be specific to a PVM -- details, details!). The goal of course, is to create a market for 3rd party components here, e.g. Chris' flat PVM, or Skip's bytecode optimizer, or Greg's importer, and so on. Thoughts? --Guido van Rossum (home page: http://www.python.org/~guido/)
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