On 23/11/2010 15:01, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 08:52 -0600, Benjamin Peterson a écrit :
2010/11/23 Antoine Pitrou<solip...@pitrou.net>:
On Tue, 23 Nov 2010 14:24:18 +0000
Michael Foord<fuzzy...@voidspace.org.uk> wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old ones (including having the same underlying
value and comparing equal to it).
In many cases it is *likely* that subclassing int is a better way of
achieving that. Actually looking through the standard library to
evaluate it is the only way of confirming that.
Another API, that reduces the duplication of creating the enum and
setting the names, could be something like:
make_enums("Names", "NAME_ONE NAME_TWO NAME_THREE", base_type=int,
module=__name__)
Using __name__ we can set the module globals in the call to make_enums.
I don't understand why people insist on calling that an "enum". enum is
a C legacy and it doesn't bring anything useful as I can tell. Instead,
just assign the values explicitly.
The concept of a "enumeration" of values is still useful outside its
stunted C incarnation.
Well, it is easy to assign range(N) to a tuple of names when desired. I
don't think an automatically-enumerating constant generator is needed.
Right, and that is current practise. It has the disadvantage (that you
seemed to acknowledge) that when debugging the integer values are seen
instead of something with a useful repr.
Having a *simple* class (and API to create them) that produces named
constants with a useful repr, is what we are discussing, and that seems
awfully like an enum (in the general sense not in a C specific sense).
For backwards compatibility these constants, where they replace integer
constants, would need to be integer subclasses with the same behaviour.
Like the Qt example you appreciated so much. ;-)
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is best), of which I prefer
the latter:
SOME_CONST = Constant('SOME_CONST', 1)
OTHER_CONST = Constant('OTHER_CONST', 2)
or:
Constants = make_constants('Constants', 'SOME_CONST OTHER_CONST', start=1)
SOME_CONST = Constants.SOME_CONST
OTHER_CONST = Constants.OTHER_CONST
(Well, there is a third option that takes __name__ and sets the
constants in the module automagically. I can understand why people would
dislike that though.)
All the best,
Michael Foord
Michael
Regards
Antoine.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
