You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On the other hand, that section does reference the ABC directly, so I can see the point of your question. So I guess I'm not sure what the answer is...I don't think copy is an essential part of the ABC, but I'm not sure.
MutableSequence defines an interface. Adding a new method will break all classes that implemented this protocol but not the new method.
And what should .copy() return? list subclasses return an exact list, bytearray subclasses return an exact bytearray, but deque subclasses try to create an instance of the same type. Not all mutable sequences can be copyable. The constructor is not the part of the protocol.
The same problems are in MutableSet and MutableMapping. This is why they don't provide copy() methods (but concrete classes set and dict do).
Should we add .copy() to the ABC or remove the promise that all mutable sequences implement .copy()?
The second option would be best. Let's just clarify that copy() isn't part of the MutableSequence API.
The first option isn't really a choice be it would break existing uses that don't implement copy and because the ABC have a reliable way to create a new instance using the given abstract methods (it has no way of even knowing whether the data is stored locally, in a database, or updated through a REST API, it may not even be possible to reliably create an independent instance).