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: Other Python implementations may not expose the module name in datetime type names
Type: Stage: resolved
Components: Tests Versions: Python 3.10, Python 3.9
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: iritkatriel, jstasiak, p-ganssle, wmeehan
Priority: normal Keywords: patch

Created on 2020-11-17 15:24 by wmeehan, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 23345 closed wmeehan, 2020-11-17 15:58
Messages (6)
msg381248 - (view) Author: William Meehan (wmeehan) * Date: 2020-11-17 15:26
This just requires some changes to test_datetime and test_hash
msg381269 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2020-11-17 18:24
Is this an actual problem for another implementation of Python?

Is there some reason to think that we intended the repr of a `datetime` object to be implementation-defined?
msg381271 - (view) Author: William Meehan (wmeehan) * Date: 2020-11-17 18:34
For Python implementations that change the underlying object structure, it's not necessarily possible to recreate the `tp_name` that would be exposed in CPython. The `datetime` ends up in `__module__`, while only the type name ends up in `__name__`. There's no way to tell that the value in `__module__` actually came from `tp_name` in the first place.
msg381274 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2020-11-17 19:02
What is an example of another Python implementation that has this property? Is there a concrete issue open somewhere that this is solving?

I am not unsympathetic to the idea of accommodating other implementations of Python, but this is very abstract and I think the assumption is probably that if we're explicitly testing for something and we don't say it's implementation-defined that it is part of the language spec.

If there's some evidence that stuff like this is intended to be implementation-defined always, or there's some concrete problem that we can solve (and possibly also add tests to avoid regressions), I'd be much more comfortable with something like this.
msg410660 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2022-01-15 19:53
William, can you elaborate where this came up?
msg412163 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2022-01-30 16:53
Closing as the OP is unresponsive.
Date User Action Args
2022-04-11 14:59:38adminsetgithub: 86556
2022-01-30 16:53:54iritkatrielsetstatus: pending -> closed
resolution: rejected
messages: + msg412163

stage: patch review -> resolved
2022-01-15 19:53:22iritkatrielsetstatus: open -> pending
versions: - Python 3.7, Python 3.8
nosy: + iritkatriel

messages: + msg410660
2020-11-18 23:15:23jstasiaksetnosy: + jstasiak
2020-11-17 19:02:59p-gansslesetmessages: + msg381274
2020-11-17 18:34:36wmeehansetmessages: + msg381271
2020-11-17 18:24:43p-gansslesetnosy: + p-ganssle
messages: + msg381269
2020-11-17 15:58:26wmeehansetkeywords: + patch
stage: patch review
pull_requests: + pull_request22237
2020-11-17 15:26:07wmeehansetmessages: + msg381248
2020-11-17 15:24:52wmeehancreate