[M.-A. Lemburg]
> ...
> Doesn't compare use the same coercion scheme as all the other
> operators ? Ie. if datetimeobject.cmp(datetimeobject, otherobject)
> returns NotImplemented, wouldn't otherobject.cmp(datetimeobject,
> otherobject) be called ?
*If* it returned NotImplemented, yes. But it doesn't return NotImplemented,
it raises TypeError. This is so that, e.g.,
date.today() < 12
doesn't *end up* falling back on the default compare-object-addresses
scheme. Comparison is different than, e.g., + in that way: there's a
default non-exception-raising implementation of comparison when both objects
return NotImplemented, but the default implementation of addition when both
objects return NotImplemented raises TypeError.
> ...
> Right; provided I can easily test for the datetime types
> at C level. That doesn't seem to be easily possible, though,
> since it requires going through Python to get at the
> type objects.
Patches accepted <wink>.
> ...
> True, but then roundtripping isn't guaranteed for many
> datetime operations anyway. Pretty much the same as with floating
> point arithmetic in general.
Not so for this datetime implementation: all datetime operations are exact,
except for those that raise OverflowError.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4