At 06:01 PM 10/28/03 -0800, Brett C. wrote:
Today I got the wheels turning on my masters thesis by getting an adviser. Now I just need a topic. =) The big goal is to do something involving Python for a thesis to be finished by fall of next year (about October) so as to have it done, hopefully published (getting into LL4 would be cool), and ready to be used for doctoral applications come January 2005.
So, anyone have any ideas? The best one that I can think of is optional type-checking. I am fairly open to ideas, though, in almost any area involving language design.
Throwing another Python-specific implementation issue into the ring... how about performance of Python function calls? Specifically, the current Python interpreter has a high overhead for argument passing and frame setup that dominates performance of simple functions. One strategy I've been thinking about for a little while is replacing the per-frame variable size stacks (e.g. argument and block stacks) with per-thread stacks. In principle, this would allow a few things to happen: * Fixed-size "miniframe" workspace objects allocated on the C stack (with lazy creation of heap-allocated "real" frame objects when needed for an exception or a sys._getframe() call) * Direct use of positional arguments on the stack as the "locals" of the next function called, without creating (and then unpacking) an argument tuple, in the case where there are no */** arguments provided by the caller. This would be a pretty sizeable change to Python's internals (especially the core interpreter's handling of "call" operations), but could possibly produce double-digit percentage speedups for function calls in tight loops. (I base this hypothesis on the speed difference between a function call and resuming a generator, and the general observation that the runtime of certain classes of Python programs is almost directly proportional to the number of function calls occurring.)