> In the conservative version of this vision, Perl and Python have > different runtimes dynamically linked to an instance of the same > opcode interpreter. Memory allocation/GC and scheduling/threading are > handled inside the opcode interpreter but the OS and environment > binding is (mostly) in the libraries. Hm, the Python bytecode interpreter doesn't do the memory allocation/GC, and only does the scheduling/threading indirectly (by releasing and immediately reacquiring the global interpreter lock). > Things Python would bring to this party: our serious-cool GC, our > C extension/embedding system (*much* nicer than XS). Things Perl would > bring: blazingly fast regexps, taint, flexitypes, references. I'm not sure I want references, and I don't know what flexitypes are. --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