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

[Nick Coghlan]

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

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