On 04/25/2013 03:46 PM, R. David Murray wrote:
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.
Um, did you mean "of the issue Ethan is talking about"? 'Cause Eli is against
it.
(*) Hmm. NoneType(None) is still an error.
Hmm, so it is. When I pushed for the change just having NoneType() work was
sufficient.
--
~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
