Re: [Python-Dev] cpython: simplify and rewrite the zipimport part of 702009f3c0b1 a bit
Am 25.05.2012 07:54, schrieb benjamin.peterson:
http://hg.python.org/cpython/rev/a47d32a28662 changeset: 77129:a47d32a28662 user: Benjamin Peterson <benjamin@python.org> date: Thu May 24 22:54:15 2012 -0700 summary: simplify and rewrite the zipimport part of 702009f3c0b1 a bit
files: Modules/zipimport.c | 92 ++++++++++++++------------------ 1 files changed, 41 insertions(+), 51 deletions(-)
diff --git a/Modules/zipimport.c b/Modules/zipimport.c --- a/Modules/zipimport.c +++ b/Modules/zipimport.c @@ -319,13 +319,20 @@ return MI_NOT_FOUND; }
+typedef enum { + fl_error, + fl_not_found, + fl_module_found, + fl_ns_found +} find_loader_result;
This is probably minor, but wouldn't it make more sense to have those constants uppercased? At least that's the general style we have in the codebase for enum values. (There's one exception, but also recently committed, in posixmodule.c for the utime_result enum. Maybe that could also be fixed.) Georg
On Fri, 25 May 2012 18:57:57 +0200 Georg Brandl <g.brandl@gmx.net> wrote:
Am 25.05.2012 07:54, schrieb benjamin.peterson:
http://hg.python.org/cpython/rev/a47d32a28662 changeset: 77129:a47d32a28662 user: Benjamin Peterson <benjamin@python.org> date: Thu May 24 22:54:15 2012 -0700 summary: simplify and rewrite the zipimport part of 702009f3c0b1 a bit
files: Modules/zipimport.c | 92 ++++++++++++++------------------ 1 files changed, 41 insertions(+), 51 deletions(-)
diff --git a/Modules/zipimport.c b/Modules/zipimport.c --- a/Modules/zipimport.c +++ b/Modules/zipimport.c @@ -319,13 +319,20 @@ return MI_NOT_FOUND; }
+typedef enum { + fl_error, + fl_not_found, + fl_module_found, + fl_ns_found +} find_loader_result;
This is probably minor, but wouldn't it make more sense to have those constants uppercased? At least that's the general style we have in the codebase for enum values.
+1, this surprised me too. Regards Antoine.
On 05/25/2012 10:14 AM, Antoine Pitrou wrote:
On Fri, 25 May 2012 18:57:57 +0200 Georg Brandl<g.brandl@gmx.net> wrote:
This is probably minor, but wouldn't it make more sense to have those constants uppercased? At least that's the general style we have in the codebase for enum values. +1, this surprised me too.
FWIW I contributed the utime enum with the lowercase values. I don't uppercase enum values as a rule. Uppercasing preprocessor macros is a good idea because they're not safe. There are loads of ways they can produce unexpected behavior. So if something funny is going on, and the code involves some preprocessor slight-of-hand, those identifiers pop out at you and you know to double-check them. But enum values are as safe as houses. I think of them as equivalent to const ints, which I also don't uppercase. There's no need to draw attention to them. There's nothing in PEP 7 either way about enum nomenclature. But Benjamin has already uppercased these (and some other) enums, so I suppose the community has spoken. //arry/
On Sat, May 26, 2012 at 2:07 AM, Larry Hastings <larry@hastings.org> wrote:
On 05/25/2012 10:14 AM, Antoine Pitrou wrote:
On Fri, 25 May 2012 18:57:57 +0200 Georg Brandl <g.brandl@gmx.net> wrote:
This is probably minor, but wouldn't it make more sense to have those constants uppercased? At least that's the general style we have in the codebase for enum values.
+1, this surprised me too.
FWIW I contributed the utime enum with the lowercase values. I don't uppercase enum values as a rule.
Uppercasing preprocessor macros is a good idea because they're not safe. There are loads of ways they can produce unexpected behavior. So if something funny is going on, and the code involves some preprocessor slight-of-hand, those identifiers pop out at you and you know to double-check them. But enum values are as safe as houses. I think of them as equivalent to const ints, which I also don't uppercase. There's no need to draw attention to them.
There's nothing in PEP 7 either way about enum nomenclature. But Benjamin has already uppercased these (and some other) enums, so I suppose the community has spoken.
I think the convention is that constants are uppercased -- enums are definitely constants. It helps the reader quickly to see what is variable and what is constant in an expression -- when I see x == 42, I know which is which, but when I see x == y, I don't. If I see x == Y, I know. -- --Guido van Rossum (python.org/~guido)
participants (4)
-
Antoine Pitrou -
Georg Brandl -
Guido van Rossum -
Larry Hastings