[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Ethan Furman
ethan at stoneleaf.us
Thu Apr 25 23:37:29 CEST 2013
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?
--
~Ethan~
More information about the Python-Dev
mailing list