Hm. Trailing underscores look *really* weird to me.
On Sat, May 4, 2013 at 3:41 PM, Larry Hastings 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 for arbitrar
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 should
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 wrote:
> On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
>> Am
On Sat, 04 May 2013 06:37:23 -0700
Ethan Furman 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
On 5/4/2013 2:42 AM, Nick Coghlan wrote:
> On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
>> Am 04.05.2013 01:22, schrieb Antoine Pitrou:
>>> On Sat, 04 May 2013 11:15:17 +1200
>>> Greg Ewing wrote:
Eli Bendersky wrote:
> I'm just curious what it is about enums that sets everyone on
On 05/04/2013 04:33 AM, Antoine Pitrou wrote:
On Sat, 4 May 2013 16:42:08 +1000
Nick Coghlan wrote:
On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
Am 04.05.2013 01:22, schrieb Antoine Pitrou:
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing wrote:
Eli Bendersky wrote:
I'm just curious w
On Sat, 4 May 2013 16:42:08 +1000
Nick Coghlan wrote:
> On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
> > Am 04.05.2013 01:22, schrieb Antoine Pitrou:
> >> On Sat, 04 May 2013 11:15:17 +1200
> >> Greg Ewing wrote:
> >>> Eli Bendersky wrote:
> >>> > I'm just curious what it is about enums t
On 4 May 2013 07:42, "Nick Coghlan" 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 lookup (nam
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
MyE
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 fr
On Sat, May 4, 2013 at 4:10 PM, Georg Brandl wrote:
> Am 04.05.2013 01:22, schrieb Antoine Pitrou:
>> On Sat, 04 May 2013 11:15:17 +1200
>> Greg Ewing 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
Am 04.05.2013 01:22, schrieb Antoine Pitrou:
> On Sat, 04 May 2013 11:15:17 +1200
> Greg Ewing 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 th
On 4 May 2013 09:34, "Guido van Rossum" wrote:
>
> On Fri, May 3, 2013 at 4:08 PM, Greg Ewing
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
On 4 May 2013 00:17, "Eli Bendersky" wrote:
>
>
>
>
> On Fri, May 3, 2013 at 6:34 AM, Greg Ewing
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,
>>
>>
>> It's not a problem
On Fri, May 3, 2013 at 4:08 PM, Greg Ewing 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 work that way. (Command
On Sat, 04 May 2013 11:15:17 +1200
Greg Ewing 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 fundamental ways
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
a
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:
On Fri, May 3, 2013 at 7:14 AM, 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. When
> programmatica
On Fri, May 3, 2013 at 6:34 AM, Greg Ewing 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,
>>
>
> It's not a problem that getattr() has this behaviour.
> What I'm questioning is the
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 nam
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__"))
On Fri, May 3, 2013 at 9:57 AM, Ethan Furman 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 b
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 believ
On Thu, May 2, 2013 at 4:50 PM, Ethan Furman 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
>> pri
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~
_
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
Python-Dev@pytho
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
___
Py
On Thu, May 2, 2013 at 8:57 AM, Barry Warsaw 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.
>
Correct. Th
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 lis
On Thu, May 2, 2013 at 7:58 AM, Barry Warsaw 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 i
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 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 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
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(MoreColo
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
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 F
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 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 conflict
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 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 show
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 conte
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 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
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
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 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 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 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
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
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
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
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 = dbf.Table('storage.dbf', 'event_name C(50); date D; season
> SEASON')
>
> def retrieve_record(
On 28Apr2013 19:46, Ethan Furman 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 this:
>>> bool('F
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 bool
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 in
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 Issue
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 implementati
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 wa
[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 co
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
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 descriptors and callables) is that it means things like
> functools.parti
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 wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Season(3) is AUTUMN)
D
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 wou
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
> choo
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 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 t
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman 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 bike-shedding over the
API, or
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 Sun, Apr 28, 2013 at 7: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
In t
On 29/04/13 06:02, Guido van Rossum wrote:
My opinions added
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman 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 selectable via __call__
On 04/28/2013 02:29 PM, Antoine Pitrou wrote:
On Sun, 28 Apr 2013 13:02:11 -0700
Guido van Rossum 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 th
On Mon, 29 Apr 2013 08:28:34 +1000
Nick Coghlan wrote:
> On 29 Apr 2013 07:32, "Antoine Pitrou" wrote:
> >
> > On Sun, 28 Apr 2013 13:02:11 -0700
> > Guido van Rossum wrote:
> > >
> > > > - for the above two, how should they be included/excluded?
> > >
> > > IMO Everything should be enumerated
On 29 Apr 2013 07:32, "Antoine Pitrou" wrote:
>
> On Sun, 28 Apr 2013 13:02:11 -0700
> Guido van Rossum 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 Sun, 28 Apr 2013 13:02:11 -0700
Guido van Rossum 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 define regular
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, 33
My opinions added
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(
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 Enu
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
88 matches
Mail list logo
