[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-list
Subject:    Re: PEP 354: Enumerations in Python
From:       Ben Finney <bignose+hates-spam () benfinney ! id ! au>
Date:       2006-03-01 0:50:17
Message-ID: 87hd6j3s51.fsf () rose ! polar ! local
[Download RAW message or body]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> Ben Finney <bignose+hates-spam@benfinney.id.au> writes:
>> If an enumeration object were to be derived from, I would think it
>> just as likely to want to have *fewer* values in the derived
>> enumeration. Subclassing would not appear to offer a simple way to
>> do that.
>
> pentium_instructions = enum('add', 'sub', 'mul', ) # etc
>
> athlon64_instructions = enum('add64', 'sub64', # etc
>                              base_enum=pentium_instructions)
>
> # 386 has no floating point unit
> i386_instructions = enum(base_enum=pentium_instructions,
>                          remove=('addf', 'subf', 'mulf',))  # etc

These don't seem simple or elegant. I don't see a particular benefit
to doing it that way, rather than being explicit about manipulating
the member list::

    pentium_instructions = enum('add', 'sub', 'mul')
    athlon64_instructions = enum(
        *[ str(i) for i in pentium_instructions] + ['add64', 'sub64'] )
    i386_instructions = enum(
        *[ str(i) for i in pentium_instructions
            if i not in ['addf', 'subf', 'mulf'] ] )

I don't see a benefit to having the enum constructor grow extra
keyword arguments for operating on lists, when a list has its own
methods for doing so.

-- 
 \         "A fine is a tax for doing wrong. A tax is a fine for doing |
  `\                                              well."  -- Anonymous |
_o__)                                                                  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list
[prev in list] [next in list] [prev in thread] [next in thread]