Update documentation with `__new__` and `__init__` entries.
Support use of `auto()` in tuple subclasses on member assignment lines. Previously, auto() was only supported on the member definition line either solo or as part of a tuple:
RED = auto()
BLUE = auto(), 'azul'
However, since Python itself supports using tuple subclasses where tuples are expected, e.g.:
from collections import namedtuple
T = namedtuple('T', 'first second third')
def test(one, two, three):
print(one, two, three)
test(*T(4, 5, 6))
# 4 5 6
it made sense to also support tuple subclasses in enum definitions.
add guard so that ``Enum('bar')`` raises a TypeError instead of
creating a new enum class called `bar`. To create the new but
empty class, use:
huh = Enum('bar', names=())
When overriding the `__new__` method of an enum, the underlying data type should be created directly; i.e. .
member = object.__new__(cls)
member = int.__new__(cls, value)
member = str.__new__(cls, value)
Calling `super().__new__()` finds the lookup version of `Enum.__new__`, and will now raise an exception when detected.
When inverting a Flag member (or boundary STRICT), only consider other canonical flags; when inverting an IntFlag member (or boundary KEEP), also consider aliases.
For example:
class Book(StrEnum):
title = auto()
author = auto()
desc = auto()
Book.author.desc is Book.desc
but
Book.author.title() == 'Author'
is commonly expected. Using upper-case member names avoids this confusion and possible performance impacts.
Co-authored-by: samypr100 <3933065+samypr100@users.noreply.github.com>
When checking for auto() instances, only top-level usage is supported,
which means either alone or as part of a regular tuple. Other
containers, such as lists, dicts, or namedtuples, will not have auto()
transformed into a value.
* use final status to determine lookup or create
* 📜🤖 Added by blurb_it.
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
[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>
Ethan Furman
Nikita Sobolev
Pieter Eendebak
Alex Waygood
Prince Roshan
Sadra Barikbin
Dong-hee Na
Steve Dower
Takeshi KOMIYA
wim glenn
Alexandru Mărășteanu
Michael Droettboom
Serhiy Storchaka
Sam Ezeh
Oscar R