Hi, Raymond Hettinger <python <at> rcn.com> writes:
Curious to hear what Guido thinks about this one. A nice use of the Mapping ABC is to be able to get 3.0 behaviors. I thought that was the whole point of all these backports. If the ABC gets altered, then it just makes the 2-to-3 conversion harder. If the ABCs exists only for forward compatibility they will be mostly useless for every day usage. Mappings in Python 2.x look different and the ABCs should reflect that. The 2to3 script does replace d.iterkeys with d.keys as similar stuff, so that wouldn't make the conversion any harder.
* The 2.6 UserDict is not registered as a mapping.
Since the API's are not currently the same, it makes sense that UserDict is not registered. Right, but I think the first one should be considered a bug.
If the Mapping ABC does get changed, only IterableUserDict should get registered. A regular UserDict does not comply. If it's not a mapping it should at least be a container. But a typecheck for isinstance(UserDict, Container) gives an AttributeError currently because the __subclasshook__ doesn't handle old style classes. This is another issue the ABC backport currently has. IMO isinstance under Python 2.x shouldn't perform __*hook__ checks for old style classes.
* collections.deque isn't registered as a MutableSequence.
Deque's do not support count(), insert() or __iadd__(). They should not be registered. General purpose indexing into a deque is typically a mis-use of the data structure. It was provided only to make it easier to substitute for lists in apps the operate only one ends (i.e.d[0], d[1], d[-1], d[-2] but not d[i] to somewhere in the middle). If it doesn't implement the MutableSequence protocol it still is a Sized container. However currently it's not registered as a container.
Another issue is that builtin types don't accept ABCs currently. For example set() | SomeSet() gives a TypeError, SomeSet() | set() however works. Regards, Armin