On 5/31/2021 1:37 PM, Luciano Ramalho wrote:
On Fri, May 28, 2021 at 7:00 PM Joao S. O. Bueno <jsbu...@python.org.br> wrote:
"check_all_bits_defined" or something along it.
Best suggestion so far. Similar:
"ensure_all_bits_named"
I am all for brainstorming, as we've been doing for a few days. Maybe
we need to brainstorm some more.
I just don't think the goal should be finding a one/two-word name for
the decorator.
I see no need to find something shorter than a short sentence. After
all, defining a new enum is not something we do all the time.
Cheers,
Luciano
In this vein, I suggest these variations
@name_all_used_flags
@require_individual_flag_names
Clearly some flags may not be used, and need not be named, but this
would require all the used flags to be (individually) named, without
precluding combinations of same.
And while I am guilty of using the word "bits" in prior suggestions, I
realized today that the name of the Enum variety under discussion is
"IntFlag" not "IntBits", so it seems more appropriate to use the word
"flag" or "flags" rather than "bits", even though the implementation of
a boolean flag is a single bit.
So I withdraw my prior suggestions of @all_bits_defined and
@unique_bits in favor of @all_flags_defined and @unique_flags.
Digression/Extensions:
I'm also starting to wonder if Flag & IntFlag should be restricted to
individual flags and combinations, and if another variety of Enum, that
is very, very similar, should be called IntBitfields. On the other
hand, if there are a few flags and a small bitfield or two, that are
sufficiently related, having them contained in a single Enum might be
appropriate, and such has certainly been used on pre-existing APIs with
plain int values manipulated with logical operators.
Without having any clue as to how hard the implementation might be, or
how it would conflict with other uses of decorators, and without any
concern for the exact details of the implementation, if another syntax
would be easier, I wonder if something along the lines of new syntax
would be preferable to a decorator, when the possibility exists for both
flags and bitfields to be defined in the same Enum:
class SomeSpecificInt( IntBitfields ):
COLORS( 3 ): flags = {
RED = 1
GREEN = 2
BLUE = 4
PURPLE = RED | BLUE
},
OPACITY( 4 ): int,
DITHER( 4 ): values = {
CROSSHATCH = auto(),
SLANTED30DEGREES = auto(),
SLANTED45DEGREES = auto(),
SLANTED60DEGREES = auto(),
DOTS25PERCENT = auto(),
DOTS50PERCENT = auto(),
DOTS75PERCENT = auto(),
},
}
The idea here would be that "flags" values would be unique bits that are
in a 3-bit field, OPACITY would be an integer in a 4-bit field, and
DITHER would be a set of unique values (only 4 defined so far, but
allowing up to 15 values in a 4-bit field for future expansion).
To require the COLORS to have uniquely named flags, a different keyword
would be used instead of or in addition to "flags": COLORS( 3 ):
individual flags [or COLORS( 3 ): individual_flags ]
I realize this adds more complexity, and is far beyond the original
proposal, but it also adds missing power to subdivided int values. The
values for DITHER would be from 1-15 when extracted or cast, with the
shifting done by the Enum implementation.
Or maybe instead of the above proposal, the decorator approach could be
taken for individual IntFlag classes, but a new "CombinedEnum" could be
defined to join multiple Enum classes into a single "int" with
bitfields. In that case, the explicit bitfield sizes given in the above
syntax would only be used for CombinedEnum, but the member Enum classes
that are combined would have to meet the constraint of fitting their
values into that many bits.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/U6B74BNJ76COD4WQE7UR4IQXHU4W5F6K/
Code of Conduct: http://python.org/psf/codeofconduct/
