This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses"
Type: Stage: resolved
Components: Documentation Versions: Python 3.8, Python 3.7, Python 3.6
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Kevin.Norris, Mariatta, Xtrem532, danishprakash, docs@python, miss-islington, p-ganssle
Priority: normal Keywords: easy, patch

Created on 2018-08-09 05:03 by Kevin.Norris, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 8814 merged danishprakash, 2018-08-19 02:38
PR 9181 merged miss-islington, 2018-09-11 20:59
PR 9182 merged miss-islington, 2018-09-11 20:59
Messages (7)
msg323314 - (view) Author: Kevin Norris (Kevin.Norris) Date: 2018-08-09 05:03
The 3.x datetime documentation contains the following footnote:

> In other words, date1 < date2 if and only if date1.toordinal() < date2.toordinal(). In order to stop comparison from falling back to the default scheme of comparing object addresses, date comparison normally raises TypeError if the other comparand isn’t also a date object. However, NotImplemented is returned instead if the other comparand has a timetuple() attribute. This hook gives other kinds of date objects a chance at implementing mixed-type comparison. If not, when a date object is compared to an object of a different type, TypeError is raised unless the comparison is == or !=. The latter cases return False or True, respectively.

But in 3.x, comparison no longer falls back to comparing object addresses.  Also, some of the comments on issue 8005 seem to suggest that this footnote is not actually true in 3.x (aside from the first sentence, of course).  But regardless, the footnote should not refer to a long dead interpreter behavior as if it were still around.
msg323695 - (view) Author: Danish Prakash (danishprakash) * Date: 2018-08-18 08:53
> But in 3.x, comparison no longer falls back to comparing object addresses.

What is the default fallback in 3.x?
msg323710 - (view) Author: Kevin Norris (Kevin.Norris) Date: 2018-08-18 13:15
There is none.  It raises a TypeError.  See
msg325060 - (view) Author: miss-islington (miss-islington) Date: 2018-09-11 20:59
New changeset 9c223794c754408644c16349b85dd27fdba8a926 by Miss Islington (bot) (Danish Prakash) in branch 'master':
bpo-34365: Update date object documentation (GH-8814)
msg325062 - (view) Author: Mariatta (Mariatta) * (Python committer) Date: 2018-09-11 21:03
msg325066 - (view) Author: miss-islington (miss-islington) Date: 2018-09-11 21:24
New changeset e2b40f4ce954ea3d35a73541029b2253abd9d245 by Miss Islington (bot) in branch '3.7':
bpo-34365: Update date object documentation (GH-8814)
msg325067 - (view) Author: miss-islington (miss-islington) Date: 2018-09-11 21:27
New changeset 8a2c2d4e1b6b46a9a982e5c064ca4399ec28d55d by Miss Islington (bot) in branch '3.6':
bpo-34365: Update date object documentation (GH-8814)
Date User Action Args
2022-04-11 14:59:04adminsetgithub: 78546
2020-11-10 17:56:41Xtrem532setnosy: + Xtrem532
2018-09-11 21:27:09miss-islingtonsetmessages: + msg325067
2018-09-11 21:24:56miss-islingtonsetmessages: + msg325066
2018-09-11 21:03:41Mariattasetstatus: open -> closed

nosy: + Mariatta
messages: + msg325062

resolution: fixed
stage: patch review -> resolved
2018-09-11 20:59:58miss-islingtonsetpull_requests: + pull_request8620
2018-09-11 20:59:47miss-islingtonsetpull_requests: + pull_request8619
2018-09-11 20:59:28miss-islingtonsetnosy: + miss-islington
messages: + msg325060
2018-08-20 19:43:36p-gansslesetnosy: + p-ganssle
2018-08-19 02:38:36danishprakashsetkeywords: + patch
stage: patch review
pull_requests: + pull_request8292
2018-08-18 13:15:30Kevin.Norrissetmessages: + msg323710
2018-08-18 08:53:45danishprakashsetnosy: + danishprakash
messages: + msg323695
2018-08-17 17:58:49steve.dowersetkeywords: + easy
versions: - Python 3.4, Python 3.5
2018-08-09 05:03:49Kevin.Norriscreate