A RetroSearch Logo

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

Search Query:

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

[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, asEthan Furman ethan at stoneleaf.us
Tue Feb 26 00:28:37 CET 2013
On 02/25/2013 03:22 PM, Greg Ewing wrote:
> Ethan Furman wrote:
>> I must admit I find it mildly amusing (but a lot frustrating) that we are talk about /enumerations/ not needing to be
>> based on ints.  Checking out Merrian-Webster gives this:
>>
>> Definition of ENUMERATE
>> 1
>> : to ascertain the number of : count
>> 2
>> : to specify one after another : list
>
> It depends on what you mean by "based on ints". Pascal
> enums are using the second definition here: the values
> have ints associated with them, but are not themselves
> ints.
>
> There are really two different use cases. Sometimes you
> want to have values that are directly substitutable for ints;
> other times you would rather not, so as to catch mistakes
> more easily.

I agree.  I think whichever enum ends up in the stdlib should support both
types (and possibly a couple other variations).

--
~Ethan~
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4