This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ethan.furman
Recipients barry, eli.bendersky, ethan.furman, ezio.melotti, martin.panter, python-dev, r.david.murray, rhettinger, serhiy.storchaka, veky, vstinner
Date 2016-09-02.14:40:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Yes, you're correct here, but what about output? Do all relevant bits have
> to be named separately?


> And will the output always talk about separate
> bits?


> We have talked about this.

Indeed.  Here's my previous reply. ;)

>> The algorithm is simple: start with the biggest Flag and mask off
>> matching bits until all bits are are matched.

When I said "biggest flag" I meant the flag with the highest value (so a flag of 5 would get matched before a flag of four).

>> If any unmatched bits remain an error is raised.

This part is specifically for Flag; IntFlag will just show the values of any unmatched bits.

> If I give meaningful name to 1, 3, 4 and
> 6, but not to 2, is it supported?

Depends.  Not having 2 named has different consequences for Flag vs IntFlag (although neither is an error):

- Flag: no combination of flags will ever have the 2 bit set
- IntFlag: '2' will show in the name portion if the 2 bit is set

> And is the repr of 7 an implementation detail, or is it specified?

I should specify it in the docs, thanks.

> One more question: in the docs, you say 
>> otherwise, all members evaluate as :data:`True`.
>I would like you to reconsider the case of `.0` (.NONE in my
> terminology). Many other things in the interface (e.g. `in` operator)
> are modelled as if flags instance were just a container (set, in fact)
> of bits. In that case, empty set _should_ be false. Otherwise, this will
> be a weird exception to the usual container semantics.

Very good point.  Unless I can think of a good reason not to, I'll make that change in the next couple days.

Date User Action Args
2016-09-02 14:40:33ethan.furmansetrecipients: + ethan.furman, barry, rhettinger, vstinner, ezio.melotti, r.david.murray, eli.bendersky, python-dev, martin.panter, serhiy.storchaka, veky
2016-09-02 14:40:33ethan.furmansetmessageid: <>
2016-09-02 14:40:33ethan.furmanlinkissue23591 messages
2016-09-02 14:40:33ethan.furmancreate