[me] > > Here's what I think we should do first (I've mentioned this before but > > nobody cheered me on :-). [Jack] > Go, Guido, GO!!!! > > What I'd like in the split you propose is to see which of the items would be > implementable in Python, and try to do the split in such a way that such a > Python implementation isn't ruled out. Indeed. The importing code and the read-eval-print loop are obvious candidates (in fact IDLE shows how the latter can be done today). I'm not sure if it makes sense to have a parser/compiler or the VM written in Python, because of the expected slowdown (plus, the VM would present a chicken-egg problem :-) although for certain purposes one might want to do this. An optimizing pass would certainly be a good candidate. > Am I correct in guessing that after factoring out the components you mention > the only things that aren't in a "replaceable component" are the builtin > objects, and a little runtime glue (malloc and such)? I guess (although how much exactly will only become clear when it's done). I guess that things like thread-safety and GC policy are also pervasive. --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