On Thu, 25 Apr 2013 14:37:29 -0700, Ethan Furman <et...@stoneleaf.us> wrote: > On 04/25/2013 02:25 PM, Eli Bendersky wrote: > > On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw <ba...@python.org > > <mailto:ba...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
