Re: [Python-3000] None in Comparisons

On Wed, Nov 12, 2008 at 3:07 AM, Greg Ewing <[EMAIL PROTECTED]> wrote: > M.-A. Lemburg wrote: > >> The difference is that None is a singleton, so the set of all >> None type instances is {None}. You always have an intuitive total order >> relation on one element sets: the identity relation. > > I d

Re: [Python-3000] None in Comparisons

On Tue, Nov 11, 2008 at 7:06 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Why was the special case for None being "smaller" than all other > objects in Python removed from Python 3.0 ? (see object.c in Py2.x) > It wasn't true in Python 2.5, either. Observe: Cashew:~/pokersleuth/tracker$ pytho

Re: [Python-3000] None in Comparisons: None vs. float("inf")

Be glad you're not programming in C++ then, where trying to sort NaN can cause segfaults! More seriously, I think using the following function as the sort key will make sort do what you want: def SortNoneFirstAndNanLast(x): if x is None: return (1, x) if isnan(x): return (3, x) retu

Re: [Python-3000] None in Comparisons: None vs. float("inf")

I think the behavior of NaN in comparisons is more confusing: >>> sorted([1,nan,2]) [1, nan, 2] >>> sorted([2,nan,1]) [2, nan, 1] >>> sorted([2,None,1]) Traceback (most recent call last): File "", line 1, in sorted([2,None,1]) TypeError: unorderable types: NoneType() < int() At least the th

Re: [Python-3000] None in Comparisons: None vs. float("inf")

[M.-A. Lemburg] > ... > So far, I haven't heard a single argument for why not having None > participate in an ordering scheme is a good strategy to use, except > that it's pure. I've tracked down plenty of program logic errors that would have been discovered more easily if comparing None to (mostl

Re: [Python-3000] None in Comparisons: None vs. float("inf")

On Thu, Nov 13, 2008 at 3:35 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Anyway, like I said: it's one more thing to add to the list of > surprises in Python 3.0. I'm happy to do so. I expect that over time it won't be an issue. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Re: [Python-3000] None in Comparisons: None vs. float("inf")

On 2008-11-12 16:10, Antoine Pitrou wrote: > M.-A. Lemburg egenix.com> writes: >> The difference is that None is a singleton, so the set of all >> None type instances is {None}. You always have an intuitive total order >> relation on one element sets: the identity relation. > > But it's not what

Re: [Python-3000] None in Comparisons

Marcin 'Qrczak' Kowalczyk wrote: 2008/11/11 Greg Ewing <[EMAIL PROTECTED]>: It would be possible to implement this convention in the sort method Until someone wishes to sort a list of some objects by key, where the keys can be (1, None) compared with (1, 3). Yes, I thought of that shortly a

Re: [Python-3000] None in Comparisons

Bruce Leban wrote: > > > On Tue, Nov 11, 2008 at 2:00 PM, Greg Ewing <[EMAIL PROTECTED] > > wrote: > > M.-A. Lemburg wrote: > > On 2008-11-11 14:28, Antoine Pitrou wrote: > > But why should "n/a" (or "missing", or "undefined") imply >

Re: [Python-3000] None in Comparisons

2008/11/11 Greg Ewing <[EMAIL PROTECTED]>: > It would be possible to implement this convention in the > sort method, without making it a feature of comparisons > in general. Until someone wishes to sort a list of some objects by key, where the keys can be (1, None) compared with (1, 3). This will

Re: [Python-3000] None in Comparisons

On Tue, Nov 11, 2008 at 2:00 PM, Greg Ewing <[EMAIL PROTECTED]>wrote: > M.-A. Lemburg wrote: > >> On 2008-11-11 14:28, Antoine Pitrou wrote: >> >> But why should "n/a" (or "missing", or "undefined") imply "smaller than >>> everything else"? >>> >> >> It's just a convention based on viewing None a

Re: [Python-3000] None in Comparisons

On Tue, Nov 11, 2008 at 10:20 AM, Tim Peters <[EMAIL PROTECTED]> wrote: > [M.-A. Lemburg] >> ... >> That's fine. I'm just talking about the special case for None that >> has existed in Python for years - and for a good reason. > > That's overstating it a bit ;-) In Python 1.5.1, comparisons were >

Re: [Python-3000] None in Comparisons: None vs. float("inf")

M.-A. Lemburg egenix.com> writes: > > The difference is that None is a singleton, so the set of all > None type instances is {None}. You always have an intuitive total order > relation on one element sets: the identity relation. But it's not what you are asking for. You are asking for None to su

Re: [Python-3000] None in Comparisons

M.-A. Lemburg wrote: The difference is that None is a singleton, so the set of all None type instances is {None}. You always have an intuitive total order relation on one element sets: the identity relation. I don't see this having much practical consequence, though, since sorting members of a

Re: [Python-3000] None in Comparisons

On 2008-11-12 00:09, Antoine Pitrou wrote: > M.-A. Lemburg egenix.com> writes: > None > None >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: unorderable types: NoneType() > NoneType() > None != None >> False >> >> Two values that compare equal to each other (a

Re: [Python-3000] None in Comparisons

On 2008-11-11 19:20, Tim Peters wrote: > [M.-A. Lemburg] >> ... >> That's fine. I'm just talking about the special case for None that >> has existed in Python for years - and for a good reason. > > That's overstating it a bit ;-) In Python 1.5.1, comparisons were > changed so that objects of nume

Re: [Python-3000] None in Comparisons

M.-A. Lemburg wrote: On 2008-11-11 14:28, Antoine Pitrou wrote: But why should "n/a" (or "missing", or "undefined") imply "smaller than everything else"? It's just a convention based on viewing None as "nothing" or the empty set. It would be possible to implement this convention in the sort

Re: [Python-3000] None in Comparisons

M.-A. Lemburg egenix.com> writes: > > >>> None > None > Traceback (most recent call last): > File "", line 1, in > TypeError: unorderable types: NoneType() > NoneType() > >>> None != None > False > > Two values that compare equal to each other (and are in fact identical), > yet cannot be comp

Re: [Python-3000] None in Comparisons

M.-A. Lemburg wrote: And here's another one: ... Two values that compare equal to each other (and are in fact identical), yet cannot be compared less-than or greater-than. That's not particularly surprising -- complex numbers have been like that for a long time. The only surprise, if any, is t

Re: [Python-3000] None in Comparisons

On 2008-11-11 18:09, Guido van Rossum wrote: > We're not going to add the "feature" back that None compares smaller > than everything. It's a slippery slope that ends with all operations > involving None returning None -- I've seen a proposal made in all > earnestness requesting that None+42 == Non

Re: [Python-3000] None in Comparisons

[M.-A. Lemburg] > ... > That's fine. I'm just talking about the special case for None that > has existed in Python for years - and for a good reason. That's overstating it a bit ;-) In Python 1.5.1, comparisons were changed so that objects of numeric types compared smaller than objects of non-num

Re: [Python-3000] None in Comparisons

M.-A. Lemburg wrote: Why was the special case for None being "smaller" than all other objects in Python removed from Python 3.0 ? (see object.c in Py2.x) For one thing, it is only smallest when it controls the comparison. >>> class c(object): ... def __lt__(s,o): return True ... >>> cc = c()

Re: [Python-3000] None in Comparisons

We're not going to add the "feature" back that None compares smaller than everything. It's a slippery slope that ends with all operations involving None returning None -- I've seen a proposal made in all earnestness requesting that None+42 == None, None() == None, and so on. This Nonesense was wise

Re: [Python-3000] None in Comparisons

On 2008-11-11 15:22, Daniel Stutzbach wrote: > On Tue, Nov 11, 2008 at 7:06 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > >> Why was the special case for None being "smaller" than all other >> objects in Python removed from Python 3.0 ? (see object.c in Py2.x) >> > > It wasn't true in Python 2.5

Re: [Python-3000] None in Comparisons

Le Tuesday 11 November 2008 15:21:03 M.-A. Lemburg, vous avez écrit : > Because None is already special, has had this feature for a very > long time (...) Yeah, Python3 breaks compatibility by removing old dummy behaviour like comparaison between bytes and characters, or between an integer an Non

Re: [Python-3000] None in Comparisons

M.-A. Lemburg egenix.com> writes: > > NULLs are a fact in life, not only in SQL, but also in numerics and > statistics. You often don't want a complex calculation or query to > fail just because a few input values are not available. But it only works in the case where you only do comparisons, an

Re: [Python-3000] None in Comparisons

On 2008-11-11 15:07, Barry Warsaw wrote: > On Nov 11, 2008, at 8:54 AM, M.-A. Lemburg wrote: > >> On 2008-11-11 14:28, Antoine Pitrou wrote: >>> M.-A. Lemburg egenix.com> writes: Why was the special case for None being "smaller" than all other objects in Python removed from Python 3.0 ?

Re: [Python-3000] None in Comparisons

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 11, 2008, at 8:54 AM, M.-A. Lemburg wrote: On 2008-11-11 14:28, Antoine Pitrou wrote: M.-A. Lemburg egenix.com> writes: Why was the special case for None being "smaller" than all other objects in Python removed from Python 3.0 ? (see objec

Re: [Python-3000] None in Comparisons

On 2008-11-11 14:28, Antoine Pitrou wrote: > M.-A. Lemburg egenix.com> writes: >> Why was the special case for None being "smaller" than all other >> objects in Python removed from Python 3.0 ? (see object.c in Py2.x) > > Because ordered comparisons (<, <=, >, >=) are much stricter in 3.0 than in

Re: [Python-3000] None in Comparisons

M.-A. Lemburg egenix.com> writes: > > Why was the special case for None being "smaller" than all other > objects in Python removed from Python 3.0 ? (see object.c in Py2.x) Because ordered comparisons (<, <=, >, >=) are much stricter in 3.0 than in 2.x. In practice, ordered comparisons which do