On Apr 30, 2013, at 06:00 AM, Steven D'Aprano wrote:
>flufl.enum has been in use for Mailman for many years, and I would like to
>hear Barry's opinion on this.
I'm not sure it matters now (I'm about a billion messages behind with little
hope of catching up), but FWIW, I have use cases for extendi
On 29/04/2013 21:00, Steven D'Aprano wrote:
On 30/04/13 05:02, MRAB wrote:
Why is that backwards? MoreColor is a subclass of Color, so
instances of MoreColor are instances of Color, but instances of
Color are not instances of MoreColor. That's normal behaviour for
subclasses. (All cats are mamm
On Mon, Apr 29, 2013 at 12:52 PM, Oscar Benjamin
wrote:
> Would it not be better to avoid using isinstance() for this?
In a recent thread I explained why using isinstance() is important.
It's how we check for every other type, and it would be awlward for
type-checking frameworks to have to specia
On 30/04/13 05:02, MRAB wrote:
Why is that backwards? MoreColor is a subclass of Color, so instances
of MoreColor are instances of Color, but instances of Color are not
instances of MoreColor. That's normal behaviour for subclasses. (All
cats are mammals, but not all mammals are cats.)
Let's s
On 29 April 2013 20:04, Guido van Rossum wrote:
> On Mon, Apr 29, 2013 at 11:34 AM, Larry Hastings wrote:
>> What's the problem with overriding the isinstance checks? You mention it
>> but seem to assume it's a bad idea. That seems to me like it'd adequately
>> solve that problem with an accept
On 30/04/13 04:29, Guido van Rossum wrote:
You are too verbose. I have already said what I needed to say.
Sorry about that, sometimes I do go on and on. Let me be more terse.
When it comes to enums, I believe that violating Liskov is a feature, not a bug.
Also, I understand that both Scala an
29.04.13 21:14, Glenn Linderman написав(ла):
1) Enum could be subclassed to provide different, sharable, types of
behaviors, then further subclassed to provide a number of distinct sets
of values with those behaviors.
You can use a multiclass inheritance for this.
2) Enum could be subclassed
On Mon, Apr 29, 2013 at 11:34 AM, Larry Hastings wrote:
> What's the problem with overriding the isinstance checks? You mention it
> but seem to assume it's a bad idea. That seems to me like it'd adequately
> solve that problem with an acceptable level of magic.
Depending on whether you are usi
On 29/04/2013 19:24, Steven D'Aprano wrote:
On 30/04/13 03:01, Guido van Rossum wrote:
Oh dear, this is actually a mess. I don't want MoreColor.red and
Color.red to be distinct objects, but then the isinstance() checks
will become confusing. If we don't override isinstance(), we'll
get
not isi
On 04/29/2013 10:01 AM, Guido van Rossum wrote:
On Mon, Apr 29, 2013 at 9:12 AM, Ethan Furman wrote:
On 04/29/2013 08:39 AM, Guido van Rossum wrote:
Indeed, the "type(Color.red) is Color" claim was meant for the
situation where red is defined directly in Color, and I used type()
instead of isi
You are too verbose. I have already said what I needed to say.
On Mon, Apr 29, 2013 at 11:24 AM, Steven D'Aprano wrote:
> On 30/04/13 03:01, Guido van Rossum wrote:
>
>> Oh dear, this is actually a mess. I don't want MoreColor.red and
>> Color.red to be distinct objects, but then the isinstance()
On 30/04/13 03:01, Guido van Rossum wrote:
Oh dear, this is actually a mess. I don't want MoreColor.red and
Color.red to be distinct objects, but then the isinstance() checks
will become confusing. If we don't override isinstance(), we'll get
not isinstance(Color.red, MoreColor)
isinstanc
On 4/29/2013 10:01 AM, Guido van Rossum wrote:
On Mon, Apr 29, 2013 at 9:12 AM, Ethan Furman wrote:
On 04/29/2013 08:39 AM, Guido van Rossum wrote:
Indeed, the "type(Color.red) is Color" claim was meant for the
situation where red is defined directly in Color, and I used type()
instead of isin
On Mon, Apr 29, 2013 at 9:12 AM, Ethan Furman wrote:
> On 04/29/2013 08:39 AM, Guido van Rossum wrote:
>>
>> Indeed, the "type(Color.red) is Color" claim was meant for the
>> situation where red is defined directly in Color, and I used type()
>> instead of isinstance() because Barry was proposing
On 04/29/2013 08:39 AM, Guido van Rossum wrote:
Indeed, the "type(Color.red) is Color" claim was meant for the
situation where red is defined directly in Color, and I used type()
instead of isinstance() because Barry was proposing to overload
isinstance() to make this true without equating the cl
Indeed, the "type(Color.red) is Color" claim was meant for the
situation where red is defined directly in Color, and I used type()
instead of isinstance() because Barry was proposing to overload
isinstance() to make this true without equating the classes. But for
the subclass case, I want MoreColor
On Apr 29, 2013, at 7:32 AM, Ethan Furman wrote:
> On 04/28/2013 01:02 PM, Guido van Rossum wrote:
>> On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
>> - should enum items be of the type of the Enum class? (i.e. type(SPRING)
>> is Seasons)
>
> IMO Yes.
This decision seems natural to me, so
[creating new thread]
On 04/29/2013 01:30 AM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 11:50:16PM -0700, Ethan Furman wrote:
In other words, currently:
class Color(Enum):
red = 1
green = 2
blue = 3
class MoreColor(Color):
cyan = 4
magenta = 5
18 matches
Mail list logo
