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)
i
On Sun, Apr 21, 2013 at 11:29 AM, Steven D'Aprano 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 mention the
> Liskov S
On Sun, Apr 21, 2013 at 9:10 AM, R. David Murray wrote:
> On Sun, 21 Apr 2013 08:34:39 +1000, Tim Delaney
> wrote:
>> On 21 April 2013 04:10, Barry Warsaw wrote:
>>
>> > On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
>> >
>> > >Just using definition order as the stable iteration order would d
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 b
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. Us
On Sun, 21 Apr 2013 08:34:39 +1000, Tim Delaney
wrote:
> On 21 April 2013 04:10, Barry Warsaw 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
On 21 April 2013 04:10, Barry Warsaw 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 isn't possi
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
>
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__`` p
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 compa
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 u
On Sat, 20 Apr 2013 14:10:32 -0400, Barry Warsaw 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 thi
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
13 matches
Mail list logo
