[Zope3-dev] interface conventions: default=_RAISE_ERROR

Jim Fulton jim@zope.com
Tue, 14 May 2002 14:32:12 -0400


Guido van Rossum wrote:
> 
> > > in the __init__ of the Interfaces package.  An interface that wants to use
> > > the default marker would simply
> > > from Interface import Interface, _RAISE_ERROR
> > > and implementations could import from their interfaces or from the original
> > > declaration in the Interface package.
> >
> > I really wouldn't bother. It saves very little typing, adds to the
> > complexity of finding out what things really mean, adds another
> > dependency, and saves a few hundred bytes at most per runtime.
> 
> While we're at it, I don't particularly like the pattern. 

The pattern is based on Python's getattr. :)

The pattern was extended in Zope 2 by my confusion over the inconsistency
between getattr and (dictionary) get.  I assumed that they would be consistent
and all of Zope 2's get methods raise an error is a value is not found and
no default is given.

I'd be OK with treating getattr as an aberation. :)

There is the problem that it is sometimes difficult for the caller
of get to detect the not-found case. It's usually as hard for a client to
pick a marker to pass to get to detect the non-found case when it needs
to.

> If it is
> used I think there should be a *public* value so that a caller can be
> explicit about "I want the exception" rather than having to use a
> short argument list.

I like this. Note, however, that it would be good enough to not raise
an exception but to get this value when a key is not found.

> Where this is used, would it be acceptable if the exception itself
> (KeyError?) was specified as the default value?  Or is an exception a
> valid regular default?

This feels too brittle to me.

Maybe we should switch to having two versions of each get method.
This would be easier to implement and to document.  Anybody got
a suggestion for a naming convention?

Jim

P.S. I'm really happy that this kind of dialog is taking place and theat we're
     taking the time, even at the expense of slowing Zope 3's development, 
     to make things clearer.

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org