Re: [Python-Dev] objections to renaming enumobject.h/c in 3.4?

On Fri, Aug 2, 2013 at 11:20 PM, Raymond Hettinger wrote:

On Aug 2, 2013, at 8:47 PM, Eli Bendersky wrote:

I was looking around the Objects directory and noticed that we have enumobject.h/c with the enumobject structure for "enumerate" and "reversed". This is somewhat confusing now with Lib/enum.py and will be doubly confusing if we ever decide to have a C implementation of enums.

Any objections to renaming the files and the internal structure & static functions with s/enum/enumerate/ ? This would more accurately reflect the use of the code, and avoid confusion with enums. These structures/types are not part of the stable ABI defined by PEP 384.

I wouldn't mind renaming enumobject.c/h to enumerateobject.c/h, but I think it is going overboard to rename all the internal structures and static functions. The latter is entirely unnecessary. The C language itself has enums and there has never been any confusion with the enumerate iterator.

My reasoning is this: Objects/enumobject.c currently has functions like enum_new, enum_dealloc, etc. If we ever implement enums in C, we're going to either have to find creative names for them, or have two sets of same-named static functions in two different files. While valid formally, it's confusing for code navigation and similar reasons. However, this can really be delayed until we actually do decide to implement enums in C. For now, just renaming the files should solve most of the problem. Eli