I think the update method can (and personally, should) stay unchanged:

spam.update(dict(x, y))

seems succinct and elegant enough, with the proposed constructor syntax.

Sorry my ignorance, do (Mutable)Mapping ABC say anything about
constructors?

On Thu, Apr 12, 2018 at 12:45 PM, Serhiy Storchaka <storch...@gmail.com>
wrote:

> 09.04.18 00:18, Andrés Delfino пише:
>
>> I thought that maybe dict could accept several mappings as positional
>> arguments, like this:
>>
>>     class Dict4(dict):
>>          def __init__(self, *args, **kwargs):
>>              if len(args) > 1:
>>                  if not all([isinstance(arg, dict) for arg in args]):
>>                      raise TypeError('Dict4 expected instances of dict
>>     since multiple positional arguments were passed')
>>
>>                  temp = args[0].copy()
>>
>>                  for arg in args[1:]:
>>                      temp.update(arg)
>>
>>                  super().__init__(temp, **kwargs)
>>              else:
>>                  super().__init__(*args, **kwargs)
>>
>>
>> AFAIK, this wouldn't create compatibility problems, since you can't pass
>> two positional arguments now anyways.
>>
>> It would be useful to solve the "sum/union dicts" discussion, for
>> example: requests.get(url, params=dict(params, {'foo': bar})
>>
>> Whar are your thoughts?
>>
>
> It is easy to make the dict constructor merging several positional
> arguments. But this is not a tiny harmless change, it will start a cascade
> of other changes.
>
> After changing the dict constructor, we will need to update the
> dict.update() method too. Constructors and update() methods of dict
> subclasses (OrderedDict, defaultdict, Counter, and more specialized
> classes) should be updated too. UserDict, WeakKeyDictionary,
> WeakValueDictionary are next. After that we will have a pressure of
> updating constructors and update() methods of abstract classes Mapping and
> MutableMapping. This change will break a lot of third-party code that
> implement concrete implementations of these classes, because adding support
> of new arguments in the method of abstract class breaks an interface.
>
> We will be able to pass this path (we have already passed it), but we must
> realize how long it is.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to