Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 04/27/2013 08:59 PM, Greg Ewing wrote:
It's possible to make it work, I think. The __call__ method
of the metaclass is going to have to do something special
anyway, so that Planet(3) can look up and return an existing
instance instead of making a new one. And if it doesn't make
a new instance, it's not going to call the __init__ method.
It works beautifully! It's not even complicated because the metaclass __new__ uses object.__new__ to create the
instances, so EnumType.__call__ is /only/ called in cases like Planet(3), or Planet('EARTH').
Sweet!
--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] class name spaces inside an outer function
On 04/27/2013 09:20 PM, Guido van Rossum wrote: On Saturday, April 27, 2013, Greg Ewing wrote: class Planet(Enum): MERCURY = (3.303e+23, 2.4397e6) VENUS = (4.869e+24, 6.0518e6) EARTH = (5.976e+24, 6.37814e6) MARS= (6.421e+23, 3.3972e6) JUPITER = (1.9e+27, 7.1492e7) SATURN = (5.688e+26, 6.0268e7) URANUS = (8.686e+25, 2.5559e7) NEPTUNE = (1.024e+26, 2.4746e7) def __init__(self, mass, radius): self.mass = mass self.radius = radius If you want something like this, do you really have to inherit from Enum? To answer your question: Somewhere in the previous threads about enums a couple people had use-cases for an enum with extra attributes. So, while you don't /have/ to enherit from Enum, if Enum provides the basics of what you need, and you can extend it with the extra functionality that you need, why shouldn't you? (Not a rhetorical question -- I'm happy to learn something I don't know.) -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] enum discussion: can someone please summarize open issues?
Hi all, I've just read a few dozen enum-related emails, and there are so many more. I would like to form an opinion about the proposal(s), but I feel I don't know what the actual issues are anymore. In the past, somebody usually presented a summary of the issues so far, and that was a good point for late comers to get up to speed and weigh in. (It can be here or in the PEP.) It is also a good point to focus the discussion (which seems to have wandered quite far from sensible Pythonic design in places). Thanks in advance, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
Example enumeration: class Seasons(Enum): SPRING = 1 SUMMER = 2 AUTUMN = 3 WINTER = 4 days_in_year = 365 @property def avg_temp(self): return (75, 92, 66, 33)[int(self)+1] # enums are 1-based Definite Issues: - should enum items be of the type of the Enum class? (i.e. type(SPRING) is Seasons) - should an enum item be selectable via __call__ instead of __getitem__ (i.e. Seasons(3) is AUTUMN) - should days_in_year be enumerated? - should avg_temp be enumerated? - for the above two, how should they be included/excluded? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
My opinions added On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote: > Example enumeration: > > class Seasons(Enum): > SPRING = 1 > SUMMER = 2 > AUTUMN = 3 > WINTER = 4 > > days_in_year = 365 > > @property > def avg_temp(self): > return (75, 92, 66, 33)[int(self)+1] # enums are 1-based > > > Definite Issues: > > - should enum items be of the type of the Enum class? (i.e. type(SPRING) > is Seasons) IMO Yes. > - should an enum item be selectable via __call__ instead of __getitem__ > (i.e. Seasons(3) is AUTUMN) No opinion. > - should days_in_year be enumerated? Yes. (If you don't want it to be, and it's not a method/descriptor, move it out of the class.) > - should avg_temp be enumerated? IMO No. > - for the above two, how should they be included/excluded? IMO Everything should be enumerated except (a) things with a __get__() method (i.e. descriptors) (b) __dunder__ names Also, I believe there's still an issue on the order in which items are returned by iter(Seasons), but I don't know which way this is heading. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 04/28/2013 01:02 PM, Guido van Rossum wrote: My opinions added Mine also now added. Example enumeration: class Seasons(Enum): SPRING = 1 SUMMER = 2 AUTUMN = 3 WINTER = 4 days_in_year = 365 @property def avg_temp(self): return (75, 92, 66, 33)[int(self)+1] # enums are 1-based Definite Issues: - should enum items be of the type of the Enum class? (i.e. type(SPRING) is Seasons) IMO Yes. I agree. - should an enum item be selectable via __call__ instead of __getitem__ (i.e. Seasons(3) is AUTUMN) No opinion. I think the callable syntax should be supported for database integration and consistency with every (?) other type in Python. No opinion about the __getitem__ portion. - should days_in_year be enumerated? Yes. (If you don't want it to be, and it's not a method/descriptor, move it out of the class.) Making it a property to have it in the class certainly works for me. - should avg_temp be enumerated? IMO No. I agree. - for the above two, how should they be included/excluded? IMO Everything should be enumerated except (a) things with a __get__() method (i.e. descriptors) (b) __dunder__ names This also works for me. Also, I believe there's still an issue on the order in which items are returned by iter(Seasons), but I don't know which way this is heading. As somebody pointed out earlier, the only order which cannot be reconstructed after the fact is definition order (value order can be, lexical order can be, etc.). So my vote is to have the default iteration order be the original definition order, as any other desired order can be added to the class. -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] class name spaces inside an outer function
Guido van Rossum wrote: On Saturday, April 27, 2013, Greg Ewing wrote: class Planet(Enum): MERCURY = (3.303e+23, 2.4397e6) VENUS = (4.869e+24, 6.0518e6) EARTH = (5.976e+24, 6.37814e6) def __init__(self, mass, radius): self.mass = mass self.radius = radius If you want something like this, doyou really have to inherit from Enum? I suppose not, but the same could be said for cases where you want to add methods to enums, etc. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Sun, 28 Apr 2013 13:02:11 -0700 Guido van Rossum wrote: > > > - for the above two, how should they be included/excluded? > > IMO Everything should be enumerated except > (a) things with a __get__() method (i.e. descriptors) > (b) __dunder__ names I think it would be nice to define regular methods on enums. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 29 Apr 2013 07:32, "Antoine Pitrou" wrote: > > On Sun, 28 Apr 2013 13:02:11 -0700 > Guido van Rossum wrote: > > > > > - for the above two, how should they be included/excluded? > > > > IMO Everything should be enumerated except > > (a) things with a __get__() method (i.e. descriptors) > > (b) __dunder__ names > > I think it would be nice to define regular methods on enums. Functions are descriptors, so this rule already covers ordinary methods. The slight concern I have with making the duck typed exclusion only descriptors (rather than descriptors and callables) is that it means things like functools.partial objects will be treated as enum values rather than as static methods. OTOH, explicitly wrapping such callables in staticmethod should still work, so the simpler rule is probably better. Cheers, Nick. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Mon, 29 Apr 2013 08:28:34 +1000 Nick Coghlan wrote: > On 29 Apr 2013 07:32, "Antoine Pitrou" wrote: > > > > On Sun, 28 Apr 2013 13:02:11 -0700 > > Guido van Rossum wrote: > > > > > > > - for the above two, how should they be included/excluded? > > > > > > IMO Everything should be enumerated except > > > (a) things with a __get__() method (i.e. descriptors) > > > (b) __dunder__ names > > > > I think it would be nice to define regular methods on enums. > > Functions are descriptors, so this rule already covers ordinary methods. Oh, I had missed that. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 04/28/2013 02:29 PM, Antoine Pitrou wrote: On Sun, 28 Apr 2013 13:02:11 -0700 Guido van Rossum wrote: - for the above two, how should they be included/excluded? IMO Everything should be enumerated except (a) things with a __get__() method (i.e. descriptors) (b) __dunder__ names I think it would be nice to define regular methods on enums. No worries -- regular methods have a __get__. -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 29/04/13 06:02, Guido van Rossum wrote: My opinions added On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote: Definite Issues: - should enum items be of the type of the Enum class? (i.e. type(SPRING) is Seasons) IMO Yes. +1 - should an enum item be selectable via __call__ instead of __getitem__ (i.e. Seasons(3) is AUTUMN) No opinion. 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? - should days_in_year be enumerated? Yes. (If you don't want it to be, and it's not a method/descriptor, move it out of the class.) +1, but see below. - should avg_temp be enumerated? IMO No. - for the above two, how should they be included/excluded? IMO Everything should be enumerated except (a) things with a __get__() method (i.e. descriptors) (b) __dunder__ names +1 on excluding dunder names. +0 on excluding things with __get__. I have also suggested that that the enum package provide a decorator which can be used to explicitly flag values to *not* be turned into enum values. See here: http://mail.python.org/pipermail/python-dev/2013-April/125641.html Even if the Enum class doesn't support this feature, I ask that it be written in such a way that a subclass could add it (i.e. please expose a public method for deciding what to exclude). -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Sun, Apr 28, 2013 at 7:37 PM, Steven D'Aprano wrote: > I have also suggested that that the enum package provide a decorator > which can be used to explicitly flag values to *not* be turned into > enum values. See here: > > http://mail.python.org/pipermail/python-dev/2013-April/125641.html In that example, 'food = property(lambda:"skip")' would work in a pinch. (Granted, it wouldn't be a *class* attribute, but you can make a class attribute by assiging it after class creation is completed.) And if you want to make your enum instances callable, ISTM the right (or at least the One Obvious) way to do it is to add a __call__ method to the class. > Even if the Enum class doesn't support this feature, I ask that it be > written in such a way that a subclass could add it (i.e. please expose > a public method for deciding what to exclude). Since you can exclude anything by it having a __get__ method, or include it by making it *not* have a __get__ method, I'm not sure what use case you're actually looking for. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 4/28/2013 4:37 PM, Steven D'Aprano wrote: I have also suggested that that the enum package provide a decorator which can be used to explicitly flag values to *not* be turned into enum values. See here: http://mail.python.org/pipermail/python-dev/2013-April/125641.html Even if the Enum class doesn't support this feature, I ask that it be written in such a way that a subclass could add it (i.e. please expose a public method for deciding what to exclude). That last comment is very interesting to me... I think it would be good if the enum implementation doesn't prevent the creation of a subclass of integer enumerations which can be extended so that when arithmetic is done on them, that new enumeration values and names can be added to the collection (think flag fields). The add ones might have names that do not follow the rules for identifiers. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman 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.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman 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
I think that's a red herring, because you're comparing the use of the object
constructor with look-up by name.
Seasons[3] should not be considered as constructing an instance from argument
3, but a reverse lookup from raw value to enum value. Hence the use of
__getitem__ rather than __call__.
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
I'm not sure whether flufl.enums support creating additional instances after
the event, but if it did, I would expect that I could say Season('WET') to get
a new instance. I am indifferent to whether or not Season('AUTUMN') should
return the existing AUTUMN enum value.
I think that I lean very slightly to these rules:
- Season(x) constructs new instances. If x is already a Season enum, it returns
x; otherwise if x is a value already used for a Season enum, it raises.
- Season[x] looks up existing instances, and raises if x is not already a
Season value.
but only very slightly.
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))
Instead of having field_type be Season, couldn't you make it Season.__getitem__
?
--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
Steven D'Aprano writes: > >>- should an enum item be selectable via __call__ instead of __getitem__ > >> (i.e. Seasons(3) is AUTUMN) > > > > No opinion. > > 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? Ethan thinks that "Seasons(3)" is a typecast, not an access into a mapping (which would be better expressed by "Seasons[3]"). Ie, the inverse of "int(AUTUMN)". This is consistent with the "AUTUMN is-a Seasons" position that Ethan and Guido take. It's inconsistent with the "AUTUMN is-a Seasons_VALUE" implementation of Flufl.Enum. @Ethan: I have real trouble sympathizing with your point of view because you consistently pluralize your Enum names. AUTUMN *is not* a SeasonZZ, it is an element of the *collection* Seasons. OTOH, AUTUMN *is* a Season (look Ma, no ZZ!) I wonder if you might not get more sympathy from Guido if you named your Enums with the singular form. Note that for some reason I don't have the same problem if Barry names an Enum "Season" (no ZZ!) I don't know why, maybe because the semantics of type is to define a collection (which in English is invariably denoted by the plural of the type name), so there's implicitly a plural there. But I'm not confident in that psychoanalysis. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 04/28/2013 07:10 PM, Stephen J. Turnbull wrote: @Ethan: I have real trouble sympathizing with your point of view because you consistently pluralize your Enum names. AUTUMN *is not* a SeasonZZ, it is an element of the *collection* Seasons. OTOH, AUTUMN *is* a Season (look Ma, no ZZ!) I would hope that you would pay more attention to my arguments and rationale than to poorly chosen names. The way English does things is not the only way things are done. As it happens, I agree with you, and changed (and will change) all mention of Seasons to Season, and WeekDays to WeekDay, etc., etc., in my responses. -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 04/28/2013 06:52 PM, Steven D'Aprano wrote:
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Season(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
I think that's a red herring, because you're comparing the use of the object
constructor with look-up by name.
int, float, and bool all have object constructors that take the given string and return a matching instance; int /may/
return a pre-existing instance, bool /will/ return a pre-existing instance.
As I've stated before, 'bool's are the closest existing data type to enums, in that bools use the object constructor to
convert the incoming parameter to an existing bool instance, of which there will only ever be two.
bool(9) is bool('maybe') is bool(True) is True
and similarly, Enum behavior /should be/ (in my opinion ;)
Season.AUTUMN is Season('AUTUMN') is Season(3)
Like it or not, when you write `class Season(Enum)` a new *type* is created called Season, and Season(x) should either
return a Season instance that matches x or raise. Having a match and raising anyway just doesn't seem to me to be the
Python Way.
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
I'm not sure whether flufl.enums support creating additional instances after
the event, but if it did, I would expect
that I could say Season('WET') to get a new instance. I am indifferent to
whether or not Season('AUTUMN') should return
the existing AUTUMN enum value.
Adding more enumerators after the fact should not be supported; there is subclassing for that. Not worth actively
preventing, but not encouraged.
--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan wrote:
> Functions are descriptors, so this rule already covers ordinary methods. The
> slight concern I have with making the duck typed exclusion only descriptors
> (rather than descriptors and callables) is that it means things like
> functools.partial objects will be treated as enum values rather than as
> static methods. OTOH, explicitly wrapping such callables in staticmethod
> should still work, so the simpler rule is probably better.
I think the practice of using callables (other than possibly decorated
functions) as global variables is confusing at best, even in a
non-enum class, since few people will be able to predict whether they
will get the instance passed or not. So I think the rule looking only
for descriptors is superior.
There has been a whole lot more discussion in this thread. I am now
asking everyone to stop bikeshedding, even if you think *your* point
isn't bikeshedding -- the cacophony makes it impossible to hear
anyone.
There are a few more issues on which I'd like to pronounce.
1. The order in which iter(Color) should produce the items. The
argument has been made that definition order is the only order that is
not easily reconstructed, and I agree. So let's use definition order,
even if that means it can't be implemented in Python 2.
2. Whether Color(x) should be allowed, and what it should mean. Taking
the example of bool, it should return an existing enum if the argument
is either a Color or one of the values used for Color items (choosing
one somehow if there are multiple with the same value -- it doesn't
matter which one), and raise an exception if the argument is neither.
E.g.:
class Color(Enum):
red = 1
white = 2
blue = 3
x = Color.red
assert Color(x) is Color.red
assert Color(1) is Color.red
Color(42) # raises
(2a. We could also allow Color('red') is Color.red, but that could be
confusing, and we can already do that with getattr(Color, 'red'), and
bool('False') doesn't return False anyway, so let's not do that.)
(2b. Let's not hypergeneralize and try to make bool and enums
completely alike. I see no advantage to adding bool.True and
bool.False, nor in making enums "final" classes, or giving a meaning
to iter(bool). Type bool is its own thing, but that doesn't mean enums
can't emulate aspects of it.)
Together with my pronouncements earlier in this thread I am hoping
that Eli and Barry will update the PEP and implementation (let's give
them a week) and everyone else will quiet down. I realize we're
deviating further from flufl.enum than our initial hope, but I think
the outcome is better.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
Ethan Furman writes: > I would hope that you would pay more attention to my arguments and > rationale than to poorly chosen names. I do. Nevertheless, it requires conscious effort. It's quite appropriate for you to ask that of me, but ... do you think you're doing Python any good to ask more effort of Guido? (Assuming he needs it, of course -- I'm just conjecturing that the form of your examples may make the whole thing less persuasive for him. But of course he has advantages, being Dutch and all :-) > The way English does things is not the only way things are done. I am nearly-native fluent in Japanese[1] -- I know better than most people just how differently things *can* be done. That doesn't help much with the effort gradient in English, though. Footnotes: [1] Even my 15-year-old daughter admits that, so it must be true. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
[re-directing back to python-dev]
On 04/28/2013 08:42 PM, Davis Silverman wrote:
as a not super experienced python developer, when i see Season('AUTUMN') it
looks like im creating an a Season object. I
understand your resoning, that it acts like a boolean singleton, however, i
feel it would confuse many, and isn't worth
it. From what i see, its meant to be a lookup sort of thing, but it doesnt
really feel like one.
Or am i completely wrong about something?
As far as you are concerned, you are creating a Season object. That it happens to be a pre-existing Season object is an
implementation detail, and the whole thing would work just as well if it did indeed create a brand new object (you
couldn't use `is` then, but in general `is` shouldn't be used anyway and I see no reason why `is` should be encouraged
with Enums; use `==`).
Two examples:
- the first few integers (up to 256 now, I think) are pre-created by the interpreter; when you do `int('7')` you are
not getting a brand-new, never before used, integer 7 object, you're getting a cached integer 7 object.
- all booleans (yup, both of them ;) are pre-created; when you ask for a True or a False, you are not getting a brand
new one.
Since `is` is discouraged, both of those cases could go the other way (always creating a brand new object) and properly
written programs would continue to run just fine -- slower, but fine.
Enums are the same: they could return brand new instances every time, and programs using `==` to compare will keep on
working. That they don't is an implementation detail.
The real guarantee with enums is that once you have one created you'll only
ever see the original values; so
class Last(Enum):
X = 1
Y = 2
Z = 3
will only have three possible elements, X, Y, and Z, and X will always have the value of 1, Y will always have the vale
of 2, and Z will always have the value of 3. If you try and get `Last("W")` you'll trigger an exception, just like you
do with `int("house")`.
--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 4/28/2013 9:09 PM, Guido van Rossum wrote:
(2a. We could also allow Color('red') is Color.red, but that could be
confusing, and we can already do that with getattr(Color, 'red'), and
bool('False') doesn't return False anyway, so let's not do that.)
Glad you made this pronouncement in this way, because otherwise there
would be ambiguity in the case:
class Color(Enum):
red = 'white'
white = 'blue'
blue = 'red'
although that would no doubt drive the programmers batty anyway... but there
may be instances where code is generated that could produce something
ambiguous, even though this example is atrocious.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Sunday, April 28, 2013, Ethan Furman wrote: > > Enums are the same: they could return brand new instances every time, and > programs using `==` to compare will keep on working. That they don't is an > implementation detail. > Whoa. In this case the identity property is not justban implementation issue, it is part of the spec. Same for bool. (But == works too.) --Guido -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
Am 28.04.2013 22:36, schrieb Ethan Furman: >>> Example enumeration: >>> >>> class Seasons(Enum): SPRING = 1 SUMMER = 2 AUTUMN = 3 WINTER = 4 >>> >>> days_in_year = 365 >>> >>> @property def avg_temp(self): return (75, 92, 66, 33)[int(self)+1] # >>> enums are 1-based >>> >>> >>> Definite Issues: >>> >>> - should enum items be of the type of the Enum class? (i.e. type(SPRING) >>> is Seasons) >> >> IMO Yes. > > I agree. > >>> - should an enum item be selectable via __call__ instead of __getitem__ >>> (i.e. Seasons(3) is AUTUMN) >> >> No opinion. > > I think the callable syntax should be supported for database integration and > consistency with every (?) other type in Python. No opinion about the > __getitem__ portion. > > >>> - should days_in_year be enumerated? >> >> Yes. (If you don't want it to be, and it's not a method/descriptor, move it >> out of the class.) > > Making it a property to have it in the class certainly works for me. > > >>> - should avg_temp be enumerated? >> >> IMO No. > > I agree. > > >>> - for the above two, how should they be included/excluded? >> >> IMO Everything should be enumerated except (a) things with a __get__() >> method (i.e. descriptors) (b) __dunder__ names > > This also works for me. > > >> Also, I believe there's still an issue on the order in which items are >> returned by iter(Seasons), but I don't know which way this is heading. > > As somebody pointed out earlier, the only order which cannot be reconstructed > after the fact is definition order (value order can be, lexical order can be, > etc.). So my vote is to have the default iteration order be the original > definition order, as any other desired order can be added to the class. Thanks for the summary, that was very helpful. I find myself agreeing with every one of your opinions. Good job :) Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Sun, Apr 28, 2013 at 09:02:15PM -0700, Ethan Furman wrote:
> Two examples:
>
> - the first few integers (up to 256 now, I think) are pre-created by the
> interpreter; when you do `int('7')` you are not getting a brand-new, never
> before used, integer 7 object, you're getting a cached integer 7 object.
>
> - all booleans (yup, both of them ;) are pre-created; when you ask for a
> True or a False, you are not getting a brand new one.
>
> Since `is` is discouraged, both of those cases could go the other way
> (always creating a brand new object) and properly written programs would
> continue to run just fine -- slower, but fine.
>
> Enums are the same: they could return brand new instances every time, and
> programs using `==` to compare will keep on working. That they don't is an
> implementation detail.
That's not how I understand it. I expected that the correct way to use
enums is with identity checks:
if arg is Season.SUMMER:
handle_summer()
At least, that's how I'm used to dealing with sentinels or pseudo-enums
created with object(), and I just expected it to carry over to actual
enums. Should I reset my thinking and use == with flufl.enums?
--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
Steven D'Aprano wrote:
On 29/04/13 10:29, Ethan Furman wrote:
- bool(1)# True
- int('11') # 11
- str(var) # whatever var had in it, now as a str
I think that's a red herring, because you're comparing the use of the
object constructor with look-up by name.
How does what bool() is doing differ from a lookup?
It's not constructing a new instance. Neither is
int() in the cases where the argument is in the
range of values that it caches.
More generally, the built-in types can be thought
of as coercion functions -- they take an argument
and return some related value from the type's
repertoire. Whether they do that by constructing
a new object or not is an implementation detail.
--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 28Apr2013 19:46, Ethan Furman wrote:
| int, float, and bool all have object constructors that take the
| given string and return a matching instance; int /may/ return a
| pre-existing instance, bool /will/ return a pre-existing instance.
I think Guido's already pointed out this:
>>> bool('False')
True
| As I've stated before, 'bool's are the closest existing data type to
| enums, in that bools use the object constructor to convert the
| incoming parameter to an existing bool instance, of which there will
| only ever be two.
|
| bool(9) is bool('maybe') is bool(True) is True
|
| and similarly, Enum behavior /should be/ (in my opinion ;)
|
| Season.AUTUMN is Season('AUTUMN') is Season(3)
I think that would be _efficient_, but as an outside user I wouldn't
necessarily expect it unless I'd ready the spec very closely and
the spec was explicit about it.
Coming from (in the fairly distant past) a C background, I naively
think of enums as nicely named ordinals of some kind and expect to
compare them with ==, not "is".
If you want to guarantee "is", be my guest though.
I don't know how that might make things go with some hypothetical subclass
with many many and extensible enum values.
| Like it or not, when you write `class Season(Enum)` a new *type* is
| created called Season, and Season(x) should either return a Season
| instance that matches x or raise. Having a match and raising anyway
| just doesn't seem to me to be the Python Way.
I'm +1 on all of this.
[...]
| >I'm not sure whether flufl.enums support creating additional instances after
the event, but if it did, I would expect
| >that I could say Season('WET') to get a new instance. I am indifferent to
whether or not Season('AUTUMN') should return
| >the existing AUTUMN enum value.
|
| Adding more enumerators after the fact should not be supported;
| there is subclassing for that. Not worth actively preventing, but
| not encouraged.
I'd go a bit further here: I'd take this final sentence as being
-0 on preventing adding more enumerals(?), whereas I'm a solid -1
on preventing it. By all means not actively support it, but very
against doing things that make it hard for a subclass to support
it.
Just 2c,
--
Would you remember a one-line .sig? - Paul Thompson, [email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Sun, 28 Apr 2013 17:29:35 -0700
Ethan Furman wrote:
>
> 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))
I've never seen any kind of "data retrieval" which works like that.
Would you care to explain us the context?
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
