Skip to content

Regarding irregular flag enumerations, aliases and canonical members #153802

Description

@jbdyn

This is a follow-up to #150577.

I did not find any other issues about my findings.

Flag enumeration members feature iteration, which yields only canonical members and not aliases, i.e. members being composed of canonical members.

However, there can be alias members being composed of absent canonical members:

from enum import Flag

class Missing(Flag):
    A = 7

assert list(Missing) == []
assert list(Missing.A) == [None, None, None]
assert ~Missing(0) == Missing(0)

Another real example are the flag enums in the ssl module, where canonical members are partially absent, analogous to:

from enum import Flag

class Partial(Flag):
    A = 1
    # Maybe there once was a `B` here?
    C = 3  # Is `C` now meant to be canonical?

assert list(Partial) == [Partial.A]
assert list(Partial.C) == [Partial.A, None]
assert ~Partial(0) == Partial.A

For completeness: Named zero-valued flags are also ignored, although being canonical:

from enum import Flag

class Named(Flag):
    ZERO = 0
    ONE = 1

assert list(Named) == [Named.ONE]
assert list(Named.ONE) == [Named.ONE]
assert ~Named.ONE == Named.ZERO

A remapping of values is the obvious approach, but not always feasible. For the ssl module, the flag values are dictated by the external OpenSSL library.

My expectation is that aliases composed of absent canonical members are also considered canonical and thereby yielded by iteration.


As a side note: Interestingly, for an IntFlag, missing values are added:

from enum import IntFlag

class Added(IntFlag):
    A = 2

print(~Added(0))
# <Added.A|1: 3>

Metadata

Metadata

Assignees

Labels

stdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

Fields

No fields configured for issues without a type.

Projects

Status
No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions