Zope 3.0, and why I won't use it

[Alex Martelli]

Josiah Carlson <jcarlson at uci.edu> wrote:

> > but the point is whether, if and when 'optional static typing' _syntax_
> > gets it, it will have this semantics or that of inserting a lot of
> > typechecks... people can do typecheks or adaptation now, and neither
> > will go away -- but which, if either, should syntax facilitate?  That,
> > as I see it, is key.
> 
> I guess it all depends.
> "In the face of ambiguity, refuse the temptation to guess."
> "Explicit is better than implicit."
> 
> With the requisite zens quoted, I'd say that there should be an explicit
> way to do both, because guessing which one (but not both) is necessarily
> the wrong thing to do.

Since the actual need for type-checking is extremely rare, I contend it
should not _at all_ be a candidate for a syntax to facilitate it.  Since
the actual need for adaptation is much wider, I contend it's the one
obvious choice for the "nice syntax" if any.
 
> With that said, type-based dispatch, checking and adaptation are
> provided by decorators, which are explicit.  They are not a syntax
> per-se, but they will get the job done in the mean time (if placing type
> checking and adaptations in the function body is not sufficient).

Type checking is ugly, so it's quite fitting that it be implemented in
ugly ways -- by boilerplate or user-coded splats.  Adaptation is
beautiful, and beautiful is better than ugly (see, I can quote the zen
of Python too...), so it should have nice syntax (<var> 'as' <itf>).

Type-based dispatch is a little bit of a mess to implement with
decorators, IMHO.  Consider the hypothetical code...:

class A(object):
  @ dispatch(int)
  def foo(x): ...

  @ dispatch(float)
  def foo(x): ...

class B(object):
  @ dispatch(int)
  def foo(x): ...

  @ dispatch(str)
  def foo(x): ...

Sure, dispatch can be a H**2OF which returns a dispatching-foo and
stashes somewhere a (say) foo__int, foo__float or whatever, but the
problem is, _WHAT_ 'somewhere'.  dispatch isn't told what class body
it's being called from, so it can't easily stash stuff in the obvious
place, the class dictionary being built.  Attributes of the
dispatching-foo don't seem good, because of the problem of getting at
the right previously-returned dispatching-foo object on successive calls
of dispatch from within the same class body (but not from separate class
bodies).   Maybe some peek-into-the-stack black magic or custom
metaclass can help, but it does seem a little bit of a mess, unless I'm
overlooking something obvious.  If the implementation is hard to
explain, it's a bad idea...


Alex