Zope 3.0, and why I won't use it

Tue Nov 16 04:54:28 EST 2004

>>>>> "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.

    Alex> syntax sugar;-) ends up being a way to ease *type-checking*,
    Alex> then, well, I'll evaluate that as being on a par with easing
    Alex> alcohol abuse.  What

I don't think people have been too keen to get static type checking
into the language anyway. It might be an option in pychecker, but that
should be enough. Dynamic type checking, well, that's an obvious net
loss over adaptation.

-- 
Ville Vainio   http://tinyurl.com/2prnb