[SciPy-dev] Is Python being Dylanized?

Pat Miller pnmiller at pacbell.net
Tue Feb 12 01:32:16 CST 2002

Prahbu writes:

> I ask a naive question, what is the feasibility of actually doing
> something like Dylan?  OK forget truly generic functions.  I'm just
> talking of optional typing to speed things up.  I guess psyco, weave,
> pyCOD etc. all put together and taken to their logical end will give
> us Python + optional typing + heaven? :D Of course I could also be
> *completely* mistaken.  Looking at Eric's subsequent post it looks
> like even optional typing can be magically handled.  This is looking
> amazing.

It is amazing.

I had a friend who was really big into Dylan, I liked a lot of the ideas
there and it in fact helped frame some of the direction that pyCOD
and now weave.accelerate (a better name than weave.cod!) have

Type inference is a powerful tool and when it works, it can lead
to some great improvements using the extra typing knowledge.

I for one, would love to see Python allow an optional type:


def foo(string s):
   print s + "hi"

which is much nicer than the

def foo(s):
   assert type(s) == StringType
   print s + "hi"

we have to use now.   If I get real ambitious, I can actually
check for the asserts of argument type and we
can skip all the wacky guess and check that Eric
has proposed and the wackier signatures that I propose.

It will take more work to get the accelerator to work on
class methods.  This is in part due to the issues about
Python's super dynamic attribute system that makes it
hard to infer types of attributes.  Perhaps the assert
system isn't too bad for it, though I think that writing

class foo:
    def solver(self,x):
        assert type(self.nx) == IntType
        assert type(self.name) == StringType
        assert type(x) == FloatType

would get kind of tedious.

One idea is to simply assume that the types you are given
are fixed for all time, another is to assume that the
values for a given instance are fixed for all time
(that is nx and name will either never change type
or perhaps never change value).  Then I can compile
even more efficient code (but require more information)


More information about the Scipy-dev mailing list