PEP 354: Enumerations in Python

Cyril Bazin cyril.bazin at info.unicaen.fr
Tue Feb 28 07:42:31 EST 2006


What about that?

SomeNumbers = enum('0', '1', '2', '3', '4', '5', '6', '7')

or

Rooms = enum('1bed', '2beds', 'moreThan2beds')

or even

Comments = enum('#', ';', '//')


Cyril

On 28 Feb 2006 03:14:25 -0800, Carl Banks <invalidemail at aerojockey.com>
wrote:
>
> Stefan Rank wrote:
> > on 28.02.2006 07:50 Carl Banks said the following:
> > > Ben Finney wrote:
> > >> This PEP specifies an enumeration data type for Python.
> > >
> > [snip]
> > >
> > > Here's why I think it's not too useful to begin with: the benefits of
> > > the enum you describe here are pretty weak.
> >
> > I need to disagree heavily here :)
>
> "the benefits of the enum you describe here [beyond my example which I
> claimed enum was only a minor improvement over] are pretty weak."
>
>
> > > It's a pretty weak case to have a dedicated builtin to prevent
> > > duplicates in something that changes maybe once a month, as enums tend
> > > to change rather slowly.  (At least, that's the way enums in other
> > > languages are used, and the design you present here seems to suggest
> > > you intend to use them that way as well.)  And frankly, a unit test or
> > > assertion could check this.
> > [snip]
> >
> > I don't understand what you mean by 'change rather slowly'?
>
> Construct data structure on-the-fly from an XML file edited by multiple
> people every day  = changes rather quickly
>
> Construct data structure from a Python file that was last edited a year
> and a half ago = changes rather slowly
>
> Typically, enums fall into the latter category.  You set the enum
> values, and then pretty much leave them alone, adding new values only
> occasionally.  (Come on, how often do the days of the week change?)
> All I was saying is, changes to the enum values are infrequent enough
> that having a special type just to make sure there are no duplicates is
> a waste.  The only justification for a built-in enum is the other stuff
> you mentioned.
>
>
> > One thing that is probably missing to allow this, is a enum-set-creation
> > with the | operator::
> >
> >    Weekdays = enum('mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun')
> >    daysihate = Weekdays.mon | Weekdays.thu
> >
> > (and this discussion needs to move to python-dev ?)
>
> What's wrong with set((Weekdays.mon,Weekdays.thu))?  Explicit is better
> than implicit.
>
>
> > As for the metaclass versions: For myself, the above version feels more
> > natural and straightforward (in the same way as the PEP author describes
> > it), though I understand the subclassing ideas.
> >
> > But are there use cases for subclassing, that aren't better served with
> > a new enum or something homegrown?
> > Can C++/Pascal/Java enums be subclassed?
>
> In C++, enum is a type but not a class.  Same thing with Ada.  Java
> didn't have enums last time I checked.  Don't know about Pascal.  I
> didn't care too much about subclassing; I just thought different enum
> constant that couldn't (or, rather, oughtn't) be compared probably
> should be instances of a separate class.  It doesn't matter much,
> though.
>
> Should something like this work:
>
> day = Weekdays.mon
> isinstance(day,Weekdays)
>
> ?
>
>
> Carl Banks
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20060228/951237a9/attachment.html>


More information about the Python-list mailing list