[Python-Dev] objections to renaming enumobject.h/c in 3.4? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Aug 3 15:17:59 CEST 2013

On 3 August 2013 22:39, Eli Bendersky <eliben at gmail.com> wrote:

On Fri, Aug 2, 2013 at 11:20 PM, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:

On Aug 2, 2013, at 8:47 PM, Eli Bendersky <eliben at gmail.com> 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 enumnew, enumdealloc, 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.

Yep, this is an area where laziness is definitely a virtue - if work is only needed to handle a hypothetical future change, then it can be deferred and handled as part of that change. :)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list