On Fri, Mar 22, 2019 at 8:44 AM Jonathan Fine <jfine2...@gmail.com> wrote: > > Antoine Pitrou wrote: > > Note that, if you're able to live with a third-party dependency, the > > `toolz` package has what you need (and lots of other things too): > > https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.merge > > I suggest that the supporters of dict + dict make (and put up on PyPi) > a pure-Python subclass of dict that has the desired properties. This > would > > 1. Clarify and document the syntax and semantics. > 2. Help with exploration and testing. > 3. Provide a 'back-port' mechanism to current Python. > 4. Give the proposal the benefit of practical experience. >
The trouble with that is that you can't always use a dict subclass (or a non-subclass MutableMapping implementation, etc, etc, etc). There are MANY situations in which Python will give you an actual real dict, and it defeats the purpose if you then have to construct an AddableDict out of it just so you can add something to it. Not every proposed change makes sense on PyPI, and it definitely won't get a fair representation in "practical experience". If someone's proposing adding a new module to the standard library, then by all means, propose PyPI. But changes to core types can't be imported from other modules. Python is not Ruby. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
