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

Nick Coghlan ncoghlan at gmail.com
Sat Aug 3 08:35:24 CEST 2013

On 3 August 2013 16:20, 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.

Oops, I missed the part about renaming things in the code. I'm with Raymond on that part (i.e. not worth it) - I was just agreeing to renaming the files.

Cheers, Nick.

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

More information about the Python-Dev mailing list