enum.auto() By default, the initial value starts at 1. Per the documentation here: https://docs.python.org/3/library/enum.html#enum.auto

This doesn't really follow expected behavior in majority of programming languages nor python. Most will expect starting value to be zero. I personally skipped over this as I've never seen an enum start at 1 in any language before. Excuse my ignorance if this is more common place then I realize.

I propose an optional argument to the class to allow different starting values: enum.auto(0)

For IntEnum, maybe. But for Enum, the whole point of auto() is that the values don't really matter. The rationale was that with IntEnum, truth testing (which is often used in Python to realize Optional) would distinguish None, and then all true Enums would actually be true in the boolean sense.

In a way, most real examples of enums already have some "fake" value which they map to 0. In Python, you idiomatically use None for that.

Understandable and I do believe IntEnum should default as zero as its the default type most will choose when trying to mimic other languages.

C/C++ has the same problem where the value isn't suppose to matter but as soon as you go across the compiled / interpreted application (libraries and network communication) the value of the enum becomes important. 

I have corrected all my code to have a "fake" value of 0 instead of using enum.auto() as the first value, but it would be nice to not have to use that workaround. Maybe a new class CIntEnum would be acceptable?

I think you should be even more explicit. If values matter, they _should_ be seen in code. (All of them, not just the first one.) auto() just means "this value doesn't really matter". And it's not really hard to write concrete values instead of auto(), in many instances it's even easier. :-)

I only created this issue because its a deviation from any standard that exists AFAIK. Nothing I know of starts at 1 in programming and I more than likely won't be the last one to make this mistake. If indexing in Python started at 1 or any other accessor for that matter started with 1 I could understand it but it doesn't. Its even an ongoing online joke that "arrays start at 1". 

Most other language enum types are not explicit in value definitions because they don't matter, they now have to matter and be explicit in python due to this deviation.

Honestly, I think it's backwards. Either they _do_ matter because of some external factor (you mention network interoperability, though I'd like you to clarify... what exactly did you send over the network?), or they don't matter (if done right, you shouldn't even _notice_ that they start at 1 --- unless you test their truth value, which was the reason for the original departure from the usual practice in the first place).

You mention indexing... I _hope_ you're not using IntEnums for indexing tuples (or lists). :-o In such a scenario, you're really much better off cutting the middleman and using objects with attributes directly (an interesting insight: due to the way most objects in Python are implemented, you _still_ have the middlemen integers in the process -- only they are called "hash values" and they _truly_ don't matter:).

Welcome to enums, they don't matter until they do. I'm personally not a fan of enums for APIs but they exist all the time.

Indexing was an example case that nothing starts at 1.

See the attached file to demonstrate differences.

_But why should it matter that starting value is the same_ unless you actually use IntEnums for indexing?

About your code: what do you _actually_ mean by "equivalent"? I hope you don't think that the memory representation is the same. You keep mentioning APIs and networks, but never concretely... do you intend to say that you somehow serialize those values, send them over the wire and then deserialize them into another language?

Definition of equivalent
1: equal in force, amount, or value

Are you referring to memory space as what is actually stored in RAM? If so, that seems to be outside the scope here. I don't think anyone expected an interpreted language to have the same memory space as a compiled binary from C for example.

Concretely anything to do with Serialization, API (ctypes), network communication (non-serialization), etc will fail.

Regardless of the reasons above, 1 is never the intended default value of anything default initialized in any language I've ever come across.

Other than it’s not what you expect, do you have a concrete example of what problem this is causing you?

We’re unlikely to change anything without knowing what problem is being solved.

Seems like there is a misunderstanding here as to why this is an issue.  I can write an example up that would expand on the file I attached, but I feel like anyone that has experience in the above situations would identify this as an issue.

Can I ask why Python strayed from something that is considered a standard in almost all other languages?

I think everyone understands, we just feel that it doesn't matter.

You can see if PEP 435 answers your question.

Changing to an enhancement request for 3.11, for the proposal to add a optional argument to auto().

Firstly (or Zeroithly ;) my apologies for not noticing this earlier.


In the functional API section:
------------------------------
The reason for defaulting to 1 as the starting number and not 0 is that 0 is False in a boolean sense, but enum members all evaluate to True.

---

To the best of my knowledge, Python Enums are different from other languages' enums in several respects; apparently this is one of them.  Having the default first value be 1 has been there since the beginning, and isn't going to change now.

Rather than allowing numbers to be assigned using the function that says the assigned number doesn't matter, I would rather add `start=x` in the header, the way I have it in `aenum`:

    from aenum import Enum, auto

    class ZeroEnum(Enum, start=0):
        nothing = auto()
        something = auto()

    list(ZeroEnum)
    # [<ZeroEnum.nothing: 0>, <ZeroEnum.something: 1>]

    class ZeroBaseEnum(Enum, start=0):
        pass

    class ZeroEnum2(ZeroBaseEnum):
        nothing = auto()
        something = auto()

    list(ZeroEnum2)
    # [<ZeroEnum2.nothing: 0>, <ZeroEnum2.something: 1>]


Whether the `0` goes in the header, or in auto (which it isn't), people will still need to read the docs to find out about it (unless somebody asks an SO question, of course).

My apologies for my apologies -- for some reason I thought this was first posted in August of 2020.

David, what is the actual use-case that tripped you up?  There are a few ways to create Enums from other systems (json files, cpp files, etc.).

Thank you for referencing the PEP, I just managed to read through it and I still don't have a very good understanding why it needs to default to 1. PEP 435 states:

"The reason for defaulting to 1 as the starting number and not 0 is that 0 is False in a boolean sense, but enum members all evaluate to True."

I can't find anything in the PEP that states why enum members need to evaluate to True. What am I missing here?

I was specifically tripped up with the generator I wrote that takes a C header and converts it to python ctype/enum objects. I have fixed the issue so its not a show stopper by any means its just not expected behavior for anyone with programming experience with enums outside Python. 

Here is the project in question where I discovered this:
https://github.com/intrepidcs/python_ics/issues/105

enum in question:
https://github.co/intrepidcs/python_ics/blob/master/ics/structures/e_device_settings_type.py
which is generated from this:
https://github.com/intrepidcs/python_ics/blob/master/include/ics/icsnVC40.h#L3410


Maybe it would be better to have an Enum type in the ctypes module instead to match all other language enums?

Putting an enum in the ctypes module is a decent idea.

And CEnum is probably the best name for it. "Int" part is pretty much implied in "C" part.

David, I added a PR for the Enum handling/creation in the ics library.  Syncing values with external libraries is definitely *not* what `auto` is intended for.

As for why enum members evaluate as True:  most objects in Python evaluate to True, unless they have a reason not to (such as an empty container or the number 0).  One of the main ideas behind the creation of Enum is that the exact values didn't usually matter,  but when they did they would be specified.  `auto()` was added later to make the "doesn't usually matter" case easier.

---

Vedran, or `cEnum`?  ;-)

One concern is should cEnum be Python's `int`, or a c_type int?  That should be in a new issue, though.

Okay, it's Issue45004.