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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
