Zope 3.0, and why I won't use it
Ian Bicking
ianb at colorstudy.com
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
More information about the Python-list
mailing list