[SciPy-dev] Is Python being Dylanized?

[Patrick Miller]

>
>
>
>This HPP interface looks very similar to what I thought awhile ago but
>from a different perspective. Namely, I was thinking of representing the
>signatures of C/Fortran functions using similar class definition setup in
>order to get rid of pyf-files (that may look scary for few non-Fortran
>persons). Then let f2py to scan Fortran sources and generate these class
>

One could also imagine that you could use this to specify base classes 
for C++
in Python (and get accelerated performance in Python!).   Our project 
did something
similar to what Pearu was talking about with Fortran source (ours was 
augmented
C++ header files) that we scanned.  It boils down to somebody, somewhere has
to bite the bullet on types.

Now Dylan and FL both used the idea that between some user specification 
of types
and a type inference engine one could get great benefits without giving 
up the
wonderful dynamicism of runtime typing.

The direction I was planning for the weave accelerate backplane was 
exactly as
Prabhu described...  A Python subset, reasonablely described, some types 
supported,
and extensible.  I think that I can detect "conforming" classes in the 
bytecode
compiler and then make 'em go really fast.  My true goal is to let most 
of Python
to be written in Python (accelerated into C++).  Guido wants to get the 
core of the
language smaller, and this may be a way to help.  The Py-Python could 
use the HPP
subset so that Jython could execute it directly (or put a Java interface 
to weave.accelerate)
and the normal Python is simply a weave accelerated version of 
Py-Python.  For a lot
of this to work, all one needs is a good interface between C structs and 
the Python
struct class.

Pat