Re: improving the utility and adapter lookup APIs
Martijn Faassen <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> [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 <[email protected]> [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 <[email protected]> [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 _______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )