Zope 3.0, and why I won't use it

Tue Nov 16 12:55:34 EST 2004

Ville Vainio wrote:
>>>>>>"Alex" == Alex Martelli <aleaxit at yahoo.com> writes:
> 
> 
>     Alex> where builtin 'adapt' does protocol adaptation.  On the
>     Alex> other hand, if the semantics of those 'as' clauses were
>     Alex> something like:
> 
>     Alex> def x(y, z):
>     Alex> if type(y) is not foo: raise TypeError, 'y must be foo'
>     Alex> if type(z) is not bar: raise TypeError, 'z must be bar'
>     Alex> <body of x>
> 
>     Alex> then that's the day I move to Ruby, or any other language
>     Alex> that remained halfway sensible (if any).
> 
> Even if it allowed portions of the code to be statically compiled to
> reach "native" performance? Or if it allowed resolving ambiguous
> situations in type inference? Type declarations would of course be
> optional, and they could be a big win esp. for non-cpython
> implementations of the language. Beats reverting to C#/whatever for
> situations where you want good JITtability. In CPython "adaptation"
> might be the way to go, of course, but that would still enable the
> same code to run on different variants of Python.

I would think of it differently.  I don't see a need for static typing 
to deal with the outside world.  There's always a bridge when 
communicating with the outside world, and if that bridge is smart enough 
it should be okay.  You can annotate things (I think type annotation for 
PyObjC was one of the motivations behind the decorator syntax), that's 
different from static typing, and is just a guide for coercion.

And obviously foreign functions cannot take arbitrary arguments. 
Nothing in Python can, there's always limits; though foreign functions 
may not accept immitation objects (e.g., list subclasses), and that's 
just part of the API.  That's why people tend to create wrappers around 
non-Python libraries.

I can see some performance advantages to static typing.  I don't think 
it would be worth it for any external interface, but for internal 
interfaces it might be worth it, where there's less of a concern about 
flexibility.  In that case, decorators might be all that's necessary, e.g.:

@constrain_types(a=float, b=str, c=int:
def foo(a, b):
    c = 1
    ...

Imagining an implementation of constrain_types that knew how to pick 
apart a function's code, apply the type information and optimizations, 
and put it back together.  It really doesn't need pretty syntax, because 
it's not a pretty operation (though the decorator syntax is actually 
reasonably attractive).  It would be nice if this applied both to 
arguments and local variables.

Now, I could imagine this turning into a Cargo Cult programming 
practice, where people mindlessly apply this type information despite 
there being no reason or performance gain, thus adding weight to their 
code and reducing flexibility.  But then, I'd rather work under the 
expectation that the programmer will do the right thing.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org