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
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).
On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee <
leewangzhong+pyt...@gmail.com> 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
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
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
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]
> 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
> 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
=== 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
+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
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://
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
12 matches
Mail list logo