[Patches] [ python-Patches-1004018 ] comparison of Decimal instance
with None fails
SourceForge.net
noreply at sourceforge.net
Fri Aug 6 21:53:25 CEST 2004
Patches item #1004018, was opened at 2004-08-05 10:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470
Category: Library (Lib)
Group: Python 2.4
>Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: comparison of Decimal instance with None fails
Initial Comment:
attempting to perform a comparison of None with a
Decimal instance yields a type error:
TypeError: You can interact Decimal only with int, long
or Decimal data types.
Since all other types (that I am aware of anyway)
compare higher than None, it would make sense that the
new Decimal type would compare higher as well. Attached
is a patch that does just that. Comments welcome.
----------------------------------------------------------------------
>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-06 14:53
Message:
Logged In: YES
user_id=80475
The new key= argument for list.sort in Py2.4 may help assign
a temporary value to fields containing None:
mydata.sort(key=lambda v: v is None and Decimal('Inf') or v)
----------------------------------------------------------------------
Comment By: Anthony Tuininga (atuining)
Date: 2004-08-06 12:06
Message:
Logged In: YES
user_id=619560
Its list.sort() that causes the issue. Clearly the concept
of "null" is not really present in Python (as it isn't in
many other languages) and to try to shoehorn it in in just a
few places would be unwise at best. Please consider my
request to patch decimal.py revoked. :-)
Just as a side note. As for "empty" decimal and the like --
I wasn't actually suggesting such a thing. In PL/SQL from
Oracle (and other languages) there is a null indicator
associated with each variable. Thus, you can have a string
that is null, a date that is null, a number that is null,
etc. Unfortunately, this doesn't propagate to other
languages and environments -- I am familiar with some that
do it this way and some that don't and the the ones that do
don't do it exactly the same way, either.... :-)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-08-06 11:53
Message:
Logged In: YES
user_id=31435
Sorry, this isn't clear:
> Its quite annoying to have a list of data values, some of
> which are null and have a TypeError exception raised.
Putting None in a list simply does not raise TypeError. What,
exactly, do you do that *does* raise TypeError? The
datetime and set types *do* allow mixed-type equality
comparison, so there's no problem mixing None with instances
of those types as dict keys, or for operations like "thing in
list" or "list.remove(thing)", or for anything else that only asks
about equality. "datetime.date == x" is False if x has any
incompatible type, and "datetime.date != x" is True.
An "empty decimal" doesn't make sense to me, and would be
an extension to the IBM standard that Decimal is trying to
implement faithfully. A world of semantics would need to be
defined for it (what exactly does it do in all Decimal
operations, under all option settings), and that's a big job.
As far as general database "missing value" thingies go,
Python's None doesn't reflect their natural semantics in many
ways. For example, 3+None raises an exception too -- None
almost never "propagates silently" in Python.
----------------------------------------------------------------------
Comment By: Anthony Tuininga (atuining)
Date: 2004-08-06 08:46
Message:
Logged In: YES
user_id=619560
Ah, very interesting. I hadn't tried datetime data yet and
that one will also be an issue for us. Let me give you a
little background so you know why I am suggesting this. We
are acquiring data from a database where floating point
numbers are returned as decimal instances and date as
datetime instances. Some of this data may be null which in
DB API parlance means a None instance. Its quite annoying to
have a list of data values, some of which are null and have
a TypeError exception raised. I'm not sure how familiar you
are with the DB API and databases in general but this
behavior makes such types unusable -- which is unfortunate.
We will have to subclass or write our own "Value" class that
has the behavior we want. Do you have any further comments
about the concept of "null" with respect to databases? Or do
your existing comments still stand?
The other question I would leave you with is: comparing with
an empty set is quite possible, but how about an "empty"
decimal or "empty" datetime instance?
Thanks for the response thus far -- even if it wasn't what I
wanted. :-)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-08-06 00:16
Message:
Logged In: YES
user_id=31435
Sorry, I'm opposed to this. Silently delivering a result when
comparing to None has few intelligible use cases, but does
hide errors quite effectively. For this reason, it's generally
true that the newer types in Python refuse non-equality
comparisons with None (or with any other senselessly
incompatible type). For example,
>>> from datetime import date
>>> date.today() < None
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: can't compare datetime.date to NoneType
>>> set([1, 2]) > None
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: can only compare to a set
>>>
The new collections.deque type is an oddball in this respect,
and should probably be "fixed":
>>> import collections
>>> collections.deque() > None
True
>>>
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470
More information about the Patches
mailing list