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
Le Wed, 27 Feb 2013 12:33:35 +0900,
Stephen J. Turnbull step...@xemacs.org 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
On Wed, Feb 27, 2013 at 8:30 AM, Antoine Pitrou solip...@pitrou.net 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
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
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 only to the
On Mon, Feb 25, 2013 at 3:17 PM, Glyph gl...@twistedmatrix.com wrote:
On Feb 25, 2013, at 12:32 PM, Barry Warsaw ba...@python.org wrote:
Dumb question, but are flufl.enums ordered? That's also an important use
case.
Kind of. Ordered comparisons are explicitly not supported, but
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
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-transitive, so
On 2/25/2013 2:48 PM, Antoine Pitrou wrote:
On Mon, 25 Feb 2013 11:34:35 -0800
Ethan Furman et...@stoneleaf.us 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
On Wed, Feb 27, 2013 at 1:09 AM, Terry Reedy tjre...@udel.edu wrote:
On 2/25/2013 2:48 PM, Antoine Pitrou wrote:
On Mon, 25 Feb 2013 11:34:35 -0800
Ethan Furman et...@stoneleaf.us wrote:
Antoine, question for you:
Do you think enums from different groupings should compare equal?
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
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
On Wed, Feb 27, 2013 at 2:03 AM, Ethan Furman et...@stoneleaf.us 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
On 02/26/2013 11:17 AM, Antoine Pitrou wrote:
On Tue, 26 Feb 2013 08:03:40 -0800
Ethan Furman et...@stoneleaf.us 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
On 27 February 2013 01:50, Terry Reedy tjre...@udel.edu 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
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 02/26/2013 12:52 PM, Tim Delaney wrote:
On 27 February 2013 01:50, Terry Reedy tjre...@udel.edu
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,
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
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
On Feb 26, 2013, at 5:25 AM, Eli Bendersky eli...@gmail.com 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
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 no
Antoine Pitrou writes:
On Tue, 26 Feb 2013 08:03:40 -0800
Ethan Furman et...@stoneleaf.us 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
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
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 required
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 you
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
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 use case
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 enums to
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.
On Tue, Feb 26, 2013 at 12:53 AM, Skip Montanaro s...@pobox.com 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 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
Le Mon, 25 Feb 2013 06:45:27 -0800,
Eli Bendersky eli...@gmail.com 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
On Mon, 25 Feb 2013 07:12:03 -0800, Ethan Furman et...@stoneleaf.us 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
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 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
Le Mon, 25 Feb 2013 11:37:29 -0500,
Barry Warsaw ba...@python.org 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
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
Le Mon, 25 Feb 2013 10:44:33 -0600,
Skip Montanaro s...@pobox.com 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,
On Mon, Feb 25, 2013 at 8:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 25 Feb 2013 10:44:33 -0600,
Skip Montanaro s...@pobox.com 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
On Mon, 25 Feb 2013 09:03:06 -0800, Eli Bendersky eli...@gmail.com wrote:
On Mon, Feb 25, 2013 at 8:56 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 25 Feb 2013 10:44:33 -0600,
Skip Montanaro s...@pobox.com a écrit :
Besides we just don't need them int-based in these use-cases
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
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
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
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
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
different groups do not
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, and
On Mon, 25 Feb 2013 09:03:06 -0800
Eli Bendersky eli...@gmail.com 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
On Mon, 25 Feb 2013 13:05:02 -0500
Barry Warsaw ba...@python.org 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
On 02/25/2013 10:49 AM, Antoine Pitrou wrote:
On Mon, 25 Feb 2013 09:03:06 -0800
Eli Bendersky eli...@gmail.com 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
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 26 February 2013 07:32, Barry Warsaw ba...@python.org 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
On Feb 25, 2013, at 12:32 PM, Barry Warsaw ba...@python.org 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
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 :
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
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 :
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 Animals.bee ==
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
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, you
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 number
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 int
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
eli.bendersky python-check...@python.org 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
On Sat, 23 Feb 2013 16:02:31 +0100
Stefan Krah ste...@bytereef.org wrote:
eli.bendersky python-check...@python.org wrote:
+Ordered comparisons between enumeration values are *not* supported. Enums
are
+not integers!
Hmm. I think this limits interoperation with C libraries and
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 Feb 2013 16:02:31 +0100
Stefan Krah ste...@bytereef.org wrote:
eli.bendersky python-check...@python.org wrote:
+Ordered comparisons between enumeration values are *not* supported.
Enums are
+not
On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 Feb 2013 16:02:31 +0100
Stefan Krah ste...@bytereef.org wrote:
eli.bendersky python-check...@python.org wrote:
+Ordered
On Sat, Feb 23, 2013 at 7:57 AM, R. David Murray rdmur...@bitdance.comwrote:
On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan ncogh...@gmail.com
wrote:
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Sat, 23 Feb 2013 16:02:31 +0100
Stefan Krah
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', 'red
On Sat, 23 Feb 2013 08:27:50 -0800, Eli Bendersky eli...@gmail.com wrote:
On Sat, Feb 23, 2013 at 7:57 AM, R. David Murray rdmur...@bitdance.comwrote:
On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan ncogh...@gmail.com
wrote:
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou
On Sat, 23 Feb 2013 08:27:50 -0800
Eli Bendersky eli...@gmail.com 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
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
On Sun, Feb 24, 2013 at 3:15 AM, Eli Bendersky eli...@gmail.com 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
On Sat, 23 Feb 2013 09:15:54 -0800, Eli Bendersky eli...@gmail.com wrote:
On Sat, Feb 23, 2013 at 9:04 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 Feb 2013 08:27:50 -0800
Eli Bendersky eli...@gmail.com wrote:
See also http://bugs.python.org/issue16801#msg178542 for another
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
On Sat, Feb 23, 2013 at 10:46 AM, Nick Coghlan ncogh...@gmail.com 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
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 7:02 AM, Stefan Krah ste...@bytereef.org wrote:
eli.bendersky python-check...@python.org 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
On 24 Feb 2013 08:14, Terry Reedy tjre...@udel.edu 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
On Sun, Feb 24, 2013 at 12:19 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 24 Feb 2013 08:14, Terry Reedy tjre...@udel.edu 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
78 matches
Mail list logo
