date:20130225

On Feb 24, 2013, at 07:32 PM, Ethan Furman wrote:

>I would still like the int subclass, though, as it would be an aid to me on
>the Python side.

I think you'll know what I'm going to say. :)

1) Usually, you won't need it (see the responses from people who don't care
about the value).

2) When you do, wrapping the item in int() doesn't seem too bad to me.

>>> from flufl.enum import make
>>> Colors = make('Colors', 'red green blue'.split())
>>> int(Colors.blue)
3

Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as


On 02/24/2013 08:14 PM, Barry Warsaw wrote:

On Feb 24, 2013, at 07:32 PM, Ethan Furman wrote:


I would still like the int subclass, though, as it would be an aid to me on
the Python side.


I think you'll know what I'm going to say. :)


Yup, saw that coming.  ;)



1) Usually, you won't need it (see the responses from people who don't care
about the value).


They are not me (or others like me (we do exist! we do! we do!).



2) When you do, wrapping the item in int() doesn't seem too bad to me.


If it was just once or twice, sure, but I use them as names for ints, which means I use them as ints, which means I 
would have a boat load of int() calls.


--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Eli Bendersky

> 2) When you do, wrapping the item in int() doesn't seem too bad to me.
>>
>
> If it was just once or twice, sure, but I use them as names for ints,
> which means I use them as ints, which means I would have a boat load of
> int() calls.
>

Personally I don't see "name for ints" as being the main use case for
enums. For preparing the draft PEP I ran through some stdlib, Twisted and
personal code and there are *tons* of places that just need a simple enum
for some sort of "state", meaningful return value, or similar. That's
really where you need enums the most, and really where their values don't
matter.

I prefer to have a good solution to one problem than a poorer solution that
tries to cover two unrelated problems. For "names for ints", Nick's named
value proposal seems more relevant, but why mix the two together?

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Skip Montanaro

>> If it was just once or twice, sure, but I use them as names for ints,
>> which means I use them as ints, which means I would have a boat load of
>> int() calls.
>
>
> Personally I don't see "name for ints" as being the main use case for enums.

Ethan seems to have a use case, even if it is using enums to
masquerade as true named constants.  Perhaps the correct solution is
to consider support for true constants in Python.  (I would be
surprised if there wasn't already at least one rejected or dormant PEP
regarding that topic.)

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On 02/25/2013 06:45 AM, Eli Bendersky wrote:

2) When you do, wrapping the item in int() doesn't seem too bad to me.

If it was just once or twice, sure, but I use them as names for ints, which
means I use them as ints, which means I
would have a boat load of int() calls.

Personally I don't see "name for ints" as being the main use case for enums.

I must admit I find it mildly amusing (but a lot frustrating) that we are talk about /enumerations/ not needing to be
based on ints. Checking out Merrian-Webster gives this:

Definition of ENUMERATE
1
: to ascertain the number of : count
2
: to specify one after another : list

Python even has an enumerate function, and what does it do? Gives us an int to
associate with some item in an iterator.

Now we're talking about adding an official Enum class, but the int portion is
unnecessary and a pain to use?

For preparing the draft PEP I ran through
some stdlib, Twisted and personal code and there are *tons* of places that just
need a simple enum for some sort of
"state", meaningful return value, or similar. That's really where you need
enums the most, and really where their values
don't matter.

And if, in those places, the enums were based on ints (or strings), would it hurt you? Because in the places where I,
as well as many others, use enums we *need* the int portion; and having to wrap the enum in an int() call is seven extra
keystrokes (minor) and a heap of visual clutter (major), destroying any value the enum was supposed to have.

I prefer to have a good solution to one problem than a poorer solution that
tries to cover two unrelated problems. For
"names for ints", Nick's named value proposal seems more relevant, but why mix
the two together?

Again:

Definition of ENUMERATE
1
: to ascertain the number of : count
2
: to specify one after another : list

--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Nick Coghlan

On Tue, Feb 26, 2013 at 12:53 AM, Skip Montanaro  wrote:
>>> If it was just once or twice, sure, but I use them as names for ints,
>>> which means I use them as ints, which means I would have a boat load of
>>> int() calls.
>>
>>
>> Personally I don't see "name for ints" as being the main use case for enums.
>
> Ethan seems to have a use case, even if it is using enums to
> masquerade as true named constants.  Perhaps the correct solution is
> to consider support for true constants in Python.  (I would be
> surprised if there wasn't already at least one rejected or dormant PEP
> regarding that topic.)

I don't think we need true constants - labelled values should suffice
for easier to debug magic numbers.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Feb 26, 2013, at 01:22 AM, Nick Coghlan wrote:

>I don't think we need true constants - labelled values should suffice
>for easier to debug magic numbers.

+1

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

Le Mon, 25 Feb 2013 06:45:27 -0800,
Eli Bendersky  a écrit :

> For preparing the draft PEP I ran through some stdlib, Twisted and
> personal code and there are *tons* of places that just need a simple
> enum for some sort of "state", meaningful return value, or similar.

There are also *tons* of public APIs which are now ints and would
benefit from becoming named values, but only if doing so doesn't break
compatibility (i.e. if they are still usable everywhere an int can be
used).

> I prefer to have a good solution to one problem than a poorer
> solution that tries to cover two unrelated problems. For "names for
> ints", Nick's named value proposal seems more relevant, but why mix
> the two together?

Because the whole functionality is not important enough to have two
slightly different variations on it in the stdlib? And why is it a
poorer solution exactly?

Really, there can be two kinds of enum values (or named values):
- int-alike values (usable everywhere an int is)
- str-alike values (usable everywhere a str is)

A third kind of value, which is partly int-compatible but not entirely,
sounds like a byzantine subtlety to me.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread R. David Murray

On Mon, 25 Feb 2013 07:12:03 -0800, Ethan Furman  wrote:
> I must admit I find it mildly amusing (but a lot frustrating) that we
> are talk about /enumerations/ not needing to be based on ints.
> Checking out Merrian-Webster gives this:
> 
> Definition of ENUMERATE
> 1
> : to ascertain the number of : count
> 2
> : to specify one after another : list

I believe they are taking the second definition.  Which would mean that,
at a minimum, if it is called an Enum the components should be orderable
according to the order of definition.  Also having an integer value
would decrease the surprise factor.

Either that, or name them something other than "enum".

If they aren't ints and they aren't orderable, it seems to me they are
just a set of names.  Which if we had labeled values, could be implemented
as...a set of names.

--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as


I've stated my reasons for why enums should be int based, and some of the 
problems with having them not be int-based.

Besides "we just don't need them int-based in these use-cases" what are the reasons for the strong desire to have them 
be valueless?


--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Built with VS2012 Express for desktop

2013-02-25 Thread rahul garg

Hello again!

Apparently the executable I built was broken. I tried with Debug configuration 
on x64 and got a python_d.exe successfully.
However trying to run "python_d.exe -m test" results in an error that cannot 
import "support" from test.


rahul

From: [email protected]
To: [email protected]
Date: Wed, 20 Feb 2013 03:03:14 -0500
CC: [email protected]
Subject: Re: [Python-Dev] Built with VS2012 Express for desktop




> Date: Tue, 19 Feb 2013 12:48:02 -0600
> Subject: Re: [Python-Dev] Built with VS2012 Express for desktop
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> 
> On Tue, Feb 19, 2013 at 12:37 PM, rahul garg  wrote:
> > Hi.
> >
> > I downloaded Python 3.3 source, opened up the solution in VS2012 Express for
> > Desktop and built the "python" subproject using "Release" and "x64"
> > configurations.  I now have a "python.exe" in the PCBuild/amd64 subfolder
> > that appears to be working as far as i can see.
> >
> > I have a few questions:
> > a) Is there a test suite that I can run to verify that the build is working
> > fine?
> Last I checked there are some issues, but most of the tests should
> pass. You would run "PCBuild\python.exe -m test" from the top level of
> your checkout to see this. It's also covered at
> http://docs.python.org/devguide/

Thanks! That page is what I should have looked for! 

> > b) I now intend to build some extensions (such as NumPy). Not sure if this
> > is the right list, but would I need to modify something in distutils to get
> > it working with VS2012?
> 
> Yes. You'll probably need to point distutils to the correct batch file
> that sets up a VS2012 build environment.

Thanks again!

rahul
  

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/rahulgarg%40live.ca   
 ___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:

>And if, in those places, the enums were based on ints (or strings), would it
>hurt you?  Because in the places where I, as well as many others, use enums
>we *need* the int portion; and having to wrap the enum in an int() call is
>seven extra keystrokes (minor) and a heap of visual clutter (major),
>destroying any value the enum was supposed to have.

Yes, I think enum values inheriting from int (or string) would hurt.

First, as your question implies, which is it?  int or str?  Some people want
int some want str.  It can't be both, and I don't think we need two enum
types.

It's a deeper question though, because if enum values inherited from int, then
people would expect things like ``Colors.red == 1`` to work.  Maybe you think
that doesn't look so bad, but that also implies:

>>> Colors = make('Colors', 'red green blue'.split())
>>> Animals = make('Animals', 'ant bee cat'.split())
>>> Colors.green == Animals.bee

and *that* I have a problem with.  While I generally recommend that that enum
values be comparable by identity, not by equality, lots of people will still
use `==` instead of `is`.  My preference:

def utter(animal):
if animal is Animals.cat:
print('meow')
elif animal is Animals.bee:
print('buzz')
elif animal is Animals.ant:
print('fphfft')

but commonly used:

def utter(animal):
if animal == Animals.cat:
print('meow')
elif animal == Animals.bee:
print('buzz')
elif animal == Animals.ant:
print('fphfft')

In both cases, I want ``utter(Colors.green)`` and ``utter(2)`` to fail.  In
the latter, if enum values are derived from ints, the second example will
succeed.  Currently, in both cases ``utter(Animals.cat)`` succeeds.

Even worse, if my library defines an Animals enum and your library defines a
different Animals enum, I do not want ``utter(YourAnimals.dog)`` to print
"meow" :).

I get that you think wrapping the value in int() is ugly.  I have a compromise
that you might find acceptable.  EnumValues already have .enum and .name
attributes, to give you the value's class and string name respectively.  It
would be trivial to add a .int attribute to return the value.

Thus if you want the int value, it would be easy enough to say
``Colors.green.int`` or ``Animals.bee.int``

https://bugs.launchpad.net/flufl.enum/+bug/1132859

Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Add PEP 445: The Argument Clinic DSL

On Feb 25, 2013, at 05:40 PM, brett.cannon wrote:

>http://hg.python.org/peps/rev/7aa92fb33436
>changeset:   4776:7aa92fb33436
>user:Brett Cannon 
>date:Mon Feb 25 11:39:56 2013 -0500
>summary:
>  Add PEP 445: The Argument Clinic DSL

I beat you with PEP 436. :)

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

Le Mon, 25 Feb 2013 11:37:29 -0500,
Barry Warsaw  a écrit :
> On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:
> 
> >And if, in those places, the enums were based on ints (or strings),
> >would it hurt you?  Because in the places where I, as well as many
> >others, use enums we *need* the int portion; and having to wrap the
> >enum in an int() call is seven extra keystrokes (minor) and a heap
> >of visual clutter (major), destroying any value the enum was
> >supposed to have.
> 
> Yes, I think enum values inheriting from int (or string) would hurt.
> 
> First, as your question implies, which is it?  int or str?  Some
> people want int some want str.  It can't be both, and I don't think
> we need two enum types.

I think we do "need" two enum types (as far as some enum mechanism is
needed).
str is better for most pure-Python uses, but int is necessary for a lot
of portability / compatibility requirements.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Skip Montanaro

> Besides "we just don't need them int-based in these use-cases" what are the
> reasons for the strong desire to have them be valueless?

Not sure about other people, but piggybacking off C semantics, while
convenient, reflects the limitations of the C implementation more than
anything else.  An enumeration, while you can count its items, doesn't
imply that the elements of the enumeration are naturally ordered.  If
you force an underlying association with integers, you imply ordering
where none naturally exists.   Given this:

critters = enum(DOG, CAT, RACCOON)

what does it mean that DOG < CAT?  Python 3 got rid of a lot of
nonsense comparisons:

~% python2.7
Python 2.7.3+ (2.7:df57314b93d1, Feb 24 2013, 23:25:05)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 < None
False
>>>
~% python3.3
Python 3.3.0+ (3.3:aae2bb2e3195, Feb 24 2013, 23:15:28)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 < None
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unorderable types: int() < NoneType()
>>>

It's not clear to me that sneaking artificial ordering in the back
door via enumerations is the correct thing to do.

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

Le Mon, 25 Feb 2013 10:44:33 -0600,
Skip Montanaro  a écrit :
> > Besides "we just don't need them int-based in these use-cases" what
> > are the reasons for the strong desire to have them be valueless?
> 
> Not sure about other people, but piggybacking off C semantics, while
> convenient, reflects the limitations of the C implementation more than
> anything else.  An enumeration, while you can count its items, doesn't
> imply that the elements of the enumeration are naturally ordered.  If
> you force an underlying association with integers, you imply ordering
> where none naturally exists.   Given this:
> 
> critters = enum(DOG, CAT, RACCOON)
> 
> what does it mean that DOG < CAT?

It doesn't mean anything, but so what? "DOG" > "CAT" doesn't mean much
either, and yet it's legal in Python.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Eli Bendersky

On Mon, Feb 25, 2013 at 8:56 AM, Antoine Pitrou  wrote:

> Le Mon, 25 Feb 2013 10:44:33 -0600,
> Skip Montanaro  a écrit :
> > > Besides "we just don't need them int-based in these use-cases" what
> > > are the reasons for the strong desire to have them be valueless?
> >
> > Not sure about other people, but piggybacking off C semantics, while
> > convenient, reflects the limitations of the C implementation more than
> > anything else.  An enumeration, while you can count its items, doesn't
> > imply that the elements of the enumeration are naturally ordered.  If
> > you force an underlying association with integers, you imply ordering
> > where none naturally exists.   Given this:
> >
> > critters = enum(DOG, CAT, RACCOON)
> >
> > what does it mean that DOG < CAT?
>
> It doesn't mean anything, but so what? "DOG" > "CAT" doesn't mean much
> either, and yet it's legal in Python.
>

"DOG" > "CAT" invokes lexicographical comparison between two strings, a
well-defined and sensical operations. It simply means that in a sorted list
of strings, "CAT" will come before "DOG". This is different from an
enumeration that attempts to (at least logically) restrict a value to a set
of pre-defined entities.

That said, I'm slowly starting to realize that enums try to impose a bit of
static typing on Python, which may be the cause for so much friction :-/

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread R. David Murray

On Mon, 25 Feb 2013 09:03:06 -0800, Eli Bendersky  wrote:
> On Mon, Feb 25, 2013 at 8:56 AM, Antoine Pitrou  wrote:
> 
> > Le Mon, 25 Feb 2013 10:44:33 -0600,
> > Skip Montanaro  a Ã©crit :
> > > > Besides "we just don't need them int-based in these use-cases" what
> > > > are the reasons for the strong desire to have them be valueless?
> > >
> > > Not sure about other people, but piggybacking off C semantics, while
> > > convenient, reflects the limitations of the C implementation more than
> > > anything else.  An enumeration, while you can count its items, doesn't
> > > imply that the elements of the enumeration are naturally ordered.  If
> > > you force an underlying association with integers, you imply ordering
> > > where none naturally exists.   Given this:
> > >
> > > critters = enum(DOG, CAT, RACCOON)
> > >
> > > what does it mean that DOG < CAT?
> >
> > It doesn't mean anything, but so what? "DOG" > "CAT" doesn't mean much
> > either, and yet it's legal in Python.
> >
> 
> "DOG" > "CAT" invokes lexicographical comparison between two strings, a
> well-defined and sensical operations. It simply means that in a sorted list
> of strings, "CAT" will come before "DOG". This is different from an
> enumeration that attempts to (at least logically) restrict a value to a set
> of pre-defined entities.
> 
> That said, I'm slowly starting to realize that enums try to impose a bit of
> static typing on Python, which may be the cause for so much friction :-/

If we had labeled values, none of this would be a problem.  If you wanted
ints, you could use labeled ints as the values.  If you wanted strings,
labeled strings.  If you wanted incommensurate, unsortable objects,
you could use labeled objects as the values.

--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread MRAB

On 2013-02-25 16:37, Barry Warsaw wrote:

On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:

And if, in those places, the enums were based on ints (or strings), would it
hurt you?  Because in the places where I, as well as many others, use enums
we *need* the int portion; and having to wrap the enum in an int() call is
seven extra keystrokes (minor) and a heap of visual clutter (major),
destroying any value the enum was supposed to have.

Yes, I think enum values inheriting from int (or string) would hurt.

First, as your question implies, which is it?  int or str?  Some people want
int some want str.  It can't be both, and I don't think we need two enum
types.

It's a deeper question though, because if enum values inherited from int, then
people would expect things like ``Colors.red == 1`` to work.  Maybe you think
that doesn't look so bad, but that also implies:

 >>> Colors = make('Colors', 'red green blue'.split())
 >>> Animals = make('Animals', 'ant bee cat'.split())
 >>> Colors.green == Animals.bee

and *that* I have a problem with.  While I generally recommend that that enum
values be comparable by identity, not by equality, lots of people will still
use `==` instead of `is`.  My preference:

def utter(animal):
 if animal is Animals.cat:
 print('meow')
 elif animal is Animals.bee:
 print('buzz')
 elif animal is Animals.ant:
 print('fphfft')

but commonly used:

def utter(animal):
 if animal == Animals.cat:
 print('meow')
 elif animal == Animals.bee:
 print('buzz')
 elif animal == Animals.ant:
 print('fphfft')

Would we be doing either of those? Surely we would be using a dict
instead, and what does a dict use, identity or equality?

In both cases, I want ``utter(Colors.green)`` and ``utter(2)`` to fail.  In
the latter, if enum values are derived from ints, the second example will
succeed.  Currently, in both cases ``utter(Animals.cat)`` succeeds.

Even worse, if my library defines an Animals enum and your library defines a
different Animals enum, I do not want ``utter(YourAnimals.dog)`` to print
"meow" :).

I get that you think wrapping the value in int() is ugly.  I have a compromise
that you might find acceptable.  EnumValues already have .enum and .name
attributes, to give you the value's class and string name respectively.  It
would be trivial to add a .int attribute to return the value.

Thus if you want the int value, it would be easy enough to say
``Colors.green.int`` or ``Animals.bee.int``

https://bugs.launchpad.net/flufl.enum/+bug/1132859

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Feb 25, 2013, at 05:19 PM, MRAB wrote:

>Would we be doing either of those? Surely we would be using a dict
>instead, and what does a dict use, identity or equality?

It's just a contrived example for email brevity.  In my real world examples,
the code inside the conditions can be much more complicated and not conducive
to dict usage.

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On 02/25/2013 08:44 AM, Skip Montanaro wrote:

Besides "we just don't need them int-based in these use-cases" what are the
reasons for the strong desire to have them be valueless?

Not sure about other people, but piggybacking off C semantics, while
convenient, reflects the limitations of the C implementation more than
anything else. An enumeration, while you can count its items, doesn't
imply that the elements of the enumeration are naturally ordered. If
you force an underlying association with integers, you imply ordering
where none naturally exists. Given this:

critters = enum(DOG, CAT, RACCOON)

what does it mean that DOG < CAT? Python 3 got rid of a lot of
nonsense comparisons:

I certainly agree that there are some cases where an enumeration doesn't have any natural ordering; surely we can also
agree that there are some that do? This is why I think our new Enum should have a selectable underlying type: int,
bitmask (int is disguise ;), str, float -- whatever the developer needs. If ordering is not important, use str as your
backend, or we could even have a truly valueless backend for those occasions.

As far as not needing more than one type of enum: enumerations are used for counting and/or listing -- how many ways
can we count? int, float, complex, decimal, fraction; how many ways can we list? list, tuple, array.

I have no problem with having a valueless enum, or even with having it be the default -- so long as I can choose to use
a SequenceEnum (or IntEnum, whatever we call it) then I'll be happy.

--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On 02/25/2013 08:37 AM, Barry Warsaw wrote:

On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:

And if, in those places, the enums were based on ints (or strings), would it
hurt you?  Because in the places where I, as well as many others, use enums
we *need* the int portion; and having to wrap the enum in an int() call is
seven extra keystrokes (minor) and a heap of visual clutter (major),
destroying any value the enum was supposed to have.

Yes, I think enum values inheriting from int (or string) would hurt.

First, as your question implies, which is it?  int or str?  Some people want
int some want str.  It can't be both, and I don't think we need two enum
types.

I can see enums of at least three different types being useful: int, str, and 
bitmask; a valueless enum would be a fourth.

It's a deeper question though, because if enum values inherited from int, then
people would expect things like ``Colors.red == 1`` to work.  Maybe you think
that doesn't look so bad, but that also implies:

I do expect that to work.

 >>> Colors = make('Colors', 'red green blue'.split())
 >>> Animals = make('Animals', 'ant bee cat'.split())
 >>> Colors.green == Animals.bee

But this I don't, and in both mine, Ted's, and Alex's versions enums from different groups do not compare equal, 
regardless of the underlying value.  Of course, this does have the potential problem of `green == 1 == bee` but not 
`green == bee` which would be a problem with set and dicts -- but I'm the only one who has brought up that issue.

I get that you think wrapping the value in int() is ugly.  I have a compromise
that you might find acceptable.  EnumValues already have .enum and .name
attributes, to give you the value's class and string name respectively.  It
would be trivial to add a .int attribute to return the value.

Thus if you want the int value, it would be easy enough to say
``Colors.green.int`` or ``Animals.bee.int``

Well, it certainly isn't as ugly, and isn't as hard on the wrists.  If your's is the package that makes it in the stdlib 
I would certainly appreciate the modification.

However, as I replied to Skip, I think a stdlib solution should meet many needs, and sometimes (often, for some people 
;) those needs will be better served by an int-based or str-based enum.

--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Feb 25, 2013, at 09:35 AM, Ethan Furman wrote:

>>  >>> Colors = make('Colors', 'red green blue'.split())
>>  >>> Animals = make('Animals', 'ant bee cat'.split())
>>  >>> Colors.green == Animals.bee
>
>But this I don't, and in both mine, Ted's, and Alex's versions enums from
>different groups do not compare equal, regardless of the underlying value.
>Of course, this does have the potential problem of `green == 1 == bee` but
>not `green == bee` which would be a problem with set and dicts -- but I'm the
>only one who has brought up that issue.

Right, but my point is that if isinstance(Colors.green, int) then a reasonable
interpretation is that enum values will compare equal against other ints.  It
seems weird to me that enum values *are* ints but aren't substitutable with
ints (e.g. comparable against other ints including other subclasses of ints).

>However, as I replied to Skip, I think a stdlib solution should meet many
>needs, and sometimes (often, for some people ;) those needs will be better
>served by an int-based or str-based enum.

Maybe.  I don't think a stdlib solution has to meet *all* needs.  I think
named values plus int-interoperable enums will solve almost all use cases.

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On 02/25/2013 10:05 AM, Barry Warsaw wrote:

On Feb 25, 2013, at 09:35 AM, Ethan Furman wrote:

  >>> Colors = make('Colors', 'red green blue'.split())
  >>> Animals = make('Animals', 'ant bee cat'.split())
  >>> Colors.green == Animals.bee

But this I don't, and in both mine, Ted's, and Alex's versions enums from
different groups do not compare equal, regardless of the underlying value.
Of course, this does have the potential problem of `green == 1 == bee` but
not `green == bee` which would be a problem with set and dicts -- but I'm the
only one who has brought up that issue.

Right, but my point is that if isinstance(Colors.green, int) then a reasonable
interpretation is that enum values will compare equal against other ints.  It
seems weird to me that enum values *are* ints but aren't substitutable with
ints (e.g. comparable against other ints including other subclasses of ints).

That is certainly a valid point.  I will admit to being unhappy with the whole dict/set issue; I'm considering making my 
enums unhashable -- then if one wants them in a dict, one can take the string or int value and add it that way.

However, as I replied to Skip, I think a stdlib solution should meet many
needs, and sometimes (often, for some people ;) those needs will be better
served by an int-based or str-based enum.

Maybe.  I don't think a stdlib solution has to meet *all* needs.  I think
named values plus int-interoperable enums will solve almost all use cases.

Hey, I think I just had a light-bulb moment:  have the enum implement __index__ -- that will solve my use-case of using 
them for list indices.

Dumb question, but are flufl.enums ordered?  That's also an important use case.

--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Mon, 25 Feb 2013 09:03:06 -0800
Eli Bendersky  wrote:
> 
> "DOG" > "CAT" invokes lexicographical comparison between two strings, a
> well-defined and sensical operations. It simply means that in a sorted list
> of strings, "CAT" will come before "DOG". This is different from an
> enumeration that attempts to (at least logically) restrict a value to a set
> of pre-defined entities.

No, it's not different. Like there are use cases for ordered
comparisons of strings, there are cases for ordered comparisons of
enums.
For example, if I have an enum representing SIP or HTTP response codes,
it is perfectly reasonable to write:

if code < 200:
# temporary response
...
elif code < 400:
# successful final response
...
else:
# final error response:
...

Really, there's no justification for claiming an enum should never
compare to anything else. It's entirely application-dependent.

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Mon, 25 Feb 2013 13:05:02 -0500
Barry Warsaw  wrote:
> 
> Maybe.  I don't think a stdlib solution has to meet *all* needs.  I think
> named values plus int-interoperable enums will solve almost all use cases.

Being int-interoperable without comparing with ints is completely
bonkers.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as


On 02/25/2013 10:49 AM, Antoine Pitrou wrote:

On Mon, 25 Feb 2013 09:03:06 -0800
Eli Bendersky  wrote:


"DOG" > "CAT" invokes lexicographical comparison between two strings, a
well-defined and sensical operations. It simply means that in a sorted list
of strings, "CAT" will come before "DOG". This is different from an
enumeration that attempts to (at least logically) restrict a value to a set
of pre-defined entities.


No, it's not different. Like there are use cases for ordered
comparisons of strings, there are cases for ordered comparisons of
enums.
For example, if I have an enum representing SIP or HTTP response codes,
it is perfectly reasonable to write:

 if code < 200:
 # temporary response
 ...
 elif code < 400:
 # successful final response
 ...
 else:
 # final error response:
 ...

Really, there's no justification for claiming an enum should never
compare to anything else. It's entirely application-dependent.


+1
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as


Antoine, question for you:

Do you think enums from different groupings should compare equal?

If no, how would you propose to handle the following:

8<
--> import yaenum

--> class Color(yaenum.Enum):
... black
... red
... green
... blue
...

--> class Literature(yaenum.Enum):
...scifi
...fantasy
...mystery
...pop
...

--> Color.black
Color('black', value=0)

--> Literature.scifi
Literature('scifi', value=0)

--> black = Color.black

--> scifi = Literature.scifi

--> black == 0
True

--> hash(black)
0

--> scifi == 0
True

--> hash(scifi)
0

--> black == scifi
False

--> hash(0)
0

--> huh = dict()
--> huh[black] = 9
--> huh
{Color('black', value=0): 9}

--> huh[0]
9
--> huh[scifi]
Traceback (most recent call last):
  File "", line 1, in 
KeyError: Literature('scifi', value=0)

--> huh[scifi] = 11
--> huh
{Color('black', value=0): 9, Literature('scifi', value=0): 11}

--> huh[0]
9

--> del huh[0]
--> huh[0]
11

8<

I do not think enums from different classes should compare equal.

I see two ways around the above issue:

  1) make enums unhashable, forcing the user to pick a hash method;

  2) make the hash based on something else (like the enum's name) in which case
 the enum would not be /completely/ interoperable, even though it is a 
subclass
 of int
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Mon, 25 Feb 2013 11:34:35 -0800
Ethan Furman  wrote:
> Antoine, question for you:
> 
> Do you think enums from different groupings should compare equal?

Equality should be mostly transitive so, yes, I think they should.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7.4 and 3.2.4

2013-02-25 Thread Benjamin Peterson

2013/2/23 Perica Zivkovic :
> Hi there,
>
> like posted here:
> https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.python/xXij443PM6I
>
> I'm curious to find out are there any timelines when 2.7.4 and 3.2.4 will be
> available.

As soon as there is a releasable 2.7 tree. Unfortunately, the XML
security issue doesn't seem to be getting closer to resolution and we
have tens of release blockers.

>
> I was kinda waiting for it to release new Portable Python so now I'm just
> curious should I wait bit more and release on this python base or should I
> go for 2.7.3 and 3.2.3


-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Feb 25, 2013, at 10:25 AM, Ethan Furman wrote:

>Hey, I think I just had a light-bulb moment: have the enum implement
>__index__ -- that will solve my use-case of using them for list indices.

They don't currently, but I think it's reasonable, given that they already
support __int__.

https://bugs.launchpad.net/flufl.enum/+bug/1132972

>Dumb question, but are flufl.enums ordered?  That's also an important use
>case.

Kind of.  Ordered comparisons are explicitly not supported, but iteration over
the Enum is guaranteed to be returned in int-value order.

One thing I've been thinking about is allowing you to override the EnumValue
class that the metaclass uses.  In that case, if you really wanted ordered
comparisons, you could override __lt__() and friends in a custom enum-value
class.  I haven't quite worked out in my mind how that would look, but I have
a bug to track the feature request:

https://bugs.launchpad.net/flufl.enum/+bug/1132976

Heck, that might even allow you to implement int-derived enum values if you
really wanted them .

Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Tim Delaney

On 26 February 2013 07:32, Barry Warsaw  wrote:

> One thing I've been thinking about is allowing you to override the
> EnumValue
> class that the metaclass uses.  In that case, if you really wanted ordered
> comparisons, you could override __lt__() and friends in a custom enum-value
> class.  I haven't quite worked out in my mind how that would look, but I
> have
> a bug to track the feature request:
>
> https://bugs.launchpad.net/flufl.enum/+bug/1132976
>
> Heck, that might even allow you to implement int-derived enum values if you
> really wanted them .
>

You're starting to tread in an area that I investigated, did an
implementation of, and then started moving away from due to a different
approach (delegating to the methods in the owning Enum class when accessing
EnumValue attribtues).

I haven't touched my implementation for a couple of weeks now - been busy
with other stuff and I got a bit fatigued with the discussion so I decided
to wait until things had settled a bit. Hasn't happened yet ... ;)

I'm actually in a quandry about what way I want my enums to go. I think
each enum should have an ordinal based on the order it is defined, and
should be ordered by that ordinal. But (whether or not it inherits from int
- I'm ignoring string enums here) should __int__ and __index__ return the
ordinal, or the assigned int value (if it has one)? There are arguments
both ways. My current implementation doesn't have an ordinal at all (except
by accident in the trivial case). That was when I decided to put it aside
for a while and see where the discussion went.

Tim Delaney
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Glyph


On Feb 25, 2013, at 12:32 PM, Barry Warsaw  wrote:

>> Dumb question, but are flufl.enums ordered?  That's also an important use
>> case.
> 
> Kind of.  Ordered comparisons are explicitly not supported, but iteration over
> the Enum is guaranteed to be returned in int-value order.

Sorry to jump in to a random leaf of this thread, but there is such a barrage 
here I cannot find the beginning :).

I can see in  that 
Twisted is mentioned; it should probably reference 
 
and  
since we actually implemented a thing as well.

(You can order constants by sorting them; off the top of my head, 
NamedConstant, ValueConstant, and FlagConstant all probably behave differently.)

-g___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Greg Ewing


Ethan Furman wrote:
I must admit I find it mildly amusing (but a lot frustrating) that we 
are talk about /enumerations/ not needing to be based on ints.  Checking 
out Merrian-Webster gives this:


Definition of ENUMERATE
1
: to ascertain the number of : count
2
: to specify one after another : list


It depends on what you mean by "based on ints". Pascal
enums are using the second definition here: the values
have ints associated with them, but are not themselves
ints.

There are really two different use cases. Sometimes you
want to have values that are directly substitutable for ints;
other times you would rather not, so as to catch mistakes
more easily.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as


On 02/25/2013 09:35 AM, Ethan Furman wrote:

But this I don't, and in both mine, Ted's, and Alex's versions [. . .]


My sincerest apologies to Tim Delaney (aka 'Ted') for messing up his name.

--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as


On 02/25/2013 03:22 PM, Greg Ewing wrote:

Ethan Furman wrote:

I must admit I find it mildly amusing (but a lot frustrating) that we are talk 
about /enumerations/ not needing to be
based on ints.  Checking out Merrian-Webster gives this:

Definition of ENUMERATE
1
: to ascertain the number of : count
2
: to specify one after another : list


It depends on what you mean by "based on ints". Pascal
enums are using the second definition here: the values
have ints associated with them, but are not themselves
ints.

There are really two different use cases. Sometimes you
want to have values that are directly substitutable for ints;
other times you would rather not, so as to catch mistakes
more easily.


I agree.  I think whichever enum ends up in the stdlib should support both
types (and possibly a couple other variations).

--
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Greg Ewing

Barry Warsaw wrote:

>>> Colors = make('Colors', 'red green blue'.split())
>>> Animals = make('Animals', 'ant bee cat'.split())
>>> Colors.green == Animals.bee

The currently suggested solution to that seems to be to
make comparison non-transitive, so that Colors.green == 1
and Animals.bee == 1 but Colors.green != Animals.bee.
And then hope that this does not create a quantum black
hole that sucks us all into a logical singularity...

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Announcing PEP 436: The Argument Clinic DSL

2013-02-25 Thread Larry Hastings



Following up on a conversation on python-dev from last December:

   http://mail.python.org/pipermail/python-dev/2012-December/122920.html

I'm pleased to announced PEP 436, proposing Argument Clinic for adoption 
into the CPython source tree.


   http://www.python.org/dev/peps/pep-0436/


Argument Clinic itself hasn't changed much in the intervening three 
months; I did add a prototype extension mechanism for adding user types 
at runtime, and I allow writing the generated code to a separate file.  
The PEP is adopted out of the "clinic.txt" included with the prototype, 
updated and with a new rationale.


For what it's worth, the bug tracker issue is here:

   http://bugs.python.org/issue16612

I'm guessing python-dev is the right place for the ten-thousand-foot 
view topics: the merits of the specific proposed DSL syntax, the 
possible runtime extension API, and the approach as a whole.  So for now 
let's just use the bug tracker issue for code reviews and the like.


The prototype implementation is checked in here:

   https://bitbucket.org/larry/python-clinic/

as well as being posted to the above issue on the tracker in patch form.


I look forward to your comments,


//arry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Feb 26, 2013, at 10:04 AM, Tim Delaney wrote:

>You're starting to tread in an area that I investigated, did an
>implementation of, and then started moving away from due to a different
>approach (delegating to the methods in the owning Enum class when accessing
>EnumValue attribtues).

At first glance, this turns out to be pretty easy in flufl.enum.

https://code.launchpad.net/~barry/flufl.enum/lp1132976/+merge/150472

I'm not sure it's a good idea or whether it meets a real need, and you could
bikeshed on the name of the magic attribute, but I think this shows that it's
possible and doesn't complicate the implementation that much.

Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

2013-02-25 Thread Stephen J. Turnbull

Ethan Furman writes:

 > Again:

Repeating yourself doesn't help make the case.  It does, however,
encourage me to reply.

 > Definition of ENUMERATE
 > 1 : to ascertain the number of : count
 > 2 : to specify one after another : list

You say you need the value as an integer; when you evaluate, you are
neither counting nor listing.  Note that in both counting and listing
the object of the operation is not an element.  It is a set, and set
membership is the most important aspect of the elements for that
purpose.  The values of the elements (including whether they even have
a value) is not relevant to either of those operations.

On the other hand, if you *are* going to access (constant!) values by
name, I don't see any reason to restrict the domain to integers.  Nor
do such named constants need to be members of any set in many cases.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as