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: Breaking change in PyDate_FromTimeStamp API
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.8
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: p-ganssle Nosy List: belopolsky, berker.peksag, lukasz.langa, p-ganssle, petr.viktorin, serhiy.storchaka
Priority: release blocker Keywords: patch

Created on 2019-02-18 17:22 by p-ganssle, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 11922 merged p-ganssle, 2019-02-18 17:25
Messages (4)
msg335854 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-02-18 17:22
The PyO3 test suite has been breaking since the alpha release of Python 3.8 because PyDateTimeAPI->Date_FromTimeStamp has had a breaking change in its API:

I believe this happened when `` and `datetime.datetime.fromtimestamp` were converted over to using the argument clinic. The function `date_from_local_object` was renamed to `date_fromtimestamp`, without a corresponding change to the PyDateTimeCAPI struct.
msg335858 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-02-18 18:14
I've put *a* fix in there by introducing a new wrapper function. Ideally we would just point the C API at the argument clinic-generated function, but because it takes a single positional argument the argument clinic outputs a METH_O function instead of METH_VARARGS.

I think these are the options:

1. Modify the argument clinic spec to force METH_VARARGS for a single positional argument taking an object - if that's possible.
2. Maintain a wrapper function for the C API that just unpacks the tuple and passes it to the date_fromtimestamp function that the argument clinic is *also* wrapping.
3. Revert the argument clinic change and manually manage the date_fromtimestamp function as a METH_VARARGS classmethod.

I don't know enough about the argument clinic to know if #1 is feasible, if it is and someone can point me in the right direction, I can update my PR. If not, I think I mildly prefer #2, since maintaining a thin wrapper that unpacks a tuple is not terribly difficult compared to maintaining the method definition stuff.

Since this was an accidental break in the C API, I've marked it as a release blocker.
msg335893 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-02-19 07:04
I prefer option 2. Your PR LGTM.
msg341009 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2019-04-27 19:39
New changeset 4d8c8c0ad6163c24136d3419eb04f310b31f7e64 by Berker Peksag (Paul Ganssle) in branch 'master':
bpo-36025: Fix PyDate_FromTimestamp API (GH-11922)
Date User Action Args
2022-04-11 14:59:11adminsetgithub: 80206
2019-04-27 19:59:54berker.peksagsetstatus: open -> closed
type: behavior
resolution: fixed
stage: patch review -> resolved
2019-04-27 19:39:42berker.peksagsetnosy: + berker.peksag
messages: + msg341009
2019-02-19 07:04:28serhiy.storchakasetmessages: + msg335893
2019-02-18 18:14:38p-gansslesetpriority: normal -> release blocker
nosy: + lukasz.langa
messages: + msg335858

2019-02-18 17:25:19p-gansslesetkeywords: + patch
stage: patch review
pull_requests: + pull_request11947
2019-02-18 17:22:05p-gansslecreate