[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