Mailing List Archive: Python: Dev

a Constant addition to enum

Index | Next | Previous | View Threaded

ethan at stoneleaf

Aug 6, 2013, 1:42 PM

Post #1 of 4 (36 views)
Permalink

a Constant addition to enum

A question came up on stackoverflow asking about the Planet example and the need to have the constant G defined in the
method instead of at the class level:

http://stackoverflow.com/q/17911188/208880

Since methods and descriptors are immune to enumeration my proposed solution created a Constant descriptor that could be
used to keep class level constants at the class level. It's not complex, only about 7 lines. Should we have something
like that included in the enum module?

If we do include something like that, should it be constant, or should it be more like property? (The important
differences from property being that class access still returns the value, not the property itself, and setting the
class-level value changes the value but doesn't replace the property.)

--
~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

eliben at gmail

Aug 6, 2013, 2:36 PM

Post #2 of 4 (34 views)
Permalink

Re: a Constant addition to enum [In reply to]

On Tue, Aug 6, 2013 at 1:42 PM, Ethan Furman <ethan [at] stoneleaf> wrote:

> A question came up on stackoverflow asking about the Planet example and
> the need to have the constant G defined in the method instead of at the
> class level:
>
> http://stackoverflow.com/q/**17911188/208880<http://stackoverflow.com/q/17911188/208880>
>
> Since methods and descriptors are immune to enumeration my proposed
> solution created a Constant descriptor that could be used to keep class
> level constants at the class level. It's not complex, only about 7 lines.
> Should we have something like that included in the enum module?
>
> If we do include something like that, should it be constant, or should it
> be more like property? (The important differences from property being that
> class access still returns the value, not the property itself, and setting
> the class-level value changes the value but doesn't replace the property.)
>

Personally, I dislike all non-simple uses of Enums. One such use is adding
behavior to them. This can always be split to separate behavior from the
Enum itself, and I would prefer that. We went to great lengths to ensure
that things work in expected ways, but heaping additional features (even as
separate decorators) is just aggravating thiings. So -1 from me.

Finally, I suggest we exercise restraint in adding more capabilities to
enums in 3.4; enums are a new creature for Python and it will be extremely
useful to see them used in the wild for a while first. We can enhance them
in 3.5, but premature enhancement is IMHO much more likely to do harm than
good.

Eli

solipsis at pitrou

Aug 6, 2013, 2:45 PM

Post #3 of 4 (34 views)
Permalink

Re: a Constant addition to enum [In reply to]

On Tue, 6 Aug 2013 14:36:27 -0700
Eli Bendersky <eliben [at] gmail> wrote:
> On Tue, Aug 6, 2013 at 1:42 PM, Ethan Furman <ethan [at] stoneleaf> wrote:
>
> > A question came up on stackoverflow asking about the Planet example and
> > the need to have the constant G defined in the method instead of at the
> > class level:
> >
> > http://stackoverflow.com/q/**17911188/208880<http://stackoverflow.com/q/17911188/208880>
> >
> > Since methods and descriptors are immune to enumeration my proposed
> > solution created a Constant descriptor that could be used to keep class
> > level constants at the class level. It's not complex, only about 7 lines.
> > Should we have something like that included in the enum module?
> >
> > If we do include something like that, should it be constant, or should it
> > be more like property? (The important differences from property being that
> > class access still returns the value, not the property itself, and setting
> > the class-level value changes the value but doesn't replace the property.)
> >
>
> Personally, I dislike all non-simple uses of Enums. One such use is adding
> behavior to them. This can always be split to separate behavior from the
> Enum itself, and I would prefer that. We went to great lengths to ensure
> that things work in expected ways, but heaping additional features (even as
> separate decorators) is just aggravating thiings. So -1 from me.

Agreed. Also, putting constants inside Enum declarations is just
confusing.
(it doesn't help that the presented "use case" is the typical
schoolbook example that doesn't correspond to any real-world
situation, just like parsing Roman numbers and solving Hanoi tower
puzzles)

Regards

Antoine.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Aug 6, 2013, 10:05 PM

Post #4 of 4 (30 views)
Permalink

Re: a Constant addition to enum [In reply to]

On 7 August 2013 07:36, Eli Bendersky <eliben [at] gmail> wrote:
> On Tue, Aug 6, 2013 at 1:42 PM, Ethan Furman <ethan [at] stoneleaf> wrote:
>>
>> A question came up on stackoverflow asking about the Planet example and
>> the need to have the constant G defined in the method instead of at the
>> class level:
>>
>> http://stackoverflow.com/q/17911188/208880
>>
>> Since methods and descriptors are immune to enumeration my proposed
>> solution created a Constant descriptor that could be used to keep class
>> level constants at the class level. It's not complex, only about 7 lines.
>> Should we have something like that included in the enum module?
>>
>> If we do include something like that, should it be constant, or should it
>> be more like property? (The important differences from property being that
>> class access still returns the value, not the property itself, and setting
>> the class-level value changes the value but doesn't replace the property.)
>
>
> Personally, I dislike all non-simple uses of Enums. One such use is adding
> behavior to them. This can always be split to separate behavior from the
> Enum itself, and I would prefer that. We went to great lengths to ensure
> that things work in expected ways, but heaping additional features (even as
> separate decorators) is just aggravating thiings. So -1 from me.
>
> Finally, I suggest we exercise restraint in adding more capabilities to
> enums in 3.4; enums are a new creature for Python and it will be extremely
> useful to see them used in the wild for a while first. We can enhance them
> in 3.5, but premature enhancement is IMHO much more likely to do harm than
> good.

Agreed. I wouldn't be averse to taking those advanced examples out of
the docs, too.

Like metaclasses, you can do crazy things with enums. "Can" doesn't
mean "should", however. We've had a lot of success with metaclasses by
soft-pedalling them in the standard library, so people only explore
them when they *really* need them. I think we'd be well advised to
pursue a similar path with advanced Enum tricks.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads