[issue44993] enum.auto() starts with one instead of zero

David Rebbe added the comment: 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

[issue44993] enum.auto() starts with one instead of zero

David Rebbe added the comment: 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

[issue44993] enum.auto() starts with one instead of zero

David Rebbe added the comment: 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 m

[issue44993] enum.auto() starts with one instead of zero

David Rebbe added the comment: 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. -- Added f

[issue44993] enum.auto() starts with one instead of zero

David Rebbe added the comment: 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 accesso

[issue44993] enum.auto() starts with one instead of zero

David Rebbe added the comment: 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 com

[issue44993] enum.auto() starts with one instead of zero

New submission from David Rebbe : 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 sta

[issue32822] finally block doesn't re-raise exception if return statement exists inside

David Rebbe added the comment: I'll have to look into this as I have yet to commit anything but I'll put it on my list of things to do. -- ___ Python tracker <https://bugs.python.o

[issue32822] finally block doesn't re-raise exception if return statement exists inside

David Rebbe added the comment: Oops I didn't realize I referenced the tutorial documentation. Maybe it would be better to mention this behavior in the tutorial documentation also. I've always assumed exception raises take priority over any return/break/continues. Behavior is back

[issue32822] finally block doesn't re-raise exception if return statement exists inside

New submission from David Rebbe : According to the docs: "When an exception has occurred in the try clause and has not been handled by an except clause (or it has occurred in an except or else clause), it is re-raised after the finally clause has been executed." https://docs.py