Some ABC issues: * The 2.6-backported Mapping ABC has the 3.0 dict API, that is, it uses keys() that returns a view etc. * The 2.6 UserDict is not registered as a mapping. * collections.deque isn't registered as a MutableSequence. If there are no objections, I will correct these issues in the 2.6 and 3.0 branches. Georg
On Mon, May 26, 2008 at 1:27 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Some ABC issues:
* The 2.6-backported Mapping ABC has the 3.0 dict API, that is, it uses keys() that returns a view etc.
How would you correct this in 2.6? Add the inter* variants and make keys, items, and values return a list?
* The 2.6 UserDict is not registered as a mapping.
* collections.deque isn't registered as a MutableSequence.
If there are no objections, I will correct these issues in the 2.6 and 3.0 branches.
None on principle.
Georg
-- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."
* The 2.6-backported Mapping ABC has the 3.0 dict API, that is, it uses keys() that returns a view etc.
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.
* 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. If the Mapping ABC does get changed, only IterableUserDict should get registered. A regular UserDict does not comply.
* 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 there are no objections, I will correct these issues in the 2.6 and 3.0 branches.
I think none of these changes should be made. Raymond
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
From: "Armin Ronacher" <armin.ronacher@active-4.com>
If the ABCs exists only for forward compatibility they will be mostly useless for every day usage.
The Mapping ABC is still useful as a mixin in code that will run on both 2.6 and 3.0. It is the easiest way to start coding with views.
Deque's do not support count(), insert() or __iadd__(). They should not be registered.
If it doesn't implement the MutableSequence protocol it still is a Sized container. However currently it's not registered as a container.
Seems useless to me. I don't think the intent of the ABC pep was to mandate that every class that defines __len__ must be registered as Sized.
Another issue is that builtin types don't accept ABCs currently. For example set() | SomeSet() gives a TypeError, SomeSet() | set() however works.
Pandora's Box -- sure you want to open it? Raymond
On Mon, May 26, 2008 at 4:11 PM, Raymond Hettinger <python@rcn.com> wrote:
Deque's do not support count(), insert() or __iadd__(). They should not be registered.
If it doesn't implement the MutableSequence protocol it still is a Sized container. However currently it's not registered as a container.
Seems useless to me. I don't think the intent of the ABC pep was to mandate that every class that defines __len__ must be registered as Sized.
There's no need to register as Sized -- the Sized ABC recognizes classes that define __len__ automatically. The Container class does the same looking for __contains__. Since the deque class doesn't implement __contains__, it is not considered a Container -- correctly IMO.
Another issue is that builtin types don't accept ABCs currently. For example set() | SomeSet() gives a TypeError, SomeSet() | set() however works.
Pandora's Box -- sure you want to open it?
In 3.0 I'd like to; this was my original intent. In 2.6 I think it's not worth the complexity, though I won't complain. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
There's no need to register as Sized -- the Sized ABC recognizes classes that define __len__ automatically. The Container class does the same looking for __contains__. Since the deque class doesn't implement __contains__, it is not considered a Container -- correctly IMO. True. deque doesn't implement __contains__. However "in" still works because of the __iter__ fallback. So from the API's perspective it's still compatible, even though it doesn't implement it. The same probably affects old style iterators (__getitem__ with index). One could argue that
Hi, Guido van Rossum <guido <at> python.org> writes: they are still iterable or containers, but that's harder to check so probably not worth the effort.
Another issue is that builtin types don't accept ABCs currently. For example set() | SomeSet() gives a TypeError, SomeSet() | set() however works.
Pandora's Box -- sure you want to open it?
In 3.0 I'd like to; this was my original intent. In 2.6 I think it's not worth the complexity, though I won't complain. I would love to help on that as I'm very interested in that feature.
Regards, Armin
On Tue, May 27, 2008 at 12:16 PM, Armin Ronacher <armin.ronacher@active-4.com> wrote:
Hi,
Guido van Rossum <guido <at> python.org> writes:
There's no need to register as Sized -- the Sized ABC recognizes classes that define __len__ automatically. The Container class does the same looking for __contains__. Since the deque class doesn't implement __contains__, it is not considered a Container -- correctly IMO. True. deque doesn't implement __contains__. However "in" still works because of the __iter__ fallback.
Sure, but that fallback is slow, and intentionally does not trigger the 'Container' ABC.
So from the API's perspective it's still compatible, even though it doesn't implement it. The same probably affects old style iterators (__getitem__ with index). One could argue that they are still iterable or containers, but that's harder to check so probably not worth the effort.
The ABCs do not intend to capture partial behavioral compatibility that way -- the intent is to capture interface (in the duck typing sense). Whether __iter__ is a good enough substitute for __contains__ depends on a lot of things -- surely for a huge list it isn't, and for an iterator it isn't either (since it modifies the iterator's state).
Another issue is that builtin types don't accept ABCs currently. For example set() | SomeSet() gives a TypeError, SomeSet() | set() however works.
Pandora's Box -- sure you want to open it?
In 3.0 I'd like to; this was my original intent. In 2.6 I think it's not worth the complexity, though I won't complain. I would love to help on that as I'm very interested in that feature.
Please do submit patches! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, May 26, 2008 at 11:59 AM, Raymond Hettinger <python@rcn.com> wrote:
* The 2.6-backported Mapping ABC has the 3.0 dict API, that is, it uses keys() that returns a view etc.
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.
It's wrong if the ABC doesn't describe the behavior of actual implementations; that is its primary purpose, the mixin class is a nice side benefit. We could make the incompatible mixin classes available separately though, if you think they're useful.
* 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. If the Mapping ABC does get changed, only IterableUserDict should get registered. A regular UserDict does not comply.
Fair enough. I recomment to fix the Mapping ABC and register IterableUserDict.
* 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).
Hopefully they aren't registered in 3.0 either. :-)
If there are no objections, I will correct these issues in the 2.6 and 3.0 branches.
I think none of these changes should be made.
I'm in the middle. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
* The 2.6-backported Mapping ABC has the 3.0 dict API, that is, it uses keys() that returns a view etc.
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.
It's wrong if the ABC doesn't describe the behavior of actual implementations; that is its primary purpose, the mixin class is a nice side benefit.
ISTM, the one purpose of backporting is to make 2.6 closer to 3.0. Altering the API will just make them further apart. Raymond
On Tue, May 27, 2008 at 10:44 AM, Raymond Hettinger <python@rcn.com> wrote:
* The 2.6-backported Mapping ABC has the 3.0 dict API, that is, it uses keys() that returns a view etc.
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.
It's wrong if the ABC doesn't describe the behavior of actual implementations; that is its primary purpose, the mixin class is a nice side benefit.
ISTM, the one purpose of backporting is to make 2.6 closer to 3.0. Altering the API will just make them further apart.
Well, the ABCs have two sides -- they describe the API and they provide a mix-in. I feel strongly that the primary function of ABCs is to describe the API (in fact many ABCs do only that, e.g. look at Sized and Container). I want isinstance({}, collections.Mapping) to be true. If you want to use the 3.0 mixins in 2.6, perhaps an alternate set of APIs could be imported from the future? E.g. from future_collections import Mapping. IIRC a similar mechanism was proposed for some built-in functions, even though I see no traces of an implementation yet. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
If you want to use the 3.0 mixins in 2.6, perhaps an alternate set of APIs could be imported from the future? E.g. from future_collections import Mapping. IIRC a similar mechanism was proposed for some built-in functions, even though I see no traces of an implementation yet.
Any know what happened to the effort to put the 3.0 dict in future_builtins? That would nicely sync-up the ABC with a concrete implementation and bring 2.6 a little closer to 3.0. Raymond
Guido van Rossum schrieb:
On Mon, May 26, 2008 at 11:59 AM, Raymond Hettinger <python@rcn.com> wrote:
* The 2.6-backported Mapping ABC has the 3.0 dict API, that is, it uses keys() that returns a view etc.
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.
It's wrong if the ABC doesn't describe the behavior of actual implementations; that is its primary purpose, the mixin class is a nice side benefit.
We could make the incompatible mixin classes available separately though, if you think they're useful.
* 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. If the Mapping ABC does get changed, only IterableUserDict should get registered. A regular UserDict does not comply.
Fair enough. I recomment to fix the Mapping ABC and register IterableUserDict.
As a followup: - The Mapping fix is in http://bugs.python.org/issue3057. - Registering IterableUserDict is now in SVN. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
participants (5)
-
Armin Ronacher -
Benjamin Peterson -
Georg Brandl -
Guido van Rossum -
Raymond Hettinger