On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
Just using definition order as the stable iteration order would do the
trick - no need for any comparisons at all. Subclasses (e.g. IntEnum) can
then override it.
I think this isn't possible if we want to keep backward compatibility with
earlier
On Sat, 20 Apr 2013 14:10:32 -0400, Barry Warsaw ba...@python.org wrote:
On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
Just using definition order as the stable iteration order would do the
trick - no need for any comparisons at all. Subclasses (e.g. IntEnum) can
then override it.
I
On Apr 13, 2013, at 11:31 AM, Serhiy Storchaka wrote:
On 12.04.13 15:55, Eli Bendersky wrote:
The enumeration value names are available through the class members::
for member in Colors.__members__:
... print(member)
red
green
blue
This is unnecessary because
Can we separate the iteration order and the comparison order? For
iteration order, I think by definition order or by attribute name are
both great, and better than by value. But for comparing values using
, ==, , I strongly feel we should defer to the underlying values --
if those cannot be
On Apr 13, 2013, at 08:33 AM, Guido van Rossum wrote:
(And yes, I am now +1 on documenting this mechanism.)
Here's what I've added to the flufl.enum documentation:
Customization protocol
==
You can define your own enumeration value types by using the
``__value_factory__``
On Apr 13, 2013, at 12:51 PM, Steven D'Aprano wrote:
I think that's too strong a restriction. I would expect to be able to do this:
class Insect(Enum):
wsap = 1 # Oops, needed for backward compatibility, do not remove.
wasp = 1 # Preferred. Use this in new code.
bee = 2
ant
On 21 April 2013 04:10, Barry Warsaw ba...@python.org wrote:
On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
Just using definition order as the stable iteration order would do the
trick - no need for any comparisons at all. Subclasses (e.g. IntEnum) can
then override it.
I think this
On Sun, 21 Apr 2013 08:34:39 +1000, Tim Delaney timothy.c.dela...@gmail.com
wrote:
On 21 April 2013 04:10, Barry Warsaw ba...@python.org wrote:
On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
Just using definition order as the stable iteration order would do the
trick - no need for
On 21/04/13 05:42, Barry Warsaw wrote:
On Apr 13, 2013, at 12:51 PM, Steven D'Aprano wrote:
I think that's too strong a restriction. I would expect to be able to do this:
class Insect(Enum):
wsap = 1 # Oops, needed for backward compatibility, do not remove.
wasp = 1 # Preferred.
On 04/20/2013 01:42 PM, Barry Warsaw wrote: On Apr 13, 2013, at 12:51 PM,
Steven D'Aprano wrote:
[...]
What's the justification for this [unique values] restriction? I have
looked in the PEP, and didn't see one.
If you allowed this, there would be no way to look up an enumeration item by
On Sun, Apr 21, 2013 at 9:10 AM, R. David Murray rdmur...@bitdance.com wrote:
On Sun, 21 Apr 2013 08:34:39 +1000, Tim Delaney timothy.c.dela...@gmail.com
wrote:
On 21 April 2013 04:10, Barry Warsaw ba...@python.org wrote:
On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
Just using
On Sun, Apr 21, 2013 at 11:29 AM, Steven D'Aprano st...@pearwood.info wrote:
I would argue that it is the responsibility of enums to start with the least
restrictions as is reasonable, and leave additional restrictions up to
subclasses, rather than the other way around. (I'll just quietly
On 04/20/2013 10:55 PM, Rurpy wrote:
[...]
But it is not true that unique values are *required* for
storing enumeration values in a database.
I should have added that allowing mixed types for values (e.g.
as discussed in
http://mail.python.org/pipermail/python-dev/2013-April/125322.html)
is
13 matches
Mail list logo
