RetroSearch Browse

Mon Apr 29 02:29:35 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-April/125682.html

On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
>> On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>>
>>>    - should an enum item be selectable via __call__ instead of __getitem__
>>> (i.e. Seasons(3) is AUTUMN)
>
> Does anyone know why this is even an issue? Is this pure bike-shedding over the API, or are there
> technical reasons for choosing one over the other?

This is an issue because currently every other type* in Python creates (or selects ;) its instances via the call syntax:

   - bool(1)    # True
   - int('11')  # 11
   - str(var)   # whatever var had in it, now as a str

But one of the latest changes to flufl.enum was to take out the call syntax, and have only getitem syntax

   - Season('AUTUMN')  # raises an exception
   - Season['AUTUMN']  # Season.AUTUMN

Not only is this inconsistent with the rest of Python*, but it's going to be a PITA for data storage/retrieval:

     datastore = dbf.Table('storage.dbf', 'event_name C(50); date D; season SEASON')

     def retrieve_record(...):
         result = []
         for field_type, field_data in record:
             result.append(field_type(field_data))

vs.

     def retrieve_record(...):
         result = []
         for field_type, field_data in record:
             if isinstance(field_type, Enum):
                 result.append(field_type[field_data])
             else:
                 result.append(field_type(field_data))

Not being able to use call syntax on the Enum class unnecessarily complicates other code.

--
~Ethan~

* Please correct me if I'm wrong.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-April/125682.html below:

[Python-Dev] enum discussion: can someone please summarize open issues?