Having had some time to think about this problem space, here's my take on it:
===
The problem-space can be broken down into four layers:
1. the items
2. interaction between grouped items
3. the grouping itself
4. conversion from a class to a group
Here are *potential
Hi, offering my DKK 0.50 on the subject. I've used an in-house enum
type for the better part of a decade - put up at
http://unicollect.dk/download/oss/dc_enum.zip for inspiration.
I'm partial to an int subclass, or at least something very int-like,
because wrapping C libraries is such a major use
On Wed, Feb 27, 2013 at 8:30 AM, Antoine Pitrou wrote:
> I don't think extra-strong typing of constants is really useful in
> practice; it smells a bit like private methods to me.
I think checking that a value comes from a particular enum *is* a degree of
hand-holding. For libraries or framework
Le Wed, 27 Feb 2013 12:33:35 +0900,
"Stephen J. Turnbull" a écrit :
>
> As far as I can see, what you (Antoine) want is an identifier with a
> constant value, no more and no less. Grouping into an enum is merely
> a lexical convention, since you are happy to compare enums of
> different enum cla
Greg Ewing writes:
> Stephen J. Turnbull wrote:
> > Worse for me, most of the applications I have, I'd like the enumerator
> > identifiers to be both string-valued and int-valued: the int used to
> > index into Python sequences, and the string used in formatting SQL.
>
> Is the string value
Stephen J. Turnbull wrote:
Worse for me, most of the applications I have, I'd like the enumerator
identifiers to be both string-valued and int-valued: the int used to
index into Python sequences, and the string used in formatting SQL.
Is the string value required the same as the name used in
Py
Antoine Pitrou writes:
> On Tue, 26 Feb 2013 08:03:40 -0800
> Ethan Furman wrote:
> > I'm beginning to see why enums as a class has not yet been added
> > to Python. We don't want to complicate the language with too
> > many choices, yet there is no One Obvious Enum to fit the wide
> > vari
Ethan Furman writes:
> Ah, okay. Although, going with the first definition -- "ascertain
> the number of" -- I still maintain that the number is equally
> important, otherwise it could be a simple set.
Of course "number" is central to counting -- but you can count a set
of objects that have n
On Feb 26, 2013, at 5:25 AM, Eli Bendersky wrote:
> Glyph, thanks for the input. I mentioned Twisted because in its code I found
> a number of places with simple string enumerations used to represent state. I
> was not aware of twisted.python.constants, but it doesn't appear that this
> module
On 02/26/2013 03:26 PM, Greg Ewing wrote:
Ethan Furman wrote:
In the first three examples the data in quotes is the doc string; in examples
4 and 5 the RHS is the actual value assigned.
What if you want to assign both values and docstrings?
Let the bike shedding begin, eh? ;)
It could be a
Ethan Furman wrote:
In the first three examples the data in quotes is the doc string; in
examples 4 and 5 the RHS is the actual value assigned.
What if you want to assign both values and docstrings?
--
Greg
___
Python-Dev mailing list
Python-Dev@pyt
On 02/26/2013 12:52 PM, Tim Delaney wrote:
On 27 February 2013 01:50, Terry Reedy mailto:tjre...@udel.edu>> wrote:
We should NOT knowingly re-introduce the same problem again! If color and
animal are isolated from each other, they
should each be isolated from everything, including int.
FWIW t
Terry Reedy wrote:
(The
non-reflexivity of NAN is a different issue, but NANs are intentionally
insane.)
Yes, the non-transitivity in that case only applies to
one very special value. We're talking about making
comparison non-transitive for *all* values of the
types involved, which is a whole
On 27 February 2013 01:50, Terry Reedy wrote:
> On 2/25/2013 12:35 PM, Ethan Furman wrote:
>
> But this I don't, and in both mine, Ted's, and Alex's versions enums
>> from different groups do not compare equal, regardless of the underlying
>> value. Of course, this does have the potential probl
On 02/26/2013 11:17 AM, Antoine Pitrou wrote:
On Tue, 26 Feb 2013 08:03:40 -0800
Ethan Furman wrote:
I'm beginning to see why enums as a class has not yet been added to Python. We
don't want to complicate the language
with too many choices, yet there is no One Obvious Enum to fit the wide var
On Tue, 26 Feb 2013 08:03:40 -0800
Ethan Furman wrote:
> I'm beginning to see why enums as a class has not yet been added to Python.
> We don't want to complicate the language
> with too many choices, yet there is no One Obvious Enum to fit the wide
> variety of use-cases:
>
>- named int
On Wed, Feb 27, 2013 at 2:03 AM, Ethan Furman wrote:
> I'm beginning to see why enums as a class has not yet been added to Python.
> We don't want to complicate the language with too many choices, yet there is
> no One Obvious Enum to fit the wide variety of use-cases:
>
> - named int enums (ht
On 02/26/2013 01:29 AM, Stephen J. Turnbull wrote:
Ethan Furman writes:
Stephen J. Turnbull wrote:
Note that in both counting and listing the object of the
operation is not an element. It is a set, and set membership is
the most important aspect of the elements for that purpose.
No, it isn't
On 02/26/2013 07:01 AM, Terry Reedy wrote:
On 2/25/2013 6:53 PM, Greg Ewing wrote:
The currently suggested solution to that seems to be to
make comparison non-transitive, so that Colors.green == 1
and Animals.bee == 1 but Colors.green != Animals.bee.
And then hope that this does not create a qua
On Wed, Feb 27, 2013 at 1:09 AM, Terry Reedy wrote:
> On 2/25/2013 2:48 PM, Antoine Pitrou wrote:
>>
>> On Mon, 25 Feb 2013 11:34:35 -0800
>> Ethan Furman wrote:
>>>
>>> Antoine, question for you:
>>>
>>> Do you think enums from different groupings should compare equal?
>>
>>
>> Equality should b
On 2/25/2013 2:48 PM, Antoine Pitrou wrote:
On Mon, 25 Feb 2013 11:34:35 -0800
Ethan Furman wrote:
Antoine, question for you:
Do you think enums from different groupings should compare equal?
Equality should be mostly transitive so, yes, I think they should.
Or if they do not, then they sh
On 2/25/2013 6:53 PM, Greg Ewing wrote:
Barry Warsaw wrote:
>>> Colors = make('Colors', 'red green blue'.split())
>>> Animals = make('Animals', 'ant bee cat'.split())
>>> Colors.green == Animals.bee
The currently suggested solution to that seems to be to
make comparison non-transit
On 2/25/2013 12:35 PM, Ethan Furman wrote:
But this I don't, and in both mine, Ted's, and Alex's versions enums
from different groups do not compare equal, regardless of the underlying
value. Of course, this does have the potential problem of `green == 1
== bee` but not `green == bee` which wou
On Mon, Feb 25, 2013 at 3:17 PM, Glyph wrote:
>
> On Feb 25, 2013, at 12:32 PM, Barry Warsaw wrote:
>
> Dumb question, but are flufl.enums ordered? That's also an important use
> case.
>
>
> Kind of. Ordered comparisons are explicitly not supported, but iteration
> over
> the Enum is guarantee
Ethan Furman writes:
> sjt wrote:
> > Note that in both counting and listing the object of the
> > operation is not an element. It is a set, and set membership is
> > the most important aspect of the elements for that purpose.
>
> No, it isn't. It may be in some cases.
I'm referring o
On 02/25/2013 07:46 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> Again:
Repeating yourself doesn't help make the case. It does, however,
encourage me to reply.
Good! For a while I felt like I was talking to myself! ;)
> Definition of ENUMERATE
> 1 : to ascertain the numbe
Ethan Furman writes:
> Again:
Repeating yourself doesn't help make the case. It does, however,
encourage me to reply.
> Definition of ENUMERATE
> 1 : to ascertain the number of : count
> 2 : to specify one after another : list
You say you need the value as an integer; when you evaluate, yo
On Feb 26, 2013, at 10:04 AM, Tim Delaney wrote:
>You're starting to tread in an area that I investigated, did an
>implementation of, and then started moving away from due to a different
>approach (delegating to the methods in the owning Enum class when accessing
>EnumValue attribtues).
At first
Barry Warsaw wrote:
>>> Colors = make('Colors', 'red green blue'.split())
>>> Animals = make('Animals', 'ant bee cat'.split())
>>> Colors.green == Animals.bee
The currently suggested solution to that seems to be to
make comparison non-transitive, so that Colors.green == 1
and Animal
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 :
On 02/25/2013 09:35 AM, Ethan Furman wrote:
But this I don't, and in both mine, Ted's, and Alex's versions [. . .]
My sincerest apologies to Tim Delaney (aka 'Ted') for messing up his name.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
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 : l
On Feb 25, 2013, at 12:32 PM, Barry Warsaw wrote:
>> Dumb question, but are flufl.enums ordered? That's also an important use
>> case.
>
> Kind of. Ordered comparisons are explicitly not supported, but iteration over
> the Enum is guaranteed to be returned in int-value order.
Sorry to jump i
On 26 February 2013 07:32, Barry Warsaw wrote:
> One thing I've been thinking about is allowing you to override the
> EnumValue
> class that the metaclass uses. In that case, if you really wanted ordered
> comparisons, you could override __lt__() and friends in a custom enum-value
> class. I ha
On Feb 25, 2013, at 10:25 AM, Ethan Furman wrote:
>Hey, I think I just had a light-bulb moment: have the enum implement
>__index__ -- that will solve my use-case of using them for list indices.
They don't currently, but I think it's reasonable, given that they already
support __int__.
https://bu
On Mon, 25 Feb 2013 11:34:35 -0800
Ethan Furman wrote:
> Antoine, question for you:
>
> Do you think enums from different groupings should compare equal?
Equality should be mostly transitive so, yes, I think they should.
Regards
Antoine.
___
Python
Antoine, question for you:
Do you think enums from different groupings should compare equal?
If no, how would you propose to handle the following:
8<
--> import yaenum
--> class Color(yaenum.Enum):
... black
...
On 02/25/2013 10:49 AM, Antoine Pitrou wrote:
On Mon, 25 Feb 2013 09:03:06 -0800
Eli Bendersky wrote:
"DOG" > "CAT" invokes lexicographical comparison between two strings, a
well-defined and sensical operations. It simply means that in a sorted list
of strings, "CAT" will come before "DOG". Th
On Mon, 25 Feb 2013 13:05:02 -0500
Barry Warsaw wrote:
>
> Maybe. I don't think a stdlib solution has to meet *all* needs. I think
> named values plus int-interoperable enums will solve almost all use cases.
Being int-interoperable without comparing with ints is completely
bonkers.
Regards
A
On Mon, 25 Feb 2013 09:03:06 -0800
Eli Bendersky wrote:
>
> "DOG" > "CAT" invokes lexicographical comparison between two strings, a
> well-defined and sensical operations. It simply means that in a sorted list
> of strings, "CAT" will come before "DOG". This is different from an
> enumeration tha
On 02/25/2013 10:05 AM, Barry Warsaw wrote:
On Feb 25, 2013, at 09:35 AM, Ethan Furman wrote:
>>> Colors = make('Colors', 'red green blue'.split())
>>> Animals = make('Animals', 'ant bee cat'.split())
>>> Colors.green == Animals.bee
But this I don't, and in both mine, Ted's,
On Feb 25, 2013, at 09:35 AM, Ethan Furman wrote:
>> >>> Colors = make('Colors', 'red green blue'.split())
>> >>> Animals = make('Animals', 'ant bee cat'.split())
>> >>> Colors.green == Animals.bee
>
>But this I don't, and in both mine, Ted's, and Alex's versions enums from
>differe
On 02/25/2013 08:37 AM, Barry Warsaw wrote:
On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:
And if, in those places, the enums were based on ints (or strings), would it
hurt you? Because in the places where I, as well as many others, use enums
we *need* the int portion; and having to wrap th
On 02/25/2013 08:44 AM, Skip Montanaro wrote:
Besides "we just don't need them int-based in these use-cases" what are the
reasons for the strong desire to have them be valueless?
Not sure about other people, but piggybacking off C semantics, while
convenient, reflects the limitations of the C i
On Feb 25, 2013, at 05:19 PM, MRAB wrote:
>Would we be doing either of those? Surely we would be using a dict
>instead, and what does a dict use, identity or equality?
It's just a contrived example for email brevity. In my real world examples,
the code inside the conditions can be much more comp
On 2013-02-25 16:37, Barry Warsaw wrote:
On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:
And if, in those places, the enums were based on ints (or strings), would it
hurt you? Because in the places where I, as well as many others, use enums
we *need* the int portion; and having to wrap the e
On Mon, 25 Feb 2013 09:03:06 -0800, Eli Bendersky wrote:
> On Mon, Feb 25, 2013 at 8:56 AM, Antoine Pitrou wrote:
>
> > Le Mon, 25 Feb 2013 10:44:33 -0600,
> > Skip Montanaro a écrit :
> > > > Besides "we just don't need them int-based in these use-cases" what
> > > > are the reasons for the s
On Mon, Feb 25, 2013 at 8:56 AM, Antoine Pitrou wrote:
> Le Mon, 25 Feb 2013 10:44:33 -0600,
> Skip Montanaro a écrit :
> > > Besides "we just don't need them int-based in these use-cases" what
> > > are the reasons for the strong desire to have them be valueless?
> >
> > Not sure about other pe
Le Mon, 25 Feb 2013 10:44:33 -0600,
Skip Montanaro a écrit :
> > Besides "we just don't need them int-based in these use-cases" what
> > are the reasons for the strong desire to have them be valueless?
>
> Not sure about other people, but piggybacking off C semantics, while
> convenient, reflects
> Besides "we just don't need them int-based in these use-cases" what are the
> reasons for the strong desire to have them be valueless?
Not sure about other people, but piggybacking off C semantics, while
convenient, reflects the limitations of the C implementation more than
anything else. An en
Le Mon, 25 Feb 2013 11:37:29 -0500,
Barry Warsaw a écrit :
> On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:
>
> >And if, in those places, the enums were based on ints (or strings),
> >would it hurt you? Because in the places where I, as well as many
> >others, use enums we *need* the int port
On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:
>And if, in those places, the enums were based on ints (or strings), would it
>hurt you? Because in the places where I, as well as many others, use enums
>we *need* the int portion; and having to wrap the enum in an int() call is
>seven extra keys
I've stated my reasons for why enums should be int based, and some of the
problems with having them not be int-based.
Besides "we just don't need them int-based in these use-cases" what are the reasons for the strong desire to have them
be valueless?
--
~Ethan~
___
On Mon, 25 Feb 2013 07:12:03 -0800, 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 o
Le Mon, 25 Feb 2013 06:45:27 -0800,
Eli Bendersky a écrit :
> For preparing the draft PEP I ran through some stdlib, Twisted and
> personal code and there are *tons* of places that just need a simple
> enum for some sort of "state", meaningful return value, or similar.
There are also *tons* of p
On Feb 26, 2013, at 01:22 AM, Nick Coghlan wrote:
>I don't think we need true constants - labelled values should suffice
>for easier to debug magic numbers.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
On Tue, Feb 26, 2013 at 12:53 AM, Skip Montanaro wrote:
>>> If it was just once or twice, sure, but I use them as names for ints,
>>> which means I use them as ints, which means I would have a boat load of
>>> int() calls.
>>
>>
>> Personally I don't see "name for ints" as being the main use case
On 02/25/2013 06:45 AM, Eli Bendersky wrote:
2) When you do, wrapping the item in int() doesn't seem too bad to me.
If it was just once or twice, sure, but I use them as names for ints, which
means I use them as ints, which means I
would have a boat load of int() calls.
Pers
>> If it was just once or twice, sure, but I use them as names for ints,
>> which means I use them as ints, which means I would have a boat load of
>> int() calls.
>
>
> Personally I don't see "name for ints" as being the main use case for enums.
Ethan seems to have a use case, even if it is using
> 2) When you do, wrapping the item in int() doesn't seem too bad to me.
>>
>
> If it was just once or twice, sure, but I use them as names for ints,
> which means I use them as ints, which means I would have a boat load of
> int() calls.
>
Personally I don't see "name for ints" as being the main
On 02/24/2013 08:14 PM, Barry Warsaw wrote:
On Feb 24, 2013, at 07:32 PM, Ethan Furman wrote:
I would still like the int subclass, though, as it would be an aid to me on
the Python side.
I think you'll know what I'm going to say. :)
Yup, saw that coming. ;)
1) Usually, you won't need it
On Feb 24, 2013, at 07:32 PM, Ethan Furman wrote:
>I would still like the int subclass, though, as it would be an aid to me on
>the Python side.
I think you'll know what I'm going to say. :)
1) Usually, you won't need it (see the responses from people who don't care
about the value).
2) When yo
On 02/24/2013 05:40 PM, Barry Warsaw wrote:
On Feb 23, 2013, at 04:02 PM, Stefan Krah wrote:
+Ordered comparisons between enumeration values are *not* supported. Enums
are +not integers!
Hmm. I think this limits interoperation with C libraries and prototyping
C code.
This is mostly a red-h
On Feb 23, 2013, at 04:02 PM, Stefan Krah wrote:
>> +Ordered comparisons between enumeration values are *not* supported. Enums
>> are +not integers!
>
>Hmm. I think this limits interoperation with C libraries and prototyping
>C code.
This is mostly a red-herring. flufl.enum values are C-level i
On Sun, Feb 24, 2013 at 12:19 PM, Nick Coghlan wrote:
> On 24 Feb 2013 08:14, "Terry Reedy" wrote:
>> I personally think we should skip the bikeshedding over how to avoid
>> repeating names to make the bound name match the definition name (as with
>> def, class, and import). Actually, they do not
On 24 Feb 2013 08:14, "Terry Reedy" wrote:
>
> On 2/23/2013 12:46 PM, Nick Coghlan wrote:
>
>> For the standard library, we *really don't care* about any of those
>> things, because we're currently using integers and strings for
>> everything, so we can't add structure without risking breaking oth
On Sat, Feb 23, 2013 at 7:02 AM, Stefan Krah wrote:
> eli.bendersky wrote:
>> +Ordered comparisons between enumeration values are *not* supported. Enums
>> are
>> +not integers!
I agree with your idea, but note you probably shouldn't call them
e-num-erations, then.
> Hmm. I think this limits
On 2/23/2013 12:46 PM, Nick Coghlan wrote:
For the standard library, we *really don't care* about any of those
things, because we're currently using integers and strings for
everything, so we can't add structure without risking breaking other
people's code. However, just as we can get away with
On Sat, Feb 23, 2013 at 10:46 AM, Nick Coghlan wrote:
> However, pitching this at the enum level also introduces a mandatory
> level of structure we may not care about. All of the arguments about
> enums and what they should and shouldn't allow happen at the higher
> level, to do with the relation
On 02/23/2013 09:15 AM, Eli Bendersky wrote:
Hmm, constants such as os.SEEK_* which serve as *inputs* to stdlib rather
than outputs can actually be a good
candidate for enum without worrying about backwards compatibility.
The reason I make the *input* vs. *output* distinction, is that for std
On 02/23/2013 09:46 AM, Nick Coghlan wrote:
Many other existing libraries would be in the same boat - backwards
compatibility would be an insurmountable barrier to using enums, but
they *could* use named values.
I like the idea of named values, but to be clear about enums: if they are
int-bas
On Sat, 23 Feb 2013 09:15:54 -0800, Eli Bendersky wrote:
> On Sat, Feb 23, 2013 at 9:04 AM, Antoine Pitrou wrote:
>
> > On Sat, 23 Feb 2013 08:27:50 -0800
> > Eli Bendersky wrote:
> > > > See also http://bugs.python.org/issue16801#msg178542 for another use
> > > > case for named values.
> > > >
On Sun, Feb 24, 2013 at 3:15 AM, Eli Bendersky wrote:
> Hmm, constants such as os.SEEK_* which serve as *inputs* to stdlib rather
> than outputs can actually be a good candidate for enum without worrying
> about backwards compatibility.
Not true - users may be taking those values and passing the
On 02/23/2013 08:27 AM, Eli Bendersky wrote:
Any suggestions for places in the stdlib where enums could come useful will be
most welcome
codecs.EncodedFile:
errors = 'strict' | 'ignore' | 'xmlcharrefreplace' | 'replace'
socket:
AF_INET, AF_UNIX -- socket domains (first argument to soc
On Sat, Feb 23, 2013 at 9:04 AM, Antoine Pitrou wrote:
> On Sat, 23 Feb 2013 08:27:50 -0800
> Eli Bendersky wrote:
> > > See also http://bugs.python.org/issue16801#msg178542 for another use
> > > case for named values.
> > >
> > > I've seen an awful lot of code that uses global variables or clas
On Sat, 23 Feb 2013 08:27:50 -0800
Eli Bendersky wrote:
> > See also http://bugs.python.org/issue16801#msg178542 for another use
> > case for named values.
> >
> > I've seen an awful lot of code that uses global variables or class
> > attributes primarily to get name validation on constant values,
On Sun, Feb 24, 2013 at 2:27 AM, Eli Bendersky wrote:
> Any suggestions for places in the stdlib where enums could come useful will
> be most welcome
For named values in general:
- 0, 1, 2 as file descriptors (stdin/stdout/stderr)
- 0, 1, 2 as relative seek locations (start, current, end, but I
On Sat, 23 Feb 2013 08:27:50 -0800, Eli Bendersky wrote:
> On Sat, Feb 23, 2013 at 7:57 AM, R. David Murray wrote:
>
> > On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan
> > wrote:
> > > On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou
> > wrote:
> > > > On Sat, 23 Feb 2013 16:02:31 +0100
> > >
eli.bendersky wrote:
+Ordered comparisons between enumeration values are *not* supported. Enums are
+not integers!
class WeekDays(Enum):
SUNDAY = enum(doc='last day of the weekend')
MONDAY = enum(doc='back to work!')
TUESDAY = enum(doc='ho hum day')
WEDNESDAY =
On Feb 23, 2013, at 04:02 PM, Stefan Krah wrote:
>Hmm. I think this limits interoperation with C libraries and prototyping
>C code.
As for flufl.enums, it doesn't really, because while items are not ints they
are interoperable with ints.
>>> from flufl.enum import make
>>> Colors = make('Colors'
On Sat, Feb 23, 2013 at 7:57 AM, R. David Murray wrote:
> On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan
> wrote:
> > On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou
> wrote:
> > > On Sat, 23 Feb 2013 16:02:31 +0100
> > > Stefan Krah wrote:
> > >> eli.bendersky wrote:
> > >> > +Ordered compa
On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan wrote:
> On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou wrote:
> > On Sat, 23 Feb 2013 16:02:31 +0100
> > Stefan Krah wrote:
> >> eli.bendersky wrote:
> >> > +Ordered comparisons between enumeration values are *not* supported.
> >> > Enums are
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou wrote:
> On Sat, 23 Feb 2013 16:02:31 +0100
> Stefan Krah wrote:
>> eli.bendersky wrote:
>> > +Ordered comparisons between enumeration values are *not* supported.
>> > Enums are
>> > +not integers!
>>
>> Hmm. I think this limits interoperation wi
On Sat, 23 Feb 2013 16:02:31 +0100
Stefan Krah wrote:
> eli.bendersky wrote:
> > +Ordered comparisons between enumeration values are *not* supported. Enums
> > are
> > +not integers!
>
> Hmm. I think this limits interoperation with C libraries and prototyping
> C code.
Agreed, this is a deal-
eli.bendersky wrote:
> +Ordered comparisons between enumeration values are *not* supported. Enums
> are
> +not integers!
Hmm. I think this limits interoperation with C libraries and prototyping
C code.
Actually all I want from a Python enum is to be like a C enum with symbolic
representations
85 matches
Mail list logo
