Guido van Rossum wrote:
>
> Break up into VM, parser, import, mainloop, and other components?
>
> The porting efforts to seriously small machines (Win/CE,
> Pilot, etc.) all seem to need a Python VM that doesn't
> automatically pull in the parser and interactive main loop.
> There are other reasons as well to isolate various parts
> of the functionality (including all numeric data types except
> ints).
>
> This could include: restructuring of the parser so codeop.py
> can be simplified; making the interactive main loop a script.
There's some good work out there by Skip Montanaro to revamp the
VM into a combined register/stack machine. He calls it rattlesnake.
More infos can be found in the list archive (it's currently sleeping):
http://www.egroups.com/folders/rattlesnake I would like to see the VM/compiler pluggable so that experiments
like rattlesnake become easier to implement (extension modules vs.
patches to the core interpreter).
> Coercions
>
> Marc-Andre Lemburg has some good suggestions here:
> http://starship.python.net/~lemburg/coercion-0.6.zip
I will continue to work on these patches now that 1.5.2 is out.
There is a (more or less) detailed explanation of the patch set
at:
http://starship.skyport.net/~lemburg/CoercionProposal.html Instead of using of using the PY_NEWSTYLENUMBER approach I'll
turn to the new type flags that were introduced in 1.5.2. The
Py_NotImplemented singleton return value will stay, because
performance tests have shown that this method does not cause
any significant hit where as the exception raise and catch
method does introduce a significant slow-down.
> Import revamp
Greg's imputil.py (it's in the distutils package) should provide
a good start.
> Buffer object API extensions
I'll put the complete patch up on starship later this week...
here are the basic prototypes:
DL_IMPORT(int) PyObject_AsCharBuffer Py_PROTO((PyObject *obj,
const char **buffer,
int *buffer_len));
/* Takes an arbitrary object which must support the (character,
single segment) buffer interface and returns a pointer to a
read-only memory location useable as character based input for
subsequent processing.
buffer and buffer_len are only set in case no error
occurrs. Otherwise, -1 is returned and an exception set.
*/
DL_IMPORT(int) PyObject_AsReadBuffer Py_PROTO((PyObject *obj,
const void **buffer,
int *buffer_len));
/* Same as PyObject_AsCharBuffer() except that this API expects
(readable, single segment) buffer interface and returns a
pointer to a read-only memory location which can contain
arbitrary data.
buffer and buffer_len are only set in case no error
occurrs. Otherwise, -1 is returned and an exception set.
*/
DL_IMPORT(int) PyObject_AsWriteBuffer Py_PROTO((PyObject *obj,
void **buffer,
int *buffer_len));
/* Takes an arbitrary object which must support the (writeable,
single segment) buffer interface and returns a pointer to a
writeable memory location in buffer of size buffer_len.
buffer and buffer_len are only set in case no error
occurrs. Otherwise, -1 is returned and an exception set.
*/
> Distutil
>
> Should we start integrating some of the results of the
> distutil SIG? (What's the status? I haven't been paying
> attention.)
With all the different modules and packages available for Python
starting to slowly introduce dependencies, I think the main
objective should be introducing a well organized installation
info system, e.g. a registry where modules and packages can
query and save version and dependency information. Someone on
the main list mentioned that JPython has something like this...
> Misc
>
> Jeremy Hylton's urllib2.py
>
> Greg Stein's new httplib.py (or Jeremy's?)
>
> Andrew Kuchling's new PCRE release?
>
> The IPv6 patches?
These are on my wish list, so I'll simply add them here:
· APIs to faciliate creation of extensions classes (using Python
classes and C functions as methods)
The main open question here is where and how to store C data in
the instances. This could also provide a way to migrate to
all Python classes for some future version.
· Restructure the calling mechanism used in ceval.c to make
it clearer, more flexible and faster (of course, :-). Also,
inline calling of C functions/methods (this produces a noticable
speedup).
I have a patch for the restructuring and an old one (against 1.5)
for the C function call inlining.
· A "fastpath" hook made available through the sys module.
This should hook into the module/package loader and should be
used whenever set to find a module (reverting to the standard
lookup method in case it can't find it). I have an old patch
that does this. It uses a simple Python function to redirect the
lookup to a precalculated dictionary of installed modules/packages.
This results in faster startup of the Python interpreter (by saving
a few hundred stat() calls).
--
Marc-Andre Lemburg Y2000: 254 days left
---------------------------------------------------------------------
: Python Pages >>> http://starship.skyport.net/~lemburg/ :
---------------------------------------------------------