Martijn Faassen wrote:
> Thomas Lotze wrote:
>> You didn't explicitly mention the subject of backwards compatibility in
>> your original message, so let's make it explicit now: Is backwards
>> compatibility a goal in this discussion?
> True. It's indeed a goal, as I'd like to be able to use this sooner
> rather than later. If we break backwards compatibility then we'd have to
> go through all the IFoo() calls everywhere in all our code to see
> whether a default argument is in use.
>> If it isn't, I'm rather against an API that interprets an argument to
>> IFoo() as meaning different things depending on whether it's a tuple or
>> not. Python itself has an API that works like this (string formatting) and
>> is moving away from it. Requiring the default to be specified as a named
>> argument would also help readability IMO.
> Sure. But if we want to retain backwards compatibility we'll have to go
> another way.
Then let me suggest not changing the call signature of an interface at all
but only add one or a few new methods. Firstly, this will keep backwards
compatibility even with code that adapts a tuple, and secondly, it allows
us to implement a simple and consistent API anyway.
My favourite option under these circumstances would be something like
IFoo.query(*args, default=None, ...)
though possibly with a method name in a different color of bike shed,
where IFoo.query(x) is equivalent to IFoo(x) but a multiadapter lookup may
be written as IFoo.query(x, y).
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -