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

[Petr Viktorin]

On Fri, Feb 13, 2015 at 1:09 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Feb 13, 2015, at 3:08, Petr Viktorin <encukou at gmail.com> wrote:
>
>> 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 guess this means you need a MutableMappingMeta that inherits ABCMeta and does the extra check on update after calling the super checks on abstract methods? Should be pretty simple (and it's not a problem that update isn't abstract), if a bit ugly.

Yes. The ugliness makes me wonder if the warning is worth it.
I expect that popular libraries will change pretty fast after the new
update becomes preferred, and other code will just wait until this
hits them, not until they get a warning or until the old way is
officially dropped from the docs.
(FWIW, I don't see update() signature/mechanics documented on
https://docs.python.org/3/library/collections.abc.html. Is this
elsewhere?)

>> 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).
>
> Yeah, if you're special-casing it and coding it imperatively, it's pretty simple.
>
> But shouldn't it also require a var kw param? After all, the signature is supposed to be (self, *iterables_or_mappings, **kwpairs).

That part doesn't change, so I don't see a point in checking it.
If we were doing full signature checking, then yes – but I think that
best left to linter tools.