On Feb 13, 2015, at 1:26, Petr Viktorin <encukou@gmail.com> wrote:
On Fri, Feb 13, 2015 at 4:52 AM, Andrew Barnert <abarnert@yahoo.com.dmarc.invalid> wrote:
On Feb 12, 2015, at 18:45, Steven D'Aprano <steve@pearwood.info> wrote:
On Thu, Feb 12, 2015 at 07:25:24PM -0700, Eric Snow wrote:
Or just make "dict(a, b, c)" work.
I've come to the same conclusion.
- Surely this change is minor enough that it doesn't need a PEP? It just needs a patch and approval from a senior developer with commit privileges.
I'm not sure about this. If you want to change MutableMapping.update too, you'll be potentially breaking all kinds of existing classes that claim to be a MutableMapping and override update with a method with a now-incorrect signature.
Is there a mechanism to evolve ABCs? Maybe there should be, something like:
- For a few Python versions, say that the new behavior is preferred but can't be relied upon. Update the MutableMapping default implementation (this is backwards compatible). - Possibly, later, have MutableMapping warn when a class with the old update signature is registered. (With the signature improvements in py3, this should be possible for 99% cases.) Or just rely on linters to implement a check. - Finally switch over completely, so callers can rely on the new MutableMapping.update
Well, currently, ABCs don't test signatures at all, just the presence of a non-abstract method. So you'd have to change that first, which seems like a pretty big change. And the hard part is the design, not the coding (as, I suspect, with the abc module in the first place). What do you do to mark an @abstractmethod as "check signature against the new version, and, if not, warn if it's compatible with the previous version, raise otherwise"? For that matter, what is the exact rule for "compatible with the new version" given that the new version is essentially just (self, *args, **kwargs)? How do you specify that rule declaratively (or so we add a __check__(subclass_sig) method to abstract methods and make you do it imperatively)? And so on. It might be worth seeing what other languages/frameworks do to evolve signatures on their abc/interface/protocol types. I'm not sure there's a good answer to find (unless you want monstrosities like IXMLThingy4::ParseEx3 as in COM), but I wouldn't want to assume that without looking around first.