-
-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
Add timezone support to datetime C API #54590
Comments
With timezone class added to datetime module, C API should be extended to at the minimum support efficient creation of timezone instances and access to the singleton UTC instance. I am not sure whether PyDateTime_TimeZone details should be exposed in datetime.h because presumably programmers should access it through the abstract tzinfo interface. |
Would it be possible to deprecate (or at least stop enhancing) the current datetime C API and add a new capsule based one instead? We're trying to get extension module authors to *stop* relying on C level globals, since it causes problems with:
Unfortunately, the current design of the datetime C API *requires* the use of C level global state. |
I'm certainly fine with re-configuring my PR to center around a new capsule module with deprecation of the old C API (though if you have any examples of what you have in mind that would be helpful to me). Certainly the "C global needs to be initiated" problem has bitten me in the past and I'm certain will continue to bite people in the future. That said, I think it would be really good if we could get a fast path for timezone creation and access to the UTC singleton into the Python 3.7 release. I think it's kind of a big disparity between the Python and C APIs that's existed for too long already. |
On 31 December 2017 at 01:34, Paul Ganssle <report@bugs.python.org> wrote:
It turns out the API already *is* exported as a capsule: Our general guidance for capsule usage is just outdated, and the I'll file a separate issue for that docs problem later (the tracker is |
https://bugs.python.org/issue32459 covers defining a module-reloading-friendly way of using capsules. For this issue, I now think it makes sense to just ignore that problem, and add whatever you need to the existing API. |
Hunting reference leaks with "./python -m test -R 3:3 test_datetime" crashs since the commit 04af5b1. vstinner@apu$ ./python -m test -R 3:3 test_datetime Current thread 0x00007ff71fe33040 (most recent call first): Shorter example without -R, just run the same test twice: vstinner@apu$ ./python -m test -v test_datetime test_datetime -m test_utc_capi ---------------------------------------------------------------------- OK (skipped=1) Current thread 0x00007f9836b31040 (most recent call first): |
Ok, this time it should be fixed for real ;-) |
Oh, PR 5317 title mentionned this bpo number, but the merged change omits the bpo number and so wasn't mentioned on this issue. PR 5317 added: commit 58dc03c (upstream/master, master)
|
This can be closed now, I think. |
I tested manually "./python -m test test_datetime test_datetime" in 3.6, 3.7 and master branches: I confirm that the test no longer crash. It has been fixed by the commit 58dc03c. Moreover, I don't recall a recent crash on Windows Refleak or Gentoo Refleak buildbots. Thanks again Paul Ganssle for this nice enhancement! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: