RetroSearch Browse

Fri Apr 26 00:46:23 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-April/125555.html

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.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-April/125555.html below:

[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library