[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
R. David Murray
rdmurray at bitdance.com
Fri Apr 26 00:46:23 CEST 2013
On Thu, 25 Apr 2013 14:37:29 -0700, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 04/25/2013 02:25 PM, Eli Bendersky wrote:
> > On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw <barry at python.org <mailto:barry at python.org>> wrote:
> >> On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
> >
> >>> For me, the getitem syntax on a class seems odd and the call syntax is
> >>> TOOWTDI.
> >>
> >> Not if you think of it as a lookup operation instead of an instantiation
> >> operation. It really is the former because neither syntax creates new enum
> >> item objects, it just returns an already existing one.
> >
> > I think it's important to stress what this syntax is actually going to be used for. No one (I hope) is actually going to
> > write Animals(1) or Animals[1]. They will write Animals.ant - this is what enums are for in the first place! The way I
> > see it, this syntax is for enabling *programmatic access* - if you pull the value from a DB and want to convert it to an
> > actual enum value, etc. So do we really need to have two syntaxes for this?
> >
> > The call syntax already has other uses, and it's weird because:
> >
> > Enum(....) -> Creates new enums
> > Animals(....) --> accesses values ?! This is contradictory
> >
> > Animals[...] to serve as a by-value lookup makes sense, though.
>
> How about consistency?
>
> If I'm converting several types of items from a database I'd like to do something like:
>
> result = []
> for field in row:
> type = get_type(field) # returns int, bool, str, or an Enum type
> result.append(type(field))
>
>
> What you're suggesting means complicating the logic:
>
> result = []
> for field in row:
> type = get_type(field) # returns int, bool, str, or an Enum type
> if isinstance(type, Enum):
> result.append(type[field])
> else:
> result.append(type(field))
>
> We just got NoneType fixed to actually return None instead of raising an error for this same type of scenario, why
> should we muddy it up again?
I haven't cared much about this particular bikeshed, but I find this a
somewhat compelling argument. I'm working on a system that depends on
exactly this standard behavior of (most?) built in types in Python: if
you pass an instance or something that can be converted to an instance
to the type constructor, you get back an instance. If Enums break that
paradigm(*), someone would have to write a custom class that provided
that behavior in order to use Enums with my system. I wouldn't say that
was a show stopper, especially since my system may never go anywhere :),
but it certainly is an exemplar of the issue Eli is talking about.
--David
(*) Hmm. NoneType(None) is still an error.
More information about the Python-Dev
mailing list