Mailing List Archive: Python: Dev

objections to renaming enumobject.h/c in 3.4?

Index | Next | Previous | View Threaded

eliben at gmail

Aug 2, 2013, 8:47 PM

Post #1 of 7 (59 views)
Permalink

objections to renaming enumobject.h/c in 3.4?

Hi all,

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.

Eli

ncoghlan at gmail

Aug 2, 2013, 10:50 PM

Post #2 of 7 (58 views)
Permalink

Re: objections to renaming enumobject.h/c in 3.4? [In reply to]

On 3 Aug 2013 13:50, "Eli Bendersky" <eliben [at] gmail> wrote:
>
> Hi all,
>
> 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.

Sounds good to me.

Cheers,
Nick.

>
> Eli
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>

raymond.hettinger at gmail

Aug 2, 2013, 11:20 PM

Post #3 of 7 (58 views)
Permalink

Re: objections to renaming enumobject.h/c in 3.4? [In reply to]

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

Raymond

ncoghlan at gmail

Aug 2, 2013, 11:35 PM

Post #4 of 7 (58 views)
Permalink

Re: objections to renaming enumobject.h/c in 3.4? [In reply to]

On 3 August 2013 16:20, Raymond Hettinger <raymond.hettinger [at] gmail> wrote:
>
> On Aug 2, 2013, at 8:47 PM, Eli Bendersky <eliben [at] gmail> 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 | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

eliben at gmail

Aug 3, 2013, 5:39 AM

Post #5 of 7 (50 views)
Permalink

Re: objections to renaming enumobject.h/c in 3.4? [In reply to]

On Fri, Aug 2, 2013 at 11:20 PM, Raymond Hettinger
<raymond.hettinger [at] gmail> wrote:
>
> On Aug 2, 2013, at 8:47 PM, Eli Bendersky <eliben [at] gmail> 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
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Aug 3, 2013, 6:17 AM

Post #6 of 7 (50 views)
Permalink

Re: objections to renaming enumobject.h/c in 3.4? [In reply to]

On 3 August 2013 22:39, Eli Bendersky <eliben [at] gmail> wrote:
> On Fri, Aug 2, 2013 at 11:20 PM, Raymond Hettinger
> <raymond.hettinger [at] gmail> wrote:
>>
>> On Aug 2, 2013, at 8:47 PM, Eli Bendersky <eliben [at] gmail> 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 | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

alexander.belopolsky at gmail

Aug 3, 2013, 1:04 PM

Post #7 of 7 (49 views)
Permalink

Re: objections to renaming enumobject.h/c in 3.4? [In reply to]

On Sat, Aug 3, 2013 at 9:17 AM, Nick Coghlan <ncoghlan [at] gmail> wrote:

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

I would say that even renaming the files can wait until we actually have a
conflict. Note that reimplementing enum.py in C will not cause a conflict
because that code will likely go to Modules/enum.c or Modules/_enum.c and
not in Objects/enumobject.c. If any renaming in Objects/ directory is in
order, I would start with longobject.c and unicodeobject.c rather than
enumobject.c. It is fairly obvious to look for enumerate code next to
range code and tab-completion gets me to the right file fairly quickly. On
the other hand, I've been trying to find intobject.c in 3.x code on more
than one occasion.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads