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?
--
~Ethan~
_______________________________________________
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
