On Mon, Apr 29, 2013 at 03:50:22PM -0700, Ethan Furman wrote:
> This just doesn't make sense to me:
>
> --> class Stuff(Enum):
> ... blue = 1
> ... china = 'really big country'
> ... random = (8273.199, 517)
>
> --> Stuff.blue.name == 'blue'
> --> Stuff.blue.value == 1
>
> --> Stuff.
On Mon, Apr 29, 2013 at 7:30 PM, Philip Jenvey wrote:
>
> On Apr 29, 2013, at 3:25 PM, Eli Bendersky wrote:
>
> > On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman
> wrote:
> > In the Planet example we saw the possibility of specifying arguments to
> enum item __init__:
> >
> > class Planet(Enum):
>
On Apr 29, 2013, at 03:25 PM, Eli Bendersky wrote:
>I'm -1, and this is yet another bad sign of conflating enums with classes.
>If planets want to have attributes and behaviors, let them be normal
>classes. If they want a PlanetId *enum member*, that's OK, but there's no
>need to intermix the two.
On Apr 29, 2013, at 04:16 PM, Ethan Furman wrote:
>I suppose the other option is to have `.value` be whatever was assigned (1,
>'really big country', and (8273.199, 517) ), and the fact that
>`int(Stuff.china) ` blows up and doesn't store easily in a database is the
>programmers issue...
Correct.
On 04/29/2013 07:42 PM, Nikolaus Rath wrote:
State is a class, it just inherits from enum. Thus:
type(State) == type(enum) == type(EnumMetaclass)
issubclass(State, enum) == True
HTH,
-Nikolaus
If you'd tried it, you'd have found that that isn't true. enum has a
metaclass, EnumMetaclas
Marco Hemmelrath writes:
> class State(enum):
> idle = 0
> busy = 1
> idling = idle
> ideling = 0
>
> together with the premises:
>
> 1. type(State.busy) == State
> 2. type(State) == enum
State is a class, it just inherits from enum. Thus:
type(State)
On 04/29/2013 06:23 PM, Marco Hemmelrath wrote:
First of all, hi, I'm new to this list.
Following the enum discussions on this list I am kind of confused about how
enums and their respective instances, i.e.
the values, should behave in "normal" context.
I apologize beforehand for the mass of "q
On Apr 29, 2013, at 3:25 PM, Eli Bendersky wrote:
> On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman wrote:
> In the Planet example we saw the possibility of specifying arguments to enum
> item __init__:
>
> class Planet(Enum):
> MERCURY = (3.303e+23, 2.4397e6)
> VENUS = (4.869e+24, 6.0
First of all, hi, I'm new to this list.
Following the enum discussions on this list I am kind of confused about
how enums and their respective instances, i.e. the values, should behave
in "normal" context.
I apologize beforehand for the mass of "questions" because the following
contains really
Armin Rigo writes:
> Hi Nikolaus,
>
> On Sat, Apr 27, 2013 at 4:39 AM, Nikolaus Rath wrote:
>> It's indeed very informative, but it doesn't fully address the question
>> because of the _pyio module which certainly can't use any custom C code.
>> Does that mean that when I'm using x = _pyio.Buffer
Ethan Furman wrote:
I suppose the other option is to have `.value` be whatever was assigned
(1, 'really big country', and (8273.199, 517) ),
I thought that was the intention all along, and that we'd
given up on the idea of auto-assigning integer values
(because it would require either new synta
Eli Bendersky wrote:
Besides, did we not agree that the only acceptable *members* for enums
are going to be descriptors?
No, that only applies to names assigned in the class body.
Here, mass and radius are being set a different way, so
there is no restriction on them.
--
Greg
_
On 29/04/2013 15:42, Armin Rigo wrote:
On Sat, Apr 27, 2013 at 4:39 AM, Nikolaus Rath wrote:
It's indeed very informative, but it doesn't fully address the question
because of the _pyio module which certainly can't use any custom C code.
Does that mean that when I'm using x = _pyio.BufferedWrit
On 04/29/2013 03:50 PM, Ethan Furman wrote:
This just doesn't make sense to me:
--> class Stuff(Enum):
... blue = 1
... china = 'really big country'
... random = (8273.199, 517)
--> Stuff.blue.name == 'blue'
--> Stuff.blue.value == 1
--> Stuff.china.name == 'china'
--> Stuff.china.
On 04/29/2013 03:25 PM, Eli Bendersky wrote:
Besides, did we not agree that the only acceptable *members* for enums are going to
be descriptors? In the above, mass &
radius are not descriptors.
Actually, it's the other way -- descriptors are excluded from being enum items,
along with dunder
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 04/29/2013 03:33 PM, Ethan Furman wrote:
On 04/29/2013 03:25 PM, Eli Bendersky wrote:
On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman wrote:
In the Planet example we saw the possibility of specifying arguments
to enum item __init__:
class Planet(Enum):
MERCURY = (3.303e+23, 2.4397e6)
This just doesn't make sense to me:
--> class Stuff(Enum):
... blue = 1
... china = 'really big country'
... random = (8273.199, 517)
--> Stuff.blue.name == 'blue'
--> Stuff.blue.value == 1
--> Stuff.china.name == 'china'
--> Stuff.china.value == ???
--> Stuff.random.name == 'rando
On 04/29/2013 03:13 PM, Guido van Rossum wrote:
Only if it is easy to implement. This example doesn't look like a good
fit for enums, but if the enum implementation can easily support this
(e.g. if there's nothing special about __init__) I don't want to
forcibly rule it out. I don't want to have
On 04/29/2013 03:25 PM, Eli Bendersky wrote:
On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman wrote:
In the Planet example we saw the possibility of specifying arguments to enum
item __init__:
class Planet(Enum):
MERCURY = (3.303e+23, 2.4397e6)
VENUS = (4.869e+24, 6.0518e6)
EART
On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman wrote:
> In the Planet example we saw the possibility of specifying arguments to
> enum item __init__:
>
> class Planet(Enum):
> MERCURY = (3.303e+23, 2.4397e6)
> VENUS = (4.869e+24, 6.0518e6)
> EARTH = (5.976e+24, 6.37814e6)
> MAR
On Mon, Apr 29, 2013 at 2:45 PM, Terry Jan Reedy wrote:
> On 4/29/2013 8:24 AM, Eli Bendersky wrote:
>
> Thanks for the summary. One issue I don't see addressed here is
>> int-compatibility. Am I correct to assume that nothing changes w.r.t.
>> that, and that an IntEnum subclass of Enum will be
On Mon, Apr 29, 2013 at 2:45 PM, Terry Jan Reedy wrote:
> On 4/29/2013 8:24 AM, Eli Bendersky wrote:
>
>> Thanks for the summary. One issue I don't see addressed here is
>> int-compatibility. Am I correct to assume that nothing changes w.r.t.
>> that, and that an IntEnum subclass of Enum will be p
On 04/29/2013 02:45 PM, Terry Jan Reedy wrote:
On 4/29/2013 8:24 AM, Eli Bendersky wrote:
Thanks for the summary. One issue I don't see addressed here is
int-compatibility. Am I correct to assume that nothing changes w.r.t.
that, and that an IntEnum subclass of Enum will be provided which is
is
Only if it is easy to implement. This example doesn't look like a good
fit for enums, but if the enum implementation can easily support this
(e.g. if there's nothing special about __init__) I don't want to
forcibly rule it out. I don't want to have to bend over backwards to
support it, however, if
30.04.13 00:59, Ethan Furman написав(ла):
In the Planet example we saw the possibility of specifying arguments to
enum item __init__:
class Planet(Enum):
MERCURY = (3.303e+23, 2.4397e6)
VENUS = (4.869e+24, 6.0518e6)
EARTH = (5.976e+24, 6.37814e6)
MARS= (6.421e+23, 3.3
In the Planet example we saw the possibility of specifying arguments to enum
item __init__:
class Planet(Enum):
MERCURY = (3.303e+23, 2.4397e6)
VENUS = (4.869e+24, 6.0518e6)
EARTH = (5.976e+24, 6.37814e6)
MARS= (6.421e+23, 3.3972e6)
JUPITER = (1.9e+27, 7.1492e7)
In article <1100748677.3355198.1367227656892.javamail.r...@redhat.com>,
Bohuslav Kabrda wrote:
> I'd like to ask about the purpose of files in $(DESTDIR)$(LIBPL) [1] - what
> is the reason to keep them/what are they useful for?
> I'm currently "taking over" Python packaging in Fedora and I'd lik
On 4/29/2013 8:24 AM, Eli Bendersky wrote:
Thanks for the summary. One issue I don't see addressed here is
int-compatibility. Am I correct to assume that nothing changes w.r.t.
that, and that an IntEnum subclass of Enum will be provided which is
isinstance(integer)? Does that become straightforw
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 04/29/2013 10:35 AM, Steven D'Aprano wrote:
On 30/04/13 02:42, Guido van Rossum wrote:
On Mon, Apr 29, 2013 at 6:51 AM, Eli Bendersky wrote:
I don't feel strongly about allowing ()-lookup in addition to
[]-lookup, but
in this paragraph the issue of multiple definitions has sneaked in :-)
On Mon, Apr 29, 2013 at 9:47 AM, Ethan Furman wrote:
> At this point I think the best course is to not allow duplicates directly in
> the enum definition, but allow them after the fact:
>
> --> class Color(Enum):
> ... red = 1
> ... green = 2
> ... blue = 3
>
> --> Color.grene = Color
On 30/04/13 02:42, Guido van Rossum wrote:
On Mon, Apr 29, 2013 at 6:51 AM, Eli Bendersky wrote:
I don't feel strongly about allowing ()-lookup in addition to []-lookup, but
in this paragraph the issue of multiple definitions has sneaked in :-)
flufl.enum disallows this:
class Color(Enum):
On 04/29/2013 09:30 AM, Larry Hastings wrote:
On 04/29/2013 06:51 AM, Eli Bendersky wrote:
flufl.enum disallows this:
class Color(Enum):
red = 1
blue = 2
green = 1 # oops!
Has it been decided that this is now allowed? If this is indeed the case, then
Color(1) is a problem. The options
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 Mon, Apr 29, 2013 at 6:51 AM, Eli Bendersky wrote:
> I don't feel strongly about allowing ()-lookup in addition to []-lookup, but
> in this paragraph the issue of multiple definitions has sneaked in :-)
> flufl.enum disallows this:
>
> class Color(Enum):
> red = 1
> blue = 2
> green = 1 #
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
On Mon, Apr 29, 2013 at 5:24 AM, Eli Bendersky wrote:
> Thanks for the summary. One issue I don't see addressed here is
> int-compatibility. Am I correct to assume that nothing changes w.r.t. that,
> and that an IntEnum subclass of Enum will be provided which is
> isinstance(integer)? Does that be
On 04/29/2013 06:51 AM, Eli Bendersky wrote:
flufl.enum disallows this:
class Color(Enum):
red = 1
blue = 2
green = 1 # oops!
Has it been decided that this is now allowed? If this is indeed the
case, then Color(1) is a problem. The options are:
A. Return either Color.red or Color.gree
Le Mon, 29 Apr 2013 16:42:38 +0200,
Armin Rigo a écrit :
> Hi Nikolaus,
>
> On Sat, Apr 27, 2013 at 4:39 AM, Nikolaus Rath
> wrote:
> > It's indeed very informative, but it doesn't fully address the
> > question because of the _pyio module which certainly can't use any
> > custom C code. Does th
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
Hi Nikolaus,
On Sat, Apr 27, 2013 at 4:39 AM, Nikolaus Rath wrote:
> It's indeed very informative, but it doesn't fully address the question
> because of the _pyio module which certainly can't use any custom C code.
> Does that mean that when I'm using x = _pyio.BufferedWriter(), I could loose
>
[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
On Sun, Apr 28, 2013 at 9:09 PM, Guido van Rossum wrote:
> On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan wrote:
> > Functions are descriptors, so this rule already covers ordinary methods.
> The
> > slight concern I have with making the duck typed exclusion only
> descriptors
> > (rather than de
On Sun, Apr 28, 2013 at 9:09 PM, Guido van Rossum wrote:
> On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan wrote:
> > Functions are descriptors, so this rule already covers ordinary methods.
> The
> > slight concern I have with making the duck typed exclusion only
> descriptors
> > (rather than de
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote:
> Example enumeration:
>
> class Seasons(Enum):
> SPRING = 1
> SUMMER = 2
> AUTUMN = 3
> WINTER = 4
>
> days_in_year = 365
>
> @property
> def avg_temp(self):
> return (75, 92, 66, 33)[int(self)+1] # enums a
Hi,
I'd like to ask about the purpose of files in $(DESTDIR)$(LIBPL) [1] - what is
the reason to keep them/what are they useful for?
I'm currently "taking over" Python packaging in Fedora and I'd like to know if
these have some meaning for a distro-packaged Python (Dave Malcolm is not sure
about
Le Mon, 29 Apr 2013 00:13:53 -0700,
Ethan Furman a écrit :
> [starting new thread to not pollute the summary thread]
>
> On 04/28/2013 11:54 PM, Antoine Pitrou wrote:> On Sun, 28 Apr 2013
> 17:29:35 -0700
> > Ethan Furman wrote:
> >>
> >> Not only is this inconsistent with the rest of Python*,
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
> yellow = 6
> black = 7
>
> MoreColor.red is C
Guido van Rossum wrote:
(2a. We could also allow Color('red') is Color.red, but that could be
confusing, and we can already do that with getattr(Color, 'red'),
That doesn't quite give you the same thing. Presumably
Color('__str__') would be expected to raise a ValueError,
for example.
--
Greg
Cameron Simpson wrote:
I'd go a bit further here: I'd take this final sentence as being
-0 on preventing adding more enumerals(?), whereas I'm a solid -1
on preventing it. By all means not actively support it, but very
against doing things that make it hard for a subclass to support
it.
I had a
[starting new thread to not pollute the summary thread]
On 04/28/2013 11:54 PM, Antoine Pitrou wrote:> On Sun, 28 Apr 2013 17:29:35
-0700
Ethan Furman wrote:
Not only is this inconsistent with the rest of Python*, but it's going to be a
PITA for data storage/retrieval:
datastore = db
On 04/28/2013 09:54 PM, Guido van Rossum wrote:
On Sunday, April 28, 2013, Ethan Furman wrote:
Enums are the same: they could return brand new instances every time, and
programs using `==` to compare will keep
on working. That they don't is an implementation detail.
Whoa. In this case the i
64 matches
Mail list logo
