On 14.02.2014 11:20, Antoine Pitrou wrote:
> On Fri, 14 Feb 2014 20:13:43 +1000
> Nick Coghlan <ncogh...@gmail.com> wrote:
>> On 14 February 2014 20:02, Antoine Pitrou <solip...@pitrou.net> wrote:
>>> On Fri, 14 Feb 2014 10:46:50 +0100
>>> Lennart Regebro <rege...@gmail.com> wrote:
>>>>>
>>>>> Sending this to python-dev as I'm wondering if this was considered when
>>>>> the
>>>>> choice to have objects of different types raise a TypeError when
>>>>> ordered...
>>>>>
>>>>> So, the concrete I case I have is implementing stable ordering for the
>>>>> python Range objects that psycopg2 uses. These have 3 attributes that can
>>>>> either be None or, for sake of argument, a numeric value.
>>>>>
>>> [...]
>>>>
>>>> It was considered. It's not obvious where you want "None" to appear in
>>>> your ordering, so you will have to implement this by yourself. I can't
>>>> come up with anything obviously shorter.
>>>
>>> I have to agree with Lennart. The fact that SQL defines an order for
>>> NULL and other values doesn't mean it's obvious or right in any way (I
>>> never remember which way it goes).
>>
>> SQL doesn't define an order for NULL, it's more like a "quiet NaN" -
>> if either operand is NULL, the result is also NULL. (I ran into this
>> recently, in the context of "NULL == value" and "NULL != value" both
>> being effectively false).
>
> Hmm, it seems you're right, but I'm quite sure some DBMSes have a
> consistent way of ordering NULLs when using ORDER BY on a nullable
> column.
They do, but it's not consistent:
MS SQL Server: orders NULLs first (in table order; stable sort)
Sybase ASE: orders NULLs first (in arbitrary order)
Oracle: orders NULLs last (in arbitrary order)
PostgreSQL: orders NULLs last (in arbitrary order)
IBM DB2: orders NULLs last (in table order; stable sort)
Reference: tests done with actual databases.
A note about consistency: None is always ordered first in Python 2,
so there is a precedent. And since Python's list.sort() is stable,
Python 2 is in the same camp as MS SQL Server.
>From Python-2.7.6/Objects/object.c:
/* None is smaller than anything */
if (v == Py_None)
return -1;
if (w == Py_None)
return 1;
IMO, it was a mistake to have None return a TypeError in
comparisons, since it makes many typical data operations
fail, e.g.
Python2:
>>> l = [1,2,None,4,5,None,6]
>>> l.sort()
>>> l
[None, None, 1, 2, 4, 5, 6]
Python3:
>>> l = [1,2,None,4,5,None,6]
>>> l.sort()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: NoneType() < int()
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 14 2014)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53
::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
