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.
Understood.
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). -- Thomas