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-April/125639.html below:

[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard libraryGuido van Rossum guido at python.org
Sat Apr 27 19:35:43 CEST 2013
On Sat, Apr 27, 2013 at 10:04 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> While this will certainly work, it means you can't have class variables that
> happen to be the same type as the enum -- so no int in an IntEnum, for
> example.
>
> The solution I like best is the helper class (called, originally enough,
> enum), and only those items get transformed:
>
> class Planet(IntEnum):
>     MERCURY = enum(1)
>     VENUS = enum(2)
>     EARTH = enum(3)
>     rough_pi = 3     # not transformed

If this means that the most plain vanilla enum definition still has to
use the enum(i) notation, I'm against it. Why do you want rough_pi to
be a class variable anyway? The whole point of an enum is that it's
*not* a kitchen sink class. An enum for the planets will need other
support code that doesn't live in the enum class -- it shouldn't be
considered a general scope for miscellanea. (TBH, I think that using
classes to scope variables is mostly misguided anyway -- the standard
mechanism for scoping is the module.)

--
--Guido van Rossum (python.org/~guido)
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