RetroSearch Browse

Wed Apr 21 23:46:46 CEST 1999 · https://mail.python.org/pipermail/python-dev/1999-April/095112.html

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/  :
           ---------------------------------------------------------

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/1999-April/095112.html below:

[Python-Dev] Notice of intent: rich comparisons