Hi Yahya,
I like the full.png diagram, however, I see some issues with it.
Most seriously, the methods it lists don't match the documentation.
E.g. if you check MappingView:
https://docs.python.org/3/library/collections.abc.html#collections.abc.MappingView
you see it has only a __len__ mixin m
On 12/30/2017 11:11 AM, Yahya Abou 'Imran via Python-ideas wrote:
We can find very usefull class diagramm to understand the hierarchy of
the builtin Collection abstract class and interface in java.
Some examples:
http://www.falkhausen.de/Java-8/java.util/Collection-Hierarchy-simple.html
http://
+1 on adding these diagrams to the docs. It's great to visualize where the
special methods are implemented.
On Sat, Dec 30, 2017 at 4:17 PM, Terry Reedy wrote:
> On 12/30/2017 11:11 AM, Yahya Abou 'Imran via Python-ideas wrote:
>
>> We can find very usefull class diagramm to understand the hier
=== This proposition is purely aesthetic ===
At this time, the __repr__ of the mapping views is showing the whole mapping:
>>> from collections.abc import ValuesView, KeysView, ItemsView
>>> d = {3: 'three', 4: 'four'}
>>> KeysView(d)
KeysView({3: 'three', 4: 'four'})
>>> ValuesView(d)
ValuesView
> Hi Yahya,
> I like the full.png diagram, however, I see some issues with it.
>
> Most seriously, the methods it lists don't match the documentation.
>
> E.g. if you check MappingView:
>
> https://docs.python.org/3/library/collections.abc.html#collections.abc.MappingView
>
> you see it has only a
> A. Width restrictions suggest making the async branches a separate diagram.
I was thinking about it... Maybe Hashable and Callable could also be removed,
since they are standalone ABCs. And they're not directly linked with the
concept of Collection anyway.
> B. Be consistent on placement of
Here is another version showing all that inherit from Container, Sized and
Iterable.
I got rid of ABCMeta, since it's not the prupose of the documentation of that
page.
I left the parenthesis and the end of the methods names though...
[collections_abc.png]
You're right that there's some inconsistency here. But I don't think it's
worth fixing given that the fix would introduce another inconsistency
(which you pointed out) and would also risk breaking backwards
compatibility. I think this ship has sailed.
On Sat, Dec 30, 2017 at 5:18 PM, Yahya Abou 'I
On Fri, Dec 29, 2017 at 11:25 PM, Steven D'Aprano wrote:
> On Sat, Dec 30, 2017 at 02:56:46AM +1100, Chris Angelico wrote:
>> On Sat, Dec 30, 2017 at 2:38 AM, Steven D'Aprano wrote:
>> > The lack of support for the `in` operator is a major difference, but
>> > there's also `len` (equivalent to "c
On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee <
[email protected]> wrote:
>
> Paddy might want something like this:
> - For existing APIs which take int or IntFlag flags, allow them to
> also take a set (or perhaps any collection) of flags.
> - In new APIs, take sets of Enum flags, and
I should probably clarify that for this to work, Foo must derive from
enum.Flags. See https://docs.python.org/3/library/enum.html#flag.
(Or enum.IntFlag, https://docs.python.org/3/library/enum.html#intflag.)
Note that when using Flag, you can name the "zero" value (Color.BLACK in
the 3rd example).
In python 2.7, ABCs's caches and registries are sets. But in python 3.6 they
are WeakSet.
In consequence, the output of _dump_registry() is almost useless:
>>> from collections import abc
>>> abc.Iterator._dump_registry()
Class: collections.abc.Iterator
Inv.counter: 40
_abc_cache: <_weakrefset.We
12 matches
Mail list logo
