[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 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) -- messages: 400210 nosy: David Rebbe2 priority: normal severity: normal status: open title: enum.auto() starts with one instead of zero versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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? -- ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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. -- ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 file: https://bugs.python.org/file50234/enum_comparison.txt ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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. -- ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Python strayed from something that is considered a standard in almost all other languages? -- ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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? -- ___ Python tracker <https://bugs.python.org/issue44993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/2/tutorial/errors.html#defining-clean-up-actions This seems to not be the case if return inside a finally block, the exception needing to be thrown looks like its tossed out. I'm not sure if this is intended behavior and the docs need to be updated or python isn't doing the correct behavior. Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. -- components: Interpreter Core files: finally_test.py messages: 312014 nosy: David Rebbe priority: normal severity: normal status: open title: finally block doesn't re-raise exception if return statement exists inside type: behavior versions: Python 3.4 Added file: https://bugs.python.org/file47438/finally_test.py ___ Python tracker <https://bugs.python.org/issue32822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 backwards from what I'd expect but makes sense. -- ___ Python tracker <https://bugs.python.org/issue32822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue32822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
