> On Oct 29, 2017, at 8:19 AM, Serhiy Storchaka <storchaka at gmail.com> wrote: > > The copy() methods of list, dict, bytearray, set, frozenset, WeakValueDictionary, WeakKeyDictionary return an instance of the base type containing the content of the original collection. > > The copy() methods of deque, defaultdict, OrderedDict, Counter, ChainMap, UserDict, UserList, WeakSet, ElementTree.Element return an instance of the same type as the original collection. > > The copy() method of mappingproxy returns a copy of the underlying mapping (using its copy() method). > > os.environ.copy() returns a dict. > > Shouldn't it be more consistent? Not really. It is up to the class designer to make a decision about what the most useful behavior would be for subclassers. Note for a regular Python class, copy.copy() by default creates an instance of the subclass. On the other hand, instances like int() are harder to subclass because all the int operations such as __add__ produce exact int() instances (this is likely because so few assumptions can be made about the subclass and because it isn't clear what the semantics would be otherwise). Also, the time to argue and change APIs is BEFORE they are released, not a decade or two after they've lived successfully in the wild. Raymond
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4