Zope 3.0, and why I won't use it

Tue Nov 16 06:25:08 EST 2004

Ville Vainio <ville at spammers.com> 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

My prediction is that, once 'of course optional' type declaration gets
in, it will become the mandated approach in most new-to-Python shops, by
fallacious analogy with (say) VB and Perl's "optional" type declaration,
and by dint of managers' general liking for putting silly unjustified
restriction on professionals to hamper their productivity.  That is
going to be a huge cost.  What will it buy in exchange?

If typenames in a type declaration context can be statically resolved at
compile-time, then so can just about every other use of names, right?
After all, if the compiler can statically resolve what object 'foo' is
bound to in a clause 'x as bar.foo', it means it must somehow have
inferred that some 'class foo' statement will inevitably get executed
before then in module bar, or whatever other attribute assignment
produces that binding of name 'foo' within name 'bar'.

And of course the 'foo' type will generally be built up in another
module, so we're talking about a compiler that examines other modules in
order to be able to compile this one.  Whole-program compilation with
compile-time inferred name-object bindings would be such a huge and
total revolution wrt today's Python that very little would stay the
same.  OK, then, if that's the revolution that's in Python's future,
let's see it come _first_ -- there would be huge wins without requiring
any source code changes _IF_ name-to-object resolution could be
uniformly done at compile-time rather than at runtime, even across
modules.  Though I've never seen any example of whole-program
compilation and optimization done right, in practice (with compile time
NOT growing faster than O(N) and soon becoming untenable for large
programs), I do know that _in theory_ it's feasible -- I'd just be
astonished if it was shown that Python, never having been designed for
it, "just happens" to be the right language to have it finally occur.

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

If adaptation was a dialect-specific thing, it would hamper the ability
to move large frameworks and applications across dialects.

I don't see "falling back" to a lower-level language where you need one
as a disaster.  Doesn't have to be _AS_ low-level as C# or Java or C, of
course; I think pyrex does a great job of showing how a restricted
Python dialect/variant which, among other things, includes optional
declarations, can make your life much easier.  I don't see why there
couldn't be pyrex# or Jirex versions, or even languages inspired from
Python but farther from it than Pyrex is, such as Bobo.

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

I agree pychecker or the like might well have options to check on
everything under the sun -- no problem.  For reasons that escape me,
shop rules such as "all programs will pass lint with this and that
option" seem to never stick.  Shop rules such as "-Wall -pedantic on all
compilations and NEVER any commit of code with warnings" (a good idea,
actually) or "all VB programs must have option explicit" (maybe better
than nothing, given VB's typing mess, if you have to do VB) or "all perl
runs will always have -w" (probably a good idea), etc, etc, _are_
observed, in practice, to stick.  And there are good rules for Python,
too, of course, ones that promote productivity, from 'we do not ever use
"exec"' to similar edicts against 'from x import *'.  As long as control
freaks don't get an effective way to destroy Python's greatest strength,
namely signature-based polymorphism, I'm happy...

Alex