Wolfgang Schnerring wrote:
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including utilities, adapters and multiadapters:
IFoo() IFoo(x) IFoo(x, y)
I quite like the simplicity of this spelling, so I want to be sure *why* it must be ruled out. (...or does it, really?)
I'm thinking that this...
* Martijn Faassen <faassen@startifact.com> [2009-11-25 22:21]:
The last one won't work if we want to maintain backwards compatibility. The second argument is the default.
is a valid argument, while this...
* Tres Seaver <tseaver@palladion.com> [2009-11-25 13:34]:
You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too.
is not, as evidenced by...
* Fabio Tranchitella <kobold@kobold.it> [2009-11-25 20:51]:
IFoo(x, y, default=None, name='something')
or am I missing something here?
I think the problem would exist if we did something like this: def IFoo(default, name, *args): pass but if we did something like this we should be okay, I think: def IFoo(*args, **kw): name = kw.get('name', missing) default = kw.get('default', missing) adapted = args
So I'm thinking, there is no technical reason that prevents Thomas' spelling, and I'm wondering, do we really have to preserve backwards compatibility for this case?
I'm not very fond of the second argument interpreted as default. If it weren't there I'd be quite interested in the API you're proposing. But someone needs to think of a feasible upgrade scenario. We could instrument all calls to IFoo and see whether a default argument is in use, but what then? I'd be hard to distinguish a default argument from one we're meant to adapt. I'd also be non-trivial to scan code. We could perhaps release a special version of zope.interface/zope.component that *forbids* the second argument to see what bugs pop up, but that'd still not guarantuee we catch all cases. Regards, Martijn