Op 2006-01-14, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
If you
want to argue that the builtin sets should do that, you can - but
that's unrelated to the question of how the comparison operators
behave for the rest of the bulitin types.
What I argue is
Antoon Pardon [EMAIL PROTECTED] writes:
If you
want to argue that the builtin sets should do that, you can - but
that's unrelated to the question of how the comparison operators
behave for the rest of the bulitin types.
What I argue is that there is no single order for a specific type.
I
Mike Meyer wrote:
[EMAIL PROTECTED] writes:
try:
return a == b
except TypeError:
return a is b
This isn't easy. It's an ugly hack you have to use everytime you
want to iterate through a heterogenous set doing equality tests.
I wouldn't define this as an ugly hack. These are
Noam Raphael [EMAIL PROTECTED] writes:
Also note that using the current behaviour, you can't easily
treat objects that do define a meaningful value comparison, by
identity.
Yes you can. Just use the is operator.
Sorry, I wasn't clear enough. In treating I meant how containers
treat the objects
Mike Meyer wrote:
Noam Raphael [EMAIL PROTECTED] writes:
Also note that using the current behaviour, you can't easily
treat objects that do define a meaningful value comparison, by
identity.
Yes you can. Just use the is operator.
Sorry, I wasn't clear enough. In treating I meant how
Noam Raphael [EMAIL PROTECTED] writes:
Mike Meyer wrote:
Noam Raphael [EMAIL PROTECTED] writes:
Also note that using the current behaviour, you can't easily
treat objects that do define a meaningful value comparison, by
identity.
Yes you can. Just use the is operator.
Sorry, I wasn't clear
Op 2006-01-12, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]:
[ BIG CUT ]
I'm going to drop this part. I disagree with you and think
I can show some of your argument invalid. Hoever I also doubt
something
Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]:
Now you can take the practical option and decide that
Antoon Pardon [EMAIL PROTECTED] writes:
There is a use case for things like 1 (1,3) making sense and denoting
a total order. When you have a hetergenous list, having a total order
makes it possible to sort the list which will make it easier to
weed out duplicates. So why don't you demand a
Op 2006-01-12, Paul Rubin schreef http:
Antoon Pardon [EMAIL PROTECTED] writes:
There is a use case for things like 1 (1,3) making sense and denoting
a total order. When you have a hetergenous list, having a total order
makes it possible to sort the list which will make it easier to
weed out
Antoon Pardon [EMAIL PROTECTED] writes:
The bisect module doesn't have an alternate comparison function
neither has the heapqueue module.
They could be extended. Care to enter a feature request?
1) Python could provide a seperare total ordering, maybe with operators
like '|' and '|' and
Op 2006-01-12, Paul Rubin schreef http:
Antoon Pardon [EMAIL PROTECTED] writes:
The bisect module doesn't have an alternate comparison function
neither has the heapqueue module.
They could be extended. Care to enter a feature request?
Not really because IMO this is the wrong approach.
1)
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]:
Now you can
Op 2006-01-10, Christopher Subich schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2006-01-10, Peter Decker schreef [EMAIL PROTECTED]:
I don't see the two comparisons as equivalent at all. If two things
are different, it does not follow that they can be ranked.
That a b returns false
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
There is no way in python now to throw an exception when you
think comparing your object to some very different object
is just meaningless and using such an object in a container
that can be searched
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]:
Now you can take the practical option and decide that programmatically
it make no sense to compare a specific couple of values and throw an
exception in this case, but it doesn't matter much which test
Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]:
Now you can take the practical option and decide that programmatically
it make no sense to compare a specific couple of values and throw an
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]:
Now you can take the practical option and decide that programmatically
it make no sense to compare a
Mike Meyer wrote:
Steven Bethard writes:
Not to advocate one way or the other, but how often do you use
heterogeneous containers?
Pretty much everything I do has heterogenous containers of some sort
or another.
Sorry, I should have been a little more specific. I meant heterogeneous
Steven Bethard [EMAIL PROTECTED] writes:
Mike Meyer wrote:
Steven Bethard writes:
Not to advocate one way or the other, but how often do you use
heterogeneous containers?
Pretty much everything I do has heterogenous containers of some sort
or another.
Sorry, I should have been a little more
Mike Meyer wrote:
My question is, what reasons are left for leaving the current default
equality operator for Py3K, not counting backwards-compatibility?
(assume that you have idset and iddict, so explicitness' cost is only
two characters, in Guido's example)
Yes. Searching for items in
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]:
[EMAIL PROTECTED] writes:
My question is, what reasons are left for leaving the current default
equality operator for Py3K, not counting backwards-compatibility?
(assume that you have idset and iddict, so explicitness' cost is only
two
Antoon Pardon [EMAIL PROTECTED] writes:
Yes. Searching for items in heterogenous containers. With your change
in place, the in operator becomes pretty much worthless on
containers of heterogenous objects. Ditto for container methods that
do searches for equal members. Whenever you compare two
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] writes:
You could fix this by patching all the appropriate methods. But then
how do you describe their behavior, without making some people expect
that it will raise an exception if they pass it incomparable
On 9 Jan 2006 14:40:45 -0800, [EMAIL PROTECTED] wrote:
Hello,
Guido has decided, in python-dev, that in Py3K the id-based order
comparisons will be dropped. This means that, for example, {} []
will raise a TypeError instead of the current behaviour, which is
returning a value which is, really,
Op 2006-01-10, Fuzzyman schreef [EMAIL PROTECTED]:
On 9 Jan 2006 14:40:45 -0800, [EMAIL PROTECTED] wrote:
Hello,
Guido has decided, in python-dev, that in Py3K the id-based order
comparisons will be dropped. This means that, for example, {} []
will raise a TypeError instead of the current
On 10 Jan 2006 13:33:20 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
IMO if they aren't of the same type then the answer to:
a b
is just as obviously False as
a == b
Yet how things are proposed now, the first will throw an exception
and the latter will return False.
I don't see the
Op 2006-01-10, Peter Decker schreef [EMAIL PROTECTED]:
On 10 Jan 2006 13:33:20 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
IMO if they aren't of the same type then the answer to:
a b
is just as obviously False as
a == b
Yet how things are proposed now, the first will throw an
Antoon Pardon wrote:
Op 2006-01-10, Peter Decker schreef [EMAIL PROTECTED]:
I don't see the two comparisons as equivalent at all. If two things
are different, it does not follow that they can be ranked.
That a b returns false doesn't imply that a and b can be ranked.
take sets. set([1,2])
Peter Decker wrote:
On 10 Jan 2006 13:33:20 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
IMO if they aren't of the same type then the answer to:
a b
is just as obviously False as
a == b
Yet how things are proposed now, the first will throw an exception
and the latter
Antoon Pardon [EMAIL PROTECTED] writes:
There is no way in python now to throw an exception when you
think comparing your object to some very different object
is just meaningless and using such an object in a container
that can be searched via the in operator.
I claim that comparing for
Can you provide a case where having a test for equality throw an exception
is actually useful? Yes. It will be useful because: 1. The bug of not
finding a key in a dict because it was implicitly hashed by identity and not
by value, would not have happened. 2. You wouldn't get the weird
It seems to me that both Mike's and Fuzzyman's objections were that
sometimes you want the current behaviour, of saying that two objects
are equal if they are: 1. the same object or 2. have the same value
(when it's meaningful). In both cases this can be accomplished pretty
easily: You can do it
[EMAIL PROTECTED] writes:
It seems to me that both Mike's and Fuzzyman's objections were that
sometimes you want the current behaviour, of saying that two objects
are equal if they are: 1. the same object or 2. have the same value
(when it's meaningful). In both cases this can be accomplished
Mike Meyer wrote:
[EMAIL PROTECTED] writes:
My question is, what reasons are left for leaving the current default
equality operator for Py3K, not counting backwards-compatibility?
(assume that you have idset and iddict, so explicitness' cost is only
two characters, in Guido's example)
Steven Bethard [EMAIL PROTECTED] writes:
Not to advocate one way or the other, but how often do you use
heterogeneous containers?
Pretty much everything I do has heterogenous containers of some sort
or another. SQL queries made to DP API compliant modules return
homogenous lists of heterogenous
[EMAIL PROTECTED] writes:
My question is, what reasons are left for leaving the current default
equality operator for Py3K, not counting backwards-compatibility?
(assume that you have idset and iddict, so explicitness' cost is only
two characters, in Guido's example)
Yes. Searching for items
37 matches
Mail list logo
