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.

Author p-ganssle
Recipients p-ganssle, r.david.murray, steven.daprano
Date 2017-08-16.17:39:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1502905188.13.0.707581183553.issue31222@psf.upfronthosting.co.za>
In-reply-to
Content
@r.david.murray In the other thread, you mention that the full test suite is run against the C and Python implementations, so that answers the question of how to write the tests.

I think treating it as an enhancement in Python 3.7 makes a reasonable amount of sense - it's clearly under-specified at the moment and people are probably relying on the CPython behavior (dateutil definitely is in the latest stable release, but not on master). Saying "it's implementation-specific before Python 3.7 but in Python 3.7+, the spec says it should use self(type)" is fine by me. It's not particularly hard to work around if you're subclassing datetime anyway.

Among the major libraries that provide their own datetime objects:

- Arrow seems to use composition (https://github.com/crsmithdev/arrow/blob/master/arrow/arrow.py)
- pendulum subclasses, but implements their own "replace": https://github.com/sdispater/pendulum/blob/master/pendulum/pendulum.py#L25
- delorean uses composition: https://github.com/myusuf3/delorean/blob/master/delorean/dates.py#L174
- maya uses composition: https://github.com/kennethreitz/maya/blob/master/maya/core.py#L72

I'd say for the most part it's not a major issue to change it even as a bugfix, particularly if the line we're going with is "it was always implementation-specific", but there's also no rush.
History
Date User Action Args
2017-08-16 17:39:48p-gansslesetrecipients: + p-ganssle, steven.daprano, r.david.murray
2017-08-16 17:39:48p-gansslesetmessageid: <1502905188.13.0.707581183553.issue31222@psf.upfronthosting.co.za>
2017-08-16 17:39:48p-gansslelinkissue31222 messages
2017-08-16 17:39:47p-gansslecreate