On Sun, Nov 28, 2010 at 9:26 AM, Raymond Hettinger
<raymond.hettin...@gmail.com> wrote:
>
> On Nov 27, 2010, at 12:56 PM, Glenn Linderman wrote:
>
>> On 11/27/2010 2:51 AM, Nick Coghlan wrote:
>>>
>>> Not quite. I'm suggesting a factory function that works for any value,
>>> and derives the parent class from the type of the supplied value.
>>
>> Nick, thanks for the much better implementation than I achieved; you seem to
>> have the same goals as my implementation. I learned a bit making mine,
>> and more understanding yours to some degree. What I still don't understand
>> about your implementation, is that when adding one additional line to your
>> file, it fails:
>>
>> w = named_value("ABC", z )
>>
>> Now I can understand why it might not be a good thing to make a named value
>> of a named value (confusing, at least), but I was surprised, and still do
>> not understand, that it failed reporting the __new__() takes exactly 3
>> arguments (2 given).
>
> Can I suggest that an enum-maker be offered as a third-party module rather
> than prematurely adding it into the standard library.
Indeed. Glenn's failing example suggests to me that using a new
metaclass is probably going to be a cleaner option than trying to
dance around type's default behaviour within an ordinary class
definition (if nothing else, a separate metaclass makes it much easier
to detect when you're dealing with an instance of a named type).
Regardless, I still see value in approaching this whole discussion as
a two-level design problem, with "named values" as the more
fundamental concept, and then higher level grouping APIs to get
enum-style behaviour. Eventually attaining "One Obvious Way" for the
former seems achievable to me, while the diversity of use cases for
grouping APIs suggests to me that "one-size-fits-all" isn't going to
work unless that "one size" is a Frankenstein API with more options
than anyone could reasonably hope to keep in their head at once.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
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
