[Zope3-dev] interface conventions: default=_RAISE_ERROR

[Guido van Rossum]

[me]
> > While we're at it, I don't particularly like the pattern. 
> 
> The pattern is based on Python's getattr. :)

Yeah, and I think that was a mistake or at least an exception to the
rule.

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

Me too.

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

This is application specific.  Python itself cannot make any
assumptions; a dict containing exception classes as values is totally
legal.  But in Zope you presumably have more of an idea of what the
expected values will be.

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

Yes, as long as it can not be confused with a legitimate value.

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

Me too.

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

The one that raises an exception should be called __getitem__ and
normally invoked with obj[key] notation.

--Guido van Rossum (home page: http://www.python.org/~guido/)