[Python-ideas] Adding "+" and "+=" operators to dict

[Petr Viktorin]

On Fri, Feb 13, 2015 at 11:02 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Feb 13, 2015, at 1:26, Petr Viktorin <encukou at gmail.com> wrote:
>
>> On Fri, Feb 13, 2015 at 4:52 AM, Andrew Barnert
>> <abarnert at yahoo.com.dmarc.invalid> wrote:
>>> On Feb 12, 2015, at 18:45, Steven D'Aprano <steve at 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.

Well, by "mechanism" I meant guidelines on how it should work, not a
general implementation.
I'd just special-case MutableMapping now, and if it later turns out to
be useful elsewhere, figure a way to do it declaratively. I'm always
wary of designing a general mechanism from one example.

I propose the exact rule for "compatible with the new version" to be
"the signature contains a VAR_POSITIONAL argument", with the check
being skipped if the signature is unavailable. It's simple, only has
false negatives if the signature is wrong, and false positives if
varargs do something else (for this case there should be a warning in
docs/release notes).