bpo-36025: Restore original function API for PyDate_FromTimestamp#11922
bpo-36025: Restore original function API for PyDate_FromTimestamp#11922berkerpeksag merged 1 commit intopython:masterfrom
Conversation
|
Ah, found the reason why it's anomalously passing - I accidentally shadowed the failing test with a passing one. 😅 |
6959922 to
0aadc17
Compare
|
Since it fixes a regression in released version, I think it should be documented with a news entry. |
|
@serhiy-storchaka To be clear, this is only a regression on the 3.8 branch. I didn't think alpha versions counted as "released versions", but if they do I can add a news entry. |
760634c to
f268f7a
Compare
|
@serhiy-storchaka Thanks for the review, I made all the suggested changes, except I haven't added a NEWS entry yet. |
ded3ef2 to
d9069e6
Compare
d9069e6 to
4040647
Compare
|
@serhiy-storchaka Does this look good? Can we merge or are we waiting on something else? |
4040647 to
8a597f8
Compare
8a597f8 to
314f828
Compare
|
Just realized I never did this for this issue: CC @abalkin |
314f828 to
016deca
Compare
016deca to
8f8f617
Compare
|
The first force push since approval was an accident - included a What's New entry that was intended for another PR. The second one corrects that mistake and rebases this against the current master. @abalkin @ambv Can we merge this before the next alpha release? It would be good to get at least the pyo3 3.8-dev build job working again. |
8f8f617 to
2a231bc
Compare
2a231bc to
2cd3128
Compare
ZackerySpytz
left a comment
There was a problem hiding this comment.
There are reference leaks.
9c07733 to
a61ec40
Compare
|
@ZackerySpytz Thanks for the review! You are right about the refcounts, I have removed them. I guess |
a61ec40 to
d971844
Compare
|
@abalkin @serhiy-storchaka Next alpha release is coming up soon. Anything else you'd like me to do before merge? |
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
d971844 to
ffe34ed
Compare
Per PyO3/pyo3#352, I believe we've broken the C API for
PyDateTimeAPI->Date_FromTimestamp. As a test (and to make sure we don't do it again), I've developed these tests. They are currently passing on 3.7 and they should be failing on master / Python 3.8 since we're passing atupleto a function that strictly takesintorfloat.Once I verify that these tests are indeed failing on CI, (they are anomalously passing in my local directory against master), I will also fix the underlying problem.
We don't need a news item for this, as it fixes a regression that was only ever released in alpha.
https://bugs.python.org/issue36025