Ethan Furman added the comment: > Yes, you're correct here, but what about output? Do all relevant bits have > to be named separately?
No. > And will the output always talk about separate > bits? No. > 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. Thanks. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23591> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
