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  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to