Note that the document doesn't yet cover the regular expression engine or the "PerlInterpreter". I can't think of a disclaimer that doesn't sound like it is tongue in cheek but I do feel bad about beating up on a design which, in its own way, has a certain kind of quality (just not one I happen to prefer). When you optimize the snot out of things they tend to start looking ugly. Perl runs faster than Python. That's probably not a coincidence. Jeremy Hylton wrote: > > What beautiful diagrams! It almost makes me wish Python was > complicated enough to require such pretty pictures. To be fair, our internals documentation needs some work. I'll bet there are a lot of people in comp.lang.python that would be interested in a project like that or another one, such as adding a full warning infrastructure to Python. I wonder how we could do a Software Carpentry like deal (no money) where we get people to submit designs and ideas and then "award" the job to someone. They could do it for reputational capital and an opportunity to join "the team" (of CVS committers, PythonDev denizens etc.). It's probably better to give people ideas rather than have them implement random things that we will need to turn down. Like stackless. <duck and cover!!!> -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski
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