[Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

Steven D'Aprano steve at pearwood.info
Fri Dec 29 03:18:16 EST 2017

On Thu, Dec 28, 2017 at 12:23:53PM -0800, Paddy3118 wrote:

> Hi Steve, I did not write an attack on the "Python devs". 

I didn't say you attacked anyone and your implication that I did is 

> Re-read my 
> original with a little less hostility and there should be room for an 
> interpretation, (which I meant), that does not warrant such a hostile reply.

Please re-read my response without the hair-trigger defensiveness. 
Disagreement is not hostility. Questioning your statements is not 
hostility. None of us are entitled to only positive responses that agree 
with what we suggest, but we are all entitled to the presumption that we 
are arguing in good faith.

See also:




(I don't agree with *everything* Brett says, but its a good starting 

> The original is written in the hope of furthering discussion on the need 
> for what is deemed pythonic , and on what Python is taught , as the 
> language itself changes.

Right -- and I responded to that discussion.

I asked some genuine questions which you haven't responded to. Let me 
rephrase them:

- Are we currently promoting ints as bitsets?

- How is it relevant that "someone" (who?) wrote a description of using 
ints as bitsets and then deleted it?

- Why is a set of Enums the Pythonic way?

> We now have enums if you want to pass a set of flags to a function then you 
> could have them as separate arguments - but that leads to long and 
> cumbersome parameter lists; you could, and many do, have flags that are 
> individual powers of two and then or them together and pass the result - 
> creating a bitset; but we can now have the flags as separate enum.Enums and 
> pass a set of values to a function as the flag set. 

And no one is stopping anyone from writing code that does so.

> This new way means that people being taught the method can use a knowledge 
> of sets and enums - no need to know about powers of two,, what happens when 
> they are bit-or'd together; and bitsets.

Personally, I think that sets and Enums are no easier to learn than bit 
twiddling. But YMMV.

> We have gone to a higher level description of what we are doing; no 
> need to mired in the details of the how of what one wants to achieve.

Whether we use an int or a set of Enums, we still need to understand the 
details of how to set and clear flags, and test for them.

  THE_FLAG = 8
  the_flags = THE_FLAG | ANOTHER_FLAG

  if the_flags & THE_FLAG:
      print("flag is set")


  class MyFlags(Enum):
      THE_FLAG = "whatever"

  the flags = {THE_FLAG, ANOTHER_FLAG}

  if MyFlags.THE_FLAG in the_flags:
      print("flag is set")

Honestly, I'm not seeing a *lot* of difference here.

> As for re, and otheralready written libraries, their is no need to change 
> them, 

I see. It wasn't clear to me. It seemed to me that you were suggesting 
changing the re module, since that was just an "implementation" detail.

> but other Pythoneers might well opt to not use bitsets, but rather 
> sets of enum values.

Since ints don't provide a set-like interface, they aren't strictly 
speaking bitsets. But in any case, nobody is stopping people from using 
sets of enum values.

If you have a concrete proposal, then please state it explicitly. I 
thought I understood your proposal:

    change the implementation of re to use sets of Enums in order
    to promote their use and act as an example of best practice
    and Pythonic style

but apparently I misunderstood. Sorry. 

So now I'm left puzzled as to what you actually want. Can you be 
explicit and explain what you expect us to do when you say we should 
"teach" and "promote" (your words) Enums instead of using ints? Please 
be concrete.

- Should we change the standard library, and if so, in what ways?

- Should we change the documentation? Which parts?

- Insert something in PEP 8 about using sets of Enums?

- Re-write the tutorial? Where?

- Something else?

Without a concrete proposal, I don't think this discussion is going 


More information about the Python-ideas mailing list