Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Franklin? Lee]

On Sun, Dec 31, 2017 at 12:09 PM, MRAB  wrote:
> On 2017-12-31 08:13, Paddy3118 wrote:
>>
>> Hmm, yea I had not thought of how it would look - I had thought formost of
>> not needing to necessarily learn about bitsets.when learning about passing a
>> large number of optional flags to a function.
>>
>> Although the default could be None, interpreted as an empty set of zero
>> values.; a set of one or more enums does use more characters compared to
>> or-ing flags...
>>
> None is often used to represent a default, which might not be an empty set.

I see no reason not to allow an iterable collection of flags. That
will at least allow [] and ().
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Improve ABCs _dump_registry() readability

[Ivan Levkivskyi]

On 31 December 2017 at 20:05, Antoine Pitrou  wrote:

> On Sun, 31 Dec 2017 19:31:06 +0100
> Ivan Levkivskyi 
> wrote:
>
> > On 31 December 2017 at 19:24, Yahya Abou 'Imran via Python-ideas <
> > python-ideas@python.org> wrote:
> >
> > >
> > > >I guess a PR to fix the registry output would make sense (first file a
> > > bug on bugs.python.org for it).
> > >
> > > Ok, I will!
> > >
> > >
> > Please don't hurry with this. I am going to rewrite ABCMeta in C soon.
> > In fact most of the work is done but I am waiting for implementation of
> PEP
> > 560 to settle (need few more days for this).
> >
> > In the C version the caches/registry will be simpler and will not use
> > WeakSet (instead they will be thin C wrappers around normal sets).
>
> Hmm... Just because you are rewriting the thing in C doesn't mean that
> Yahya shouldn't submit a patch for the Python version (which I assume
> will be staying around anyway).
>

Yes, good point!

--
Ivan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Improve ABCs _dump_registry() readability

[Antoine Pitrou]

On Sun, 31 Dec 2017 19:31:06 +0100
Ivan Levkivskyi 
wrote:

> On 31 December 2017 at 19:24, Yahya Abou 'Imran via Python-ideas <
> python-ideas@python.org> wrote:
> 
> >  
> > >I guess a PR to fix the registry output would make sense (first file a  
> > bug on bugs.python.org for it).
> >
> > Ok, I will!
> >
> >  
> Please don't hurry with this. I am going to rewrite ABCMeta in C soon.
> In fact most of the work is done but I am waiting for implementation of PEP
> 560 to settle (need few more days for this).
> 
> In the C version the caches/registry will be simpler and will not use
> WeakSet (instead they will be thin C wrappers around normal sets).

Hmm... Just because you are rewriting the thing in C doesn't mean that
Yahya shouldn't submit a patch for the Python version (which I assume
will be staying around anyway).

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Improve ABCs _dump_registry() readability

[Ivan Levkivskyi]

On 31 December 2017 at 19:24, Yahya Abou 'Imran via Python-ideas <
python-ideas@python.org> wrote:

>
> >I guess a PR to fix the registry output would make sense (first file a
> bug on bugs.python.org for it).
>
> Ok, I will!
>
>
Please don't hurry with this. I am going to rewrite ABCMeta in C soon.
In fact most of the work is done but I am waiting for implementation of PEP
560 to settle (need few more days for this).

In the C version the caches/registry will be simpler and will not use
WeakSet (instead they will be thin C wrappers around normal sets).

--
Ivan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Improve ABCs _dump_registry() readability

[Guido van Rossum]

Yeah, I guess few developers have needed to use _dump_registry(), and also
it's easy enough to just access e.g. Iterator._abc_registry yourself.

The reason Iterator._abc_registry is empty is that no class directly
registered with it -- they are all registered with e.g. Sequence. The cache
includes classes registered with subclasses, but the registry itself does
not.

I guess a PR to fix the registry output would make sense (first file a bug
on bugs.python.org for it).

On Sat, Dec 30, 2017 at 11:19 PM, Yahya Abou 'Imran via Python-ideas <
python-ideas@python.org> wrote:

> 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.WeakSet object at 0x7f4b58fe2668>
> _abc_negative_cache: <_weakrefset.WeakSet object at 0x7f4b53283780>
> _abc_negative_cache_version: 40
> _abc_registry: <_weakrefset.WeakSet object at 0x7f4b58fe2630>
>
> We could convert them into a regular set before printing:
>
> if isinstance(value, WeakSet):
> value = set(value)
>
> The result:
>
> >>> abc.Iterator._dump_registry()
> Class: collections.abc.Iterator
> Inv.counter: 40
> _abc_cache: {, ,
> , ,  'dict_keyiterator'>, , ,  'set_iterator'>, , ,
> , ,  'bytes_iterator'>}
> _abc_negative_cache: set()
> _abc_negative_cache_version: 40
> _abc_registry: set()
>
>
> NB: It seems pretty weird to me that registry is empty... All the
> iterators in the cache should've been in the registry instead, should'nt
> they?
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[MRAB]

On 2017-12-31 08:13, Paddy3118 wrote:
Hmm, yea I had not thought of how it would look - I had thought formost 
of not needing to necessarily learn about bitsets.when learning about 
passing a large number of optional flags to a function.


Although the default could be None, interpreted as an empty set of zero 
values.; a set of one or more enums does use more characters compared to 
or-ing flags...



None is often used to represent a default, which might not be an empty set.


On Sunday, 31 December 2017 05:34:23 UTC, Guido van Rossum wrote:

On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee
 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 don't make them IntFlag.
- Documentation should show preference toward using sets of Enum
flags. Tutorials should pass sets.


I'm not keen on this recommendation. An argument that takes a
Set[Foo] would mean that in order to specify:
- no flags: you'd have to pass set() -- you can't use {} since
that's an empty dict, not an empty set
- one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
- two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than
Foo.BAR | Foo.BAZ

I think for each of these the proposal would be strictly worse than
the current convention.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add an UML class diagram to the collections.abc module documentation

[Yahya Abou 'Imran via Python-ideas]

>Terry Reedy writes:
>
>>B. Be consistent on placement of inherited versus added methods.  Always
>>>list inherited first?  Different fonts, as suggested, might be
>>>good.
>>
> I would prefer listing added methods first.

I don't understand why...

In the table of the documentation page, the abstract methods are listed fisrt.
In the source code, the abstract methods are implemented fisrt.
In UML, the convention is to place the abstract methods first.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add an UML class diagram to the collections.abc module documentation

[Stephen J. Turnbull]

Sorry about the premature send.

Terry Reedy writes:

 > B. Be consistent on placement of inherited versus added methods.  Always 
 > list inherited first?  Different fonts, as suggested, might be
 > good.

I would prefer listing overridden and added methods first, because
there's a good chance I already know from the base classes what
methods are inherited.

On the other hand, I would list abstract methods first, as they form
an agenda for implementing a concrete class.  (I don't have much
experience with this though.)

Steve




___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add an UML class diagram to the collections.abc module documentation

[Stephen J. Turnbull]

Terry Reedy writes:

 > B. Be consistent on placement of inherited versus added methods.  Always 
 > list inherited first?  Different fonts, as suggested, might be
 > good.

I would prefer listing added methods first.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Hmm, yea I had not thought of how it would look - I had thought formost of 
not needing to necessarily learn about bitsets.when learning about passing 
a large number of optional flags to a function.

Although the default could be None, interpreted as an empty set of zero 
values.; a set of one or more enums does use more characters compared to 
or-ing flags...

On Sunday, 31 December 2017 05:34:23 UTC, Guido van Rossum wrote:
>
> On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee  > 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 don't make them IntFlag.
>> - Documentation should show preference toward using sets of Enum
>> flags. Tutorials should pass sets.
>
>
> I'm not keen on this recommendation. An argument that takes a Set[Foo] 
> would mean that in order to specify:
> - no flags: you'd have to pass set() -- you can't use {} since that's an 
> empty dict, not an empty set
> - one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
> - two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than Foo.BAR | 
> Foo.BAZ
>
> I think for each of these the proposal would be strictly worse than the 
> current convention.
>
> -- 
> --Guido van Rossum (python.org/~guido)
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/