> > We already have an API for copying a dict (dict.copy). I still fail to see > > problem with using a method that doesn't start and end with underscores, > > other than that we "haven't done it". > > Before Python 3.0, iterators had a next() method, and that was explicitly and > consciously changed to __next__(). The arguments there seem relevant here too.
Thanks for bringing this up. PEP 3114 does a great job of explaining how and why Python uses dunders for *language-level* constructs. I would probably be opposed to language features or built-in functions doing magical things with the `copy` method of dicts; however, in this case, it's being used by the dict itself! As the PEP 3114 says: > In Python, double underscores before and after a name are used to distinguish > names that belong to the language itself... Not all things that are called > "protocols" are made of methods with double-underscore names... even though > the read method is part of the file protocol, it does not have double > underscores because there is no language construct that implicitly invokes > x.read(). The language itself doesn't call `copy`, but `dict` should feel free to. Especially if it makes life easier for subclasses (which PEP 584 actually encourages users to make in the "Rejected Semantics" section: https://www.python.org/dev/peps/pep-0584/#rejected-semantics)! _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FIPVZTUM4CJ5WJWAAYGS4E55Y7AP7J6E/ Code of Conduct: http://python.org/psf/codeofconduct/
