[Enum] fix negative number infinite loop
- _iter_bits_lsb() now raises a ValueError if a negative number
is passed in
- verify() now skips checking negative numbers for named flags
* fix auto() failure during multiple assignment
i.e. `ONE = auto(), 'text'` will now have `ONE' with the value of `(1,
'text')`. Before it would have been `(<an auto instance>, 'text')`
This removes the performance regression in 3.11, **at the expense of not fixing
the "bug" that allows accessing values from values** (e.g. `Color.RED.BLUE`).
Using the benchmark @markshannon [presented](https://github.com/python/cpython/issues/93910#issuecomment-1165503032), the results are:
| Version | Enum | Fast enum | Normal class |
| --- | --- | --- | --- |
| 3.10 | 2.04 | 0.59 | 0.56 |
| 3.11 | 2.78 | 0.31 | 0.15 |
| This PR | 1.30 | 0.32 | 0.16 |
I share this mostly as information about the source of the regression, as this may be useful. It may be that the lower-risk approach for the beta is just to revert to a previously-known working state.
When used with plain Enum, auto() returns the last numeric value assigned, skipping any incompatible member values (such as strings); starting in 3.13 the default auto() for plain Enums will require all the values to be of compatible types, and will return a new value that is 1 higher than any existing value.
Co-authored-by: Ethan Furman <ethan@stoneleaf.us>
GH-26658 introduced a regression in copy / pickle protocol for combined
`enum.Flag`s. `copy.copy(re.A | re.I)` would fail with
`AttributeError: ASCII|IGNORECASE`.
`enum.Flag` now has a `__reduce_ex__()` method that reduces flags by
combined value, not by combined name.
In previous versions of Python if an IntEnum member was combined with another integer type value using a bit-wise operation, the resulting value would still be the IntEnum type. This change restores that behavior.
- add member() and nonmember() functions
- add deprecation warning for internal classes in enums not
becoming members in 3.13
Co-authored-by: edwardcwang
Undo rejected PEP-663 changes:
- restore `repr()` to its 3.10 status
- restore `str()` to its 3.10 status
New changes:
- `IntEnum` and `IntFlag` now leave `__str__` as the original `int.__str__` so that str() and format() return the same result
- zero-valued flags without a name have a slightly changed repr(), e.g. `repr(Color(0)) == '<Color: 0>'`
- update `dir()` for mixed-in types to return all the methods and attributes of the mixed-in type
- added `_numeric_repr_` to `Flag` to control display of unnamed values
- enums without doc strings have a more comprehensive doc string added
- `ReprEnum` added -- inheriting from this makes it so only `__repr__` is replaced, not `__str__` nor `__format__`; `IntEnum`, `IntFlag`, and `StrEnum` all inherit from `ReprEnum`
In `__set_name__` there is a check for the `_value_` attribute and an attempt to add it if missing; this adds a test to cover the case for simple enums with a custom `__new__` method.
add tests that exercise the `_missing_` error path for `Flag` and `IntFlag`
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Co-authored-by: Ethan Furman <ethan@stoneleaf.us>
Modify the ``EnumType.__dir__()`` and ``Enum.__dir__()`` to ensure
that user-defined methods and methods inherited from mixin classes always
show up in the output of `help()`. This change also makes it easier for
IDEs to provide auto-completion.
* Fix typo in __repr__ code
* Add more tests for global int flag reprs
* use last module if multi-module string
- when an enum's `__module__` contains several module names, only
use the last one
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Co-authored-by: Ethan Furman <ethan@stoneleaf.us>
* [Enum] reduce scope of new format behavior
Instead of treating all Enums the same for format(), only user mixed-in
enums will be affected. In other words, IntEnum and IntFlag will not be
changing the format() behavior, due to the requirement that they be
drop-in replacements of existing integer constants.
If a user creates their own integer-based enum, then the new behavior
will apply:
class Grades(int, Enum):
A = 5
B = 4
C = 3
D = 2
F = 0
Now: format(Grades.B) -> DeprecationWarning and '4'
3.12: -> no warning, and 'B'
by-value lookups could fail on complex enums, necessitating a check for
__reduce__ and possibly sabotaging the final enum;
by-name lookups should never fail, and sabotaging is no longer necessary
for class-based enum creation.
This enables, for example, two base Enums to both inherit from `str`, and then both be mixed into the same final Enum:
class Str1Enum(str, Enum):
# some behavior here
class Str2Enum(str, Enum):
# some more behavior here
class FinalStrEnum(Str1Enum, Str2Enum):
# this now works
In 3.12 ``True`` or ``False`` will be returned for all containment checks,
with ``True`` being returned if the value is either a member of that enum
or one of its members' value.
In 3.12 the enum member, not the member's value, will be used for
format() calls. Format specifiers can be used to retain the current
display of enum members:
Example enumeration:
class Color(IntEnum):
RED = 1
GREEN = 2
BLUE = 3
Current behavior:
f'{Color.RED}' --> '1'
Future behavior:
f'{Color.RED}' --> 'RED'
Using d specifier:
f'{Color.RED:d}' --> '1'
Using specifiers can be done now and is future-compatible.
Previously TestIntEnumConvert and TestStrEnumConvert would end up
converting the module level variables from their regular int form
to a `test.test_enum.X` instance after _convert would run. This
meant that after a single test ran, the next set of _convert
functions would be operating on the enum instances rather than
ints. This would cause some tests such as the one involving format
to fail when running under a mode that repeatedly runs test such
as the refleak finder.
Ethan Furman
Nikita Sobolev
Michael Droettboom
Serhiy Storchaka
Sam Ezeh
Oscar R
Carl Bordum Hansen
Christian Heimes
Dong-hee Na
Kumar Aditya
Victor Stinner
Alex Waygood
Pablo Galindo Salgado
Brandon Schabell
Ammar Askar