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

[Eli Bendersky]

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 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