[Zope3-dev] interface conventions: default=_RAISE_ERROR

Martijn Faassen faassen@vet.uu.nl
Sun, 12 May 2002 23:17:14 +0200


Gary Poster wrote:
> On Saturday 11 May 2002 04:04 pm, Martijn Faassen wrote:
> > Gary Poster wrote:
> This convention, or something similar, goes back at least to Zope 2 
> development days, I think--long before my Zope interests.

Could you give me an example of such in Zope2? I do not recall having
run into this before.
 
> In Zope 3, as you 
> said, a _RAISE_ERROR-type marker is used in Containers; I didn't notice 
> Traversal, but I believe it.

It was just a grep for _RAISE_KEYERROR, to see how prevalent it was. :)
 
[snip]
 
> If you'd like to ponder and argue the issue a little more, I suggest looking 
> at the interfaces in the ComponentArchitecture package as a conversation 
> starter, remembering that every time you see "default=None" it's a lie: we're 
> using a marker convention.
[snip]

Okay, I took a look at that. It's just I myself generally dislike methods
that behave differently dependent on the amount of arguments passed; in that
case I am strongly inclined to pick two separate methods instead. I 
can't argue that very strongly, however.

I am not well able to judge what the needs of ComponentArchitecture users
are however, here -- I was speaking about what I see in Container and
the like, where I think a strong case can be made to do away with
_RAISE_KEYERROR and go to a more Pythonic pattern (after all Containers
are very much like mappings of some sort).

> I think raising an error is "correct," returning a default is a useful 
> shortcut, and combining the two on the basis of a marker is a reasonable 
> compromise that's easy to code.  Duplicating the pertinent methods to 
> parallel __getitem__ and get seems unnecessary and I don't care for it.  But 
> again, I'm happy to accomodate a community or ZC decision.

For methods that do not parallel existing Python (folk) interfaces so
much my objections are less strong. A question though; how do you
implement Guido's suggestion of explicitly passing an exception to
signal you want it raised? Perhaps a premature optimization question,
but aren't we going from a cheap 'is None' check to a 'is one of my
base classes Exception' check, or isn't it like that? Are we checking
whether a *particular* exception is passed instead, so
'is ComponentLookupError'?

Regards,

Martijn