Am 04.05.2013 01:22, schrieb Antoine Pitrou:
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Eli Bendersky wrote:
I'm just curious what it is about enums that sets everyone on a let's
make things safer path. Python is about duck typing, it's absolutely
On Sat, May 4, 2013 at 4:10 PM, Georg Brandl g.bra...@gmx.net wrote:
Am 04.05.2013 01:22, schrieb Antoine Pitrou:
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Eli Bendersky wrote:
I'm just curious what it is about enums that sets everyone on a let's
make
Guido van Rossum wrote:
Code that wants to validate a string the user typed as input. Web
forms just don't work that way.
Maybe validation was a misleading term to use. To be
more precise, I'm talking about taking input to the
program (it needn't come directly from a user, it could
be read
Nick Coghlan wrote:
1. The current PEP, offering only getattr(MyEnum, name).
2. We restore __getitem__ on EnumMetaclass *solely* for member lookup
by name
3. Use keyword arguments to distinguish two different
ways of calling the enum class:
MyEnum(value = 1) -- lookup by value
On 4 May 2013 07:42, Nick Coghlan ncogh...@gmail.com wrote:
2. We restore __getitem__ on EnumMetaclass *solely* for member lookup
by name (the getmember functionality above). This would leave
__call__ used for the reverse lookup (value to member and hence name)
and __getitem__ for the forward
On Sat, 4 May 2013 16:42:08 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sat, May 4, 2013 at 4:10 PM, Georg Brandl g.bra...@gmx.net wrote:
Am 04.05.2013 01:22, schrieb Antoine Pitrou:
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Eli Bendersky wrote:
On 05/04/2013 04:33 AM, Antoine Pitrou wrote:
On Sat, 4 May 2013 16:42:08 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sat, May 4, 2013 at 4:10 PM, Georg Brandl g.bra...@gmx.net wrote:
Am 04.05.2013 01:22, schrieb Antoine Pitrou:
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing
On 5/4/2013 2:42 AM, Nick Coghlan wrote:
On Sat, May 4, 2013 at 4:10 PM, Georg Brandl g.bra...@gmx.net wrote:
Am 04.05.2013 01:22, schrieb Antoine Pitrou:
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Eli Bendersky wrote:
I'm just curious what it is about
On Sat, 04 May 2013 06:37:23 -0700
Ethan Furman et...@stoneleaf.us wrote:
+1. An enum is basically a bidirectional mapping between some raw
values and some nice instances, so it deserves a well-defined lookup
operation in each direction.
As I see it, there are 3 possible ways forward
Just to stop the bikeshedding, let's do #2. Put back __getitem__
solely for lookup by name. Keep __call__ (really __new__) for lookup
by value or pass-through for members.
--Guido
On Fri, May 3, 2013 at 11:42 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, May 4, 2013 at 4:10 PM, Georg
On 05/04/2013 07:01 AM, Eric V. Smith wrote:
On 5/4/2013 2:42 AM, Nick Coghlan wrote:
I'm now -1 on my own as_dict() suggestion, due to the general name
clash problem for arbitrary enums.
To avoid the name collision, namedtuple calls this _asdict().
Although I recall Raymond told me he
Hm. Trailing underscores look *really* weird to me.
On Sat, May 4, 2013 at 3:41 PM, Larry Hastings la...@hastings.org wrote:
On 05/04/2013 07:01 AM, Eric V. Smith wrote:
On 5/4/2013 2:42 AM, Nick Coghlan wrote:
I'm now -1 on my own as_dict() suggestion, due to the general name
clash problem
Barry Warsaw wrote:
I still don't get it why this is an issue though, or at least why this is
different than any other getattr on any other class,
It's not a problem that getattr() has this behaviour.
What I'm questioning is the idea that getattr() should
be the only provided way of doing a
On Fri, May 3, 2013 at 6:34 AM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Barry Warsaw wrote:
I still don't get it why this is an issue though, or at least why this is
different than any other getattr on any other class,
It's not a problem that getattr() has this behaviour.
What I'm
On Fri, May 3, 2013 at 7:14 AM, Eli Bendersky eli...@gmail.com wrote:
I'm just curious what it is about enums that sets everyone on a let's make
things safer path. Python is about duck typing, it's absolutely unsafe in
the static typing sense, in the most fundamental ways imaginable. When
Guido van Rossum wrote:
I haven't seen code in the style that
Greg proposes in decades,
What style are you talking about here?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Eli Bendersky wrote:
I'm just curious what it is about enums that sets everyone on a let's
make things safer path. Python is about duck typing, it's absolutely
unsafe in the static typing sense, in the most fundamental ways
imaginable.
This isn't about catching bugs in the program, it's
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Eli Bendersky wrote:
I'm just curious what it is about enums that sets everyone on a let's
make things safer path. Python is about duck typing, it's absolutely
unsafe in the static typing sense, in the most
On Fri, May 3, 2013 at 4:08 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
I haven't seen code in the style that
Greg proposes in decades,
What style are you talking about here?
Code that wants to validate a string the user typed as input. Web
forms just don't
On 4 May 2013 00:17, Eli Bendersky eli...@gmail.com wrote:
On Fri, May 3, 2013 at 6:34 AM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Barry Warsaw wrote:
I still don't get it why this is an issue though, or at least why this
is
different than any other getattr on any other class,
On 4 May 2013 09:34, Guido van Rossum gu...@python.org wrote:
On Fri, May 3, 2013 at 4:08 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Guido van Rossum wrote:
I haven't seen code in the style that
Greg proposes in decades,
What style are you talking about here?
Code that wants
On May 01, 2013, at 11:54 AM, Larry Hastings wrote:
On 04/30/2013 11:29 PM, Ethan Furman wrote:
On 04/30/2013 11:18 PM, Barry Warsaw wrote:
On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
But as soon as:
type(Color.red) is Color # True
type(MoreColor.red) is MoreColor #
On May 02, 2013, at 11:44 AM, Greg Ewing wrote:
Barry Warsaw wrote:
Why isn't getattr() for lookup by name
good enough?
Because it will find things that are not enum items,
e.g. '__str__'.
Why does that matter?
-Barry
___
Python-Dev mailing list
On 05/02/2013 07:57 AM, Barry Warsaw wrote:
On May 01, 2013, at 11:54 AM, Larry Hastings wrote:
On 04/30/2013 11:29 PM, Ethan Furman wrote:
On 04/30/2013 11:18 PM, Barry Warsaw wrote:
On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
But as soon as:
type(Color.red) is Color #
On Thu, May 2, 2013 at 7:58 AM, Barry Warsaw ba...@python.org wrote:
On May 02, 2013, at 11:44 AM, Greg Ewing wrote:
Barry Warsaw wrote:
Why isn't getattr() for lookup by name
good enough?
Because it will find things that are not enum items,
e.g. '__str__'.
Why does that matter?
I claim it
On May 02, 2013, at 08:42 AM, Larry Hastings wrote:
So, for the second time: How can Color.red and MoreColor.red be the same
object when they are of different types?
It's a moot point now given Guido's pronouncement.
-Barry
___
Python-Dev mailing list
On Thu, May 2, 2013 at 8:57 AM, Barry Warsaw ba...@python.org wrote:
On May 02, 2013, at 08:42 AM, Larry Hastings wrote:
So, for the second time: How can Color.red and MoreColor.red be the same
object when they are of different types?
It's a moot point now given Guido's pronouncement.
Guido van Rossum wrote:
you should do some other check,
e.g. if x in Color:.
So you don't think it's important to have an easy
way to take user input that's supposed to be a
Color name and either return a Color or raise
a ValueError?
--
Greg
___
Eli Bendersky wrote:
TypeError: Cannot subclass enumerations
This message might be better phrased as cannot extend
enumerations, since we're still allowing subclassing
prior to defining members.
--
Greg
___
Python-Dev mailing list
On 05/02/2013 04:45 PM, Greg Ewing wrote:
Eli Bendersky wrote:
TypeError: Cannot subclass enumerations
This message might be better phrased as cannot extend
enumerations, since we're still allowing subclassing
prior to defining members.
I like it, thanks!
--
~Ethan~
On Thu, May 2, 2013 at 4:50 PM, Ethan Furman et...@stoneleaf.us wrote:
On 05/02/2013 04:45 PM, Greg Ewing wrote:
Eli Bendersky wrote:
TypeError: Cannot subclass enumerations
This message might be better phrased as cannot extend
enumerations, since we're still allowing subclassing
prior
On 05/02/2013 04:43 PM, Greg Ewing wrote:
Guido van Rossum wrote:
you should do some other check,
e.g. if x in Color:.
So you don't think it's important to have an easy
way to take user input that's supposed to be a
Color name and either return a Color or raise
a ValueError?
I don't believe
On Fri, May 3, 2013 at 9:57 AM, Ethan Furman et...@stoneleaf.us wrote:
On 05/02/2013 04:43 PM, Greg Ewing wrote:
Guido van Rossum wrote:
you should do some other check,
e.g. if x in Color:.
So you don't think it's important to have an easy
way to take user input that's supposed to be a
On May 03, 2013, at 11:06 AM, Nick Coghlan wrote:
User input should qualify, and using getattr(EnumClass, user_input) will get
you an AttributeError instead of a ValueError if user_input is not valid,
but surely you don't mind that small difference. ;)
int(getattr(C(), __str__))
Traceback
On Apr 29, 2013, at 11:10 AM, Stephen J. Turnbull wrote:
Ethan thinks that Seasons(3) is a typecast, not an access into a
mapping (which would be better expressed by Seasons[3]). Ie, the
inverse of int(AUTUMN).
This is consistent with the AUTUMN is-a Seasons position that Ethan
and Guido take.
On Apr 28, 2013, at 07:46 PM, Ethan Furman wrote:
and similarly, Enum behavior /should be/ (in my opinion ;)
Season.AUTUMN is Season('AUTUMN') is Season(3)
I think you'll have a problem with this. flufl.enum did this, but it has an
inherent conflict, which is why we removed the getattr-like
On Apr 29, 2013, at 03:36 PM, Steven D'Aprano wrote:
That's not how I understand it. I expected that the correct way to use
enums is with identity checks:
if arg is Season.SUMMER:
handle_summer()
It's certainly the way I've recommended to use them. I think `is` reads
better in context,
On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
But as soon as:
type(Color.red) is Color # True
type(MoreColor.red) is MoreColor # True
then:
Color.red is MoreColor.red # must be False, no?
If that last statement can still be True, I'd love it if someone showed me
how.
On 04/30/2013 11:18 PM, Barry Warsaw wrote:
On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
But as soon as:
type(Color.red) is Color # True
type(MoreColor.red) is MoreColor # True
then:
Color.red is MoreColor.red # must be False, no?
If that last statement can still
On 4/30/2013 11:08 PM, Barry Warsaw wrote:
On Apr 28, 2013, at 07:46 PM, Ethan Furman wrote:
and similarly, Enum behavior /should be/ (in my opinion ;)
Season.AUTUMN is Season('AUTUMN') is Season(3)
I think you'll have a problem with this. flufl.enum did this, but it has an
inherent
On May 01, 2013, at 12:19 AM, Glenn Linderman wrote:
Can Things('foo') lookup by name and Things['foo'] lookup by value? Or does
that confuse things too?
I think it confuses things too much. Why isn't getattr() for lookup by name
good enough? It is for regular classes.
-Barry
On 04/30/2013 11:29 PM, Ethan Furman wrote:
On 04/30/2013 11:18 PM, Barry Warsaw wrote:
On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote:
But as soon as:
type(Color.red) is Color # True
type(MoreColor.red) is MoreColor # True
then:
Color.red is MoreColor.red # must be
Barry Warsaw wrote:
Why isn't getattr() for lookup by name
good enough?
Because it will find things that are not enum items,
e.g. '__str__'.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Steven D'Aprano wrote:
On 29/04/13 10:29, Ethan Furman wrote:
- bool(1)# True
- int('11') # 11
- str(var) # whatever var had in it, now as a str
I think that's a red herring, because you're comparing the use of the
object constructor with look-up by name.
How does what
On 28Apr2013 19:46, Ethan Furman et...@stoneleaf.us wrote:
| int, float, and bool all have object constructors that take the
| given string and return a matching instance; int /may/ return a
| pre-existing instance, bool /will/ return a pre-existing instance.
I think Guido's already pointed out
On Sun, 28 Apr 2013 17:29:35 -0700
Ethan Furman et...@stoneleaf.us wrote:
Not only is this inconsistent with the rest of Python*, but it's going to be
a PITA for data storage/retrieval:
datastore = dbf.Table('storage.dbf', 'event_name C(50); date D; season
SEASON')
def
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
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
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
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 Color.red #
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman et...@stoneleaf.us 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] #
On Sun, Apr 28, 2013 at 9:09 PM, Guido van Rossum gu...@python.org wrote:
On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan ncogh...@gmail.com wrote:
Functions are descriptors, so this rule already covers ordinary methods.
The
slight concern I have with making the duck typed exclusion only
On Sun, Apr 28, 2013 at 9:09 PM, Guido van Rossum gu...@python.org wrote:
On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan ncogh...@gmail.com wrote:
Functions are descriptors, so this rule already covers ordinary methods.
The
slight concern I have with making the duck typed exclusion only
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
On Mon, Apr 29, 2013 at 5:24 AM, Eli Bendersky eli...@gmail.com 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)?
On Mon, Apr 29, 2013 at 6:51 AM, Eli Bendersky eli...@gmail.com 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
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 30/04/13 02:42, Guido van Rossum wrote:
On Mon, Apr 29, 2013 at 6:51 AM, Eli Bendersky eli...@gmail.com 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
On Mon, Apr 29, 2013 at 9:47 AM, Ethan Furman et...@stoneleaf.us 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
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 eli...@gmail.com wrote:
I don't feel strongly about allowing ()-lookup in addition to
[]-lookup, but
in this paragraph the issue of multiple definitions
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
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
On Mon, Apr 29, 2013 at 2:45 PM, Terry Jan Reedy tjre...@udel.edu 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
On Mon, Apr 29, 2013 at 2:45 PM, Terry Jan Reedy tjre...@udel.edu 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
Hi all,
I've just read a few dozen enum-related emails, and there are so many more.
I would like to form an opinion about the proposal(s), but I feel I don't
know what the actual issues are anymore.
In the past, somebody usually presented a summary of the issues so far,
and that was a good point
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 are 1-based
Definite Issues:
- should enum items be of the type of the
My opinions added
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman et...@stoneleaf.us 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,
On 04/28/2013 01:02 PM, Guido van Rossum wrote:
My opinions added
Mine also now added.
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,
On Sun, 28 Apr 2013 13:02:11 -0700
Guido van Rossum gu...@python.org wrote:
- for the above two, how should they be included/excluded?
IMO Everything should be enumerated except
(a) things with a __get__() method (i.e. descriptors)
(b) __dunder__ names
I think it would be nice to
On 29 Apr 2013 07:32, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 28 Apr 2013 13:02:11 -0700
Guido van Rossum gu...@python.org wrote:
- for the above two, how should they be included/excluded?
IMO Everything should be enumerated except
(a) things with a __get__() method (i.e.
On Mon, 29 Apr 2013 08:28:34 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 29 Apr 2013 07:32, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 28 Apr 2013 13:02:11 -0700
Guido van Rossum gu...@python.org wrote:
- for the above two, how should they be included/excluded?
IMO
On 04/28/2013 02:29 PM, Antoine Pitrou wrote:
On Sun, 28 Apr 2013 13:02:11 -0700
Guido van Rossum gu...@python.org wrote:
- for the above two, how should they be included/excluded?
IMO Everything should be enumerated except
(a) things with a __get__() method (i.e. descriptors)
(b)
On 29/04/13 06:02, Guido van Rossum wrote:
My opinions added
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman et...@stoneleaf.us wrote:
Definite Issues:
- should enum items be of the type of the Enum class? (i.e. type(SPRING)
is Seasons)
IMO Yes.
+1
- should an enum item be
On Sun, Apr 28, 2013 at 7:37 PM, Steven D'Aprano st...@pearwood.info wrote:
I have also suggested that that the enum package provide a decorator
which can be used to explicitly flag values to *not* be turned into
enum values. See here:
On 4/28/2013 4:37 PM, Steven D'Aprano wrote:
I have also suggested that that the enum package provide a decorator
which can be used to explicitly flag values to *not* be turned into
enum values. See here:
http://mail.python.org/pipermail/python-dev/2013-April/125641.html
Even if the Enum class
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman et...@stoneleaf.us wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Seasons(3) is AUTUMN)
Does anyone know why this is even an issue? Is this pure
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman et...@stoneleaf.us wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Seasons(3) is AUTUMN)
Does anyone know why this is
Steven D'Aprano writes:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Seasons(3) is AUTUMN)
No opinion.
Does anyone know why this is even an issue? Is this pure
bike-shedding over the API, or are there technical reasons for
choosing one over
On 04/28/2013 07:10 PM, Stephen J. Turnbull wrote:
@Ethan: I have real trouble sympathizing with your point of view
because you consistently pluralize your Enum names. AUTUMN *is not* a
SeasonZZ, it is an element of the *collection* Seasons. OTOH, AUTUMN
*is* a Season (look Ma, no ZZ!)
I
On 04/28/2013 06:52 PM, Steven D'Aprano wrote:
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman et...@stoneleaf.us wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e.
On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan ncogh...@gmail.com 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 descriptors and callables) is that it means things like
Ethan Furman writes:
I would hope that you would pay more attention to my arguments and
rationale than to poorly chosen names.
I do. Nevertheless, it requires conscious effort. It's quite
appropriate for you to ask that of me, but ... do you think you're
doing Python any good to ask more
[re-directing back to python-dev]
On 04/28/2013 08:42 PM, Davis Silverman wrote:
as a not super experienced python developer, when i see Season('AUTUMN') it
looks like im creating an a Season object. I
understand your resoning, that it acts like a boolean singleton, however, i
feel it would
On 4/28/2013 9:09 PM, 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'), and
bool('False') doesn't return False anyway, so let's not do that.)
Glad you made this pronouncement in this
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 identity property is not justban implementation
Am 28.04.2013 22:36, schrieb Ethan Furman:
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 are 1-based
Definite Issues:
- should enum items be of
On Sun, Apr 28, 2013 at 09:02:15PM -0700, Ethan Furman wrote:
Two examples:
- the first few integers (up to 256 now, I think) are pre-created by the
interpreter; when you do `int('7')` you are not getting a brand-new, never
before used, integer 7 object, you're getting a cached
87 matches
Mail list logo
