On 02/25/2013 07:46 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> Again:
Repeating yourself doesn't help make the case. It does, however,
encourage me to reply.
Good! For a while I felt like I was talking to myself! ;)
> Definition of ENUMERATE
> 1 : to ascertain the numbe
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, yo
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
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/
Argum
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 Animal
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 :
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
Python-Dev@python.org
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 : l
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 i
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 ha
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://bu
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, t
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
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
...
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". Th
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
A
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 tha
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,
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
>differe
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 th
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 i
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 comp
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 e
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 s
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 pe
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
> 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 en
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 port
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
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 keys
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: rahulg...@live.ca
To: br...@python.org
D
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~
___
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 o
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 p
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
Python-Dev@python.org
http://mail.python.org/mailman/list
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
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.
Pers
>> 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
> 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
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
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 yo
On 2/25/2013 4:49 AM, Om Damani (ओम दम्माणी) wrote:
I wish to report the following bug.
Bugs should be reported on the issue tracker for the particular project.
http://www.scipy.org/
has a Report Bugs button at the top.
--
Terry Jan Reedy
___
Pytho
I wish to report the following bug.
Scipy v.11 library in python2.7 gives
spearmanrcorrel([1,2,3,4,5],[5,6,7,8,7]) = 0.8207 while scipy v.6 in
python2.5 gives spearmanr([1,2,3,4,5],[5,6,7,8,7]) = 0.825(which is
correct according to spearman correlation formula).
The spearman correlation for [1,2
On Mon, Feb 25, 2013 at 12:41 PM, daniel.holth
wrote:
> http://hg.python.org/peps/rev/7d2494f4cd0a
> changeset: 4772:7d2494f4cd0a
> user:Daniel Holth
> date:Sun Feb 24 21:41:40 2013 -0500
> summary:
> PEP-0427: clarify some implementation details.
>
> Hope it's OK to clarify t
44 matches
Mail list logo
