-
-
Notifications
You must be signed in to change notification settings - Fork 31k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-20177: Migrate datetime.date.fromtimestamp to Argument Clinic #8535
Conversation
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. When your account is ready, please add a comment in this pull request You can check yourself Thanks again for your contribution, we look forward to reviewing it! |
For the record: CLA is signed and awaits confirmation. |
Modules/_datetimemodule.c
Outdated
@classmethod | ||
datetime.date.fromtimestamp | ||
|
||
timestamp: 'O' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
timestamp: object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Didn't get to that point in the clinic documentation.
if (PyArg_ParseTuple(args, "O:fromtimestamp", ×tamp)) | ||
result = date_local_from_object(cls, timestamp); | ||
return result; | ||
return date_fromtimestamp((PyObject *) type, timestamp); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't be better to just move the Argument Clinic declaration before date_fromtimestamp
, and rename the later to datetime_date_fromtimestamp
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that will work because date_fromtimestamp
is the C API whereas datetime_date_fromtimestamp
is the Python API and they differ in the type of the first argument. But maybe I'm overlooking something? These are just my first steps with CPython.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that since date_fromtimestamp
is used in just a single place, why not inline it? But instead of moving the body of date_fromtimestamp
inside datetime_date_fromtimestamp
, it is better to move the header of datetime_date_fromtimestamp
(generated by Argument Clinic, together with the prepending Argument Clinic declaration) in place of the header of date_fromtimestamp
. Both datetime_date_fromtimestamp
and date_fromtimestamp
are C functions, with virtually identical signatures.
Sorry if I'm not clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean, I should have just one function not the two? I don't think this works for the following reason.
I have to use datetime.date.fromtimestamp
for the clinic. If I just use date.fromtimestamp
it will complain (Parent class or module does not exist).
With the clinic declaration, this results in exactly the signature
datetime_date_fromtimestamp(PyTypeObject *type, PyObject *timestamp)
However, I cannot use this function in the PyDateTime_CAPI
declaration (l.6075). If I try that, the compiler complains
/home/tim/dev/cpython/Modules/_datetimemodule.c:6075:5: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
datetime_date_fromtimestamp,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tim/dev/cpython/Modules/_datetimemodule.c:6075:5: note: (near initialization for ‘CAPI.Date_FromTimestamp’)
The function there is expected to have PyObject *
as type, not PyTypeObject *
. I don't know if that can be corrected, but reckon that it would be a breaking change to the CAPI which we do not want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I missed that date_fromtimestamp()is not a new function, and it is used n other place. You could cast the function to the correct type as it was in the
date_methods` initialization:
(PyCFunction)datetime_date_fromtimestamp,
but the current code LGTM too.
Modules/_datetimemodule.c
Outdated
|
||
Create a date from a POSIX timestamp. | ||
|
||
The timestamp must be a double, e.g. created via time.time() and is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"must"? Aren't integers accepted too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I sort of just copied that from the original comment ("Python timestamp -- a double"). That's probably not reasonable anyway since this is the docstring for the Python API and thus should not use a C type. Is "The timestamp is a number, e.g. ..." ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is "The timestamp is a number, e.g. ..." ok?
LGTM.
@@ -0,0 +1 @@ | |||
Migrate datetime.date.fromtimestamp to Argument Clinic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a sentence ending period and "Patch by yourname."
I thought that the |
Can do, but won't be until in a couple of days. I created this PR in the EuroPython sprint. I currently have other things to do. You can leave this open until I've added more conversions. Also, I wanted to be sure that I'm on the right path and that's easier with a smaller PR. Generally, do you prefer less but larger PRs? |
You are on the right path. I prefer merging simple related changes into a single PR. |
Thanks for the clarification. I heard that you squash anyway before a merge. So I can simply add further commits for the changes? |
Yes, you can simply add further commits for the changes. |
I think we should merge this; it is an improvement after all. And it may be blocking other people from working on the other functions. |
I agree with @encukou, I think this should probably be merged and a separate issue for "migrate all date, time and datetime constructors to Argument clinic" should be opened. The fact that one has been done can serve as a useful template for the others. |
In the process of converting the date.fromtimestamp function to use argument clinic in pythonGH-8535, the C API for PyDate_FromTimestamp was inadvertently changed to expect a timestamp object rather than an argument tuple. This PR fixes this backwards-incompatible change by adding a new wrapper function for the C API function that unwraps the argument tuple and passes it to the underlying function. This PR also adds tests for both PyDate_FromTimestamp and PyDateTime_FromTimestamp to prevent any further regressions. bpo-36025
In the process of converting the date.fromtimestamp function to use argument clinic in GH-8535, the C API for PyDate_FromTimestamp was inadvertently changed to expect a timestamp object rather than an argument tuple. This PR fixes this backwards-incompatible change by adding a new wrapper function for the C API function that unwraps the argument tuple and passes it to the underlying function. This PR also adds tests for both PyDate_FromTimestamp and PyDateTime_FromTimestamp to prevent any further regressions.
This PR migrates
datetime.date.fromtimestamp
to the Argument Clinic.There's much more to to in bpo-20177, but it's a start to see how the conversion is going.
#europython2018-sprint
https://bugs.python.org/issue20177