[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit
Change by Paul Ganssle : -- pull_requests: +19849 pull_request: https://github.com/python/cpython/pull/20624 ___ Python tracker <https://bugs.python.org/issue40686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40777] _datetimemodule.c:3328:16: error: initializer element is not constant
Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue40777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40799] Create Lib/_pydatetime.py file to optimize "import datetime" when _datetime is available
Paul Ganssle added the comment: I basically agree with this — this is one of the reasons I structured the zoneinfo module the way I did rather than mimicking the pattern in datetime. I believe that there are other modules that have similar situations like heapq, but datetime is probably the worst offender. I am inclined to say that we should restructure datetime into a folder, containing __init__.py, _datetime.py and possibly _strptime.py (which I think is also only used in datetime), but I think that sort of restructuring is way more sensitive to weird import bugs than this one. As it is now, I would be shocked if this didn't break *someone*, because people are always relying on weird implementation details (knowingly or unknowingly), but I think it's worth doing; it's good to tackle it this early in the cycle. @vstinner What do you think about restructuring into a folder-based submodule rather than _pydatetime.py? It's way more likely to break someone, but I think it might be the better way to organize the code, and I don't want to have to go through *two* refactors of this sort. -- ___ Python tracker <https://bugs.python.org/issue40799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40705] use-after-free in _zoneinfo.c's module_free function
Paul Ganssle added the comment: New changeset 06a1b8915d6674e40f0dccc422ca2c06212392d8 by Ammar Askar in branch 'master': bpo-40705: Fix use-after-free in _zoneinfo's module_free (GH-20280) https://github.com/python/cpython/commit/06a1b8915d6674e40f0dccc422ca2c06212392d8 -- ___ Python tracker <https://bugs.python.org/issue40705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40713] _zoneinfo.c can use dst_offset without initialization in parse_tz_str()
Paul Ganssle added the comment: This is a duplicate of bpo-40714. It's a bit of an overzealous compiler warning (as far as I can tell it's not true that the uninitialized value would ever be used), but we fixed it anyway in GH-20291. Thanks for the report! -- nosy: +p-ganssle resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40705] use-after-free in _zoneinfo.c's module_free function
Change by Paul Ganssle : -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue40705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40683] Beta release does not distribute zoneinfo or test_zoneinfo
Paul Ganssle added the comment: No worries Łukasz, I figured it would be worth bringing up because normally the releases aren't so broken that they aren't usable in the common case. That said, this won't break any *existing* code, it'll just prevent people on Linux machines from using zoneinfo. I don't think waiting 3 weeks is a big deal. I'm planning to release a backport soon anyway, and I expect people probably won't adopt new-in-3.9 modules without a backport during the beta period *anyway*, since they can't deploy any code using that feature to prod. I'm going to resolve this issue. Thanks for the quick response Łukasz and for the quick review Victor! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40683] Beta release does not distribute zoneinfo or test_zoneinfo
Paul Ganssle added the comment: Victor has confirmed that this is working on Windows, so I think the current state of the 3.9 and master branches is now fixed. The last question remaining is whether this justifies a quick b2 release (or if there's another mechanism for a "fixup" release like b1.post0). Łukasz, what do you think? -- ___ Python tracker <https://bugs.python.org/issue40683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40683] Beta release does not distribute zoneinfo or test_zoneinfo
Paul Ganssle added the comment: New changeset 2abededbc4165d2daa14ae9d74b1f33cce0593d7 by Paul Ganssle in branch 'master': bpo-40683: Add zoneinfo to LIBSUBDIRS (#20229) https://github.com/python/cpython/commit/2abededbc4165d2daa14ae9d74b1f33cce0593d7 -- ___ Python tracker <https://bugs.python.org/issue40683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40683] Beta release does not distribute zoneinfo or test_zoneinfo
Paul Ganssle added the comment: Victor: Might be worth updating your notes to indicate that any subdirectory (not just test subdirectories) need to go into LIBSUBDIRS. zoneinfo uses a subdirectory for both the tests and the zoneinfo module, and *neither* were included in the installation in this case. -- title: Beta release does not distribute test_zoneinfo -> Beta release does not distribute zoneinfo or test_zoneinfo ___ Python tracker <https://bugs.python.org/issue40683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40683] Beta release does not distribute test_zoneinfo
Change by Paul Ganssle : -- keywords: +patch pull_requests: +19520 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/20229 ___ Python tracker <https://bugs.python.org/issue40683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40683] Beta release does not distribute zoneinfo
Paul Ganssle added the comment: I think I found the problem: these directories are not included in the Makefile.pre.in LIBSUBDIRS variable: https://github.com/python/cpython/blob/a355a06fcc7ef2232736dceb012ae623335cd7ab/Makefile.pre.in#L1373 PR incoming. -- ___ Python tracker <https://bugs.python.org/issue40683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40683] Beta release does not distribute zoneinfo
New submission from Paul Ganssle : Apparently something is wrong with make install for beta 1 and the `zoneinfo` module is not installed with it (only _zoneinfo). When I run a local build `./python -c "import zoneinfo"` works, but when I do `make install` I get ImportError: $ bin/python3 -c "import zoneinfo" Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'zoneinfo' I assume this wasn't caught earlier because Lib/test/test_zoneinfo is *also* not being installed. The C extension, _zoneinfo, is installed properly. I don't know if it is working on Windows. -- assignee: p-ganssle messages: 369357 nosy: lukasz.langa, p-ganssle priority: critical severity: normal stage: needs patch status: open title: Beta release does not distribute zoneinfo type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5537] LWPCookieJar cannot handle cookies with expirations of 2038 or greater on 32-bit platforms
Paul Ganssle added the comment: > Should we fix utcfromtimestamp() internally to avoid the OverflowError, > rather than only fixing the http.cookiejar module? I'm not a big fan of utcfromtimestamp (as you can see here: https://blog.ganssle.io/articles/2019/11/utcnow.html ), but it seems we do have the same issue in `datetime.datetime.fromtimestamp`, so I think maybe we should spawn a new issue to at least look into the possibility? -- ___ Python tracker <https://bugs.python.org/issue5537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40536] Addition of a "list of available time zones" function to zoneinfo
Paul Ganssle added the comment: I've merged the existing implementation, but I'm leaving this staged as "release blocker" so that Łukasz can have final say on whether this goes into 3.9. Thanks for the help everyone! -- ___ Python tracker <https://bugs.python.org/issue40536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40536] Addition of a "list of available time zones" function to zoneinfo
Paul Ganssle added the comment: New changeset e527ec8abe0849e784ce100f53c2736986b670ae by Paul Ganssle in branch 'master': bpo-40536: Add zoneinfo.available_timezones (GH-20158) https://github.com/python/cpython/commit/e527ec8abe0849e784ce100f53c2736986b670ae -- ___ Python tracker <https://bugs.python.org/issue40536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40536] Addition of a "list of available time zones" function to zoneinfo
Paul Ganssle added the comment: I've opened a PR adding this feature and tagged this as release blocker, since I'd like to make sure this is in the beta if Łukasz does not object. The concerns about the stability of the function I expressed earlier have not changed much, though we did get some feedback from the tz database list that at least make me think that the new approach (excluding posix/, right/ and posixrules) is *probably* the right way to go. -- priority: normal -> release blocker ___ Python tracker <https://bugs.python.org/issue40536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40536] Addition of a "list of available time zones" function to zoneinfo
Change by Paul Ganssle : -- pull_requests: +19461 pull_request: https://github.com/python/cpython/pull/20158 ___ Python tracker <https://bugs.python.org/issue40536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
Paul Ganssle added the comment: New changeset b17e49e0def23238b9e7f48c8a02e2d7bbf1f653 by Paul Ganssle in branch 'master': bpo-40503: Add documentation and what's new entry for zoneinfo (GH-20006) https://github.com/python/cpython/commit/b17e49e0def23238b9e7f48c8a02e2d7bbf1f653 -- ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40643] Improve doc-strings for datetime.strftime & strptime
Paul Ganssle added the comment: I agree, this can be improved (particularly the first one). I believe we'll need to change it in the C implementation as well as the pure python version. That said, the most useful thing for users would be a full formatting reference, which is too much to put in the docstring (and to maintain in at least 3 different places). I'm not sure *how* much better it can get, but at least the first one reads like a terrible self-referential dictionary entry "recyclist (n). a proponent of recyclism". At the very least it should disambiguate between `datetime.strftime`, `time.strftime` and `stftime(3)`. -- nosy: +p-ganssle priority: normal -> low stage: -> needs patch type: -> enhancement ___ Python tracker <https://bugs.python.org/issue40643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Paul Ganssle added the comment: This is now merged, thanks for the debate and opinions offered everyone, and thanks to Dong-hee for the implementation! The way we did the implementation, a pickle/unpickle cycle on the result of .isocalendar() will return a plain tuple. Despite the fact that I suggested it, I recognize that this is a /weird thing to do/, and I'm sorta banking on the fact that in all likelihood no one is relying on pickling and unpickling the result of .isocalendar() returning anything but a tuple (since, currently, that's already what it does, regardless of what the input type was). I suppose we'll have to see if it causes problems in the beta period, and I'll keep a close eye on it. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Paul Ganssle added the comment: New changeset 1b97b9b0ad9a2ff8eb5c8f2e2e7c2aec1d13a330 by Paul Ganssle in branch 'master': bpo-24416: Return named tuple from date.isocalendar() (GH-20113) https://github.com/python/cpython/commit/1b97b9b0ad9a2ff8eb5c8f2e2e7c2aec1d13a330 -- ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Change by Paul Ganssle : -- pull_requests: +19420 pull_request: https://github.com/python/cpython/pull/20113 ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
Paul Ganssle added the comment: Talked to Steve Dower in a sidebar about the issue with compile-time configuration, he is convinced that compile-time configuration is not something that would be useful or worth doing on Windows. I am indifferent on the matter, so I am fine with calling the compile-time configuration part of this done at this point. If anyone building Python for Windows shows up needing support for this, we can re-visit the issue — I don't believe it's technically infeasible, just that the usage patterns of Python on Windows mean that it's not worth doing. So, once we've got a critical mass of reviews done for zoneinfo, I think this feature is done. -- ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40536] Addition of a "list of available time zones" function to zoneinfo
Paul Ganssle added the comment: >From some discussion on the reference implementation PR, it seems that this >may be a more complicated feature than I had bargained for: >https://github.com/pganssle/zoneinfo/pull/60 The issue is that the current implementation picks up the posix/ and right/ directories as well as the posixrules file, none of which is *wrong* — they are available time zones, after all — but they're not really canonical zones. In `tzdata` we have a list of zones sourced from tzdata's `make zonenames`, which does not include the posix/ and right/ directories. There is `zone1970.tab` and `zone.tab`, but that has *too* strict of a subset — it only includes canonical zones associated with a specific country, as far as I can tell, and not things like UTC. It also includes, for example, America/Nuuk but not America/Godthab (which was the canonical name up until 2020a). I'm considering postponing this feature to Python 3.10 so that we can have more time to figure out a decent API for this. Łukasz: Question for you as release manager — would you prefer that we put this in for 3.9 with the understanding that before the final release we may end up needing to remove it as a nuisance or change what it returns (and possibly flags that would be passed to it), or would that be too disruptive in the beta period? I'm confident that we can make a final decision before October, just not confident that we can make a final decision before Monday. -- assignee: -> p-ganssle nosy: +lukasz.langa ___ Python tracker <https://bugs.python.org/issue40536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
Paul Ganssle added the comment: Here are some benchmarks run using the latest implementation. The pure Python code is pretty optimized, but the C code is still ~4-5x faster. Running from_utc in zone Europe/Paris c_zoneinfo: mean: 494.82 ns ± 3.80 ns; min: 489.23 ns (k=5, N=50) py_zoneinfo: mean: 2.48 µs ± 79.17 ns; min: 2.42 µs (k=5, N=10) dateutil: mean: 10.41 µs ± 209.97 ns; min: 10.17 µs (k=5, N=5) pytz: mean: 4.69 µs ± 252.70 ns; min: 4.39 µs (k=5, N=5) Running to_utc in zone Europe/Paris c_zoneinfo: mean: 539.61 ns ± 25.68 ns; min: 514.39 ns (k=5, N=50) py_zoneinfo: mean: 2.01 µs ± 61.69 ns; min: 1.94 µs (k=5, N=10) dateutil: mean: 7.88 µs ± 506.89 ns; min: 7.25 µs (k=5, N=5) pytz: mean: 773.02 ns ± 14.11 ns; min: 759.56 ns (k=5, N=50) Running utcoffset in zone Europe/Paris c_zoneinfo: mean: 329.34 ns ± 36.31 ns; min: 302.88 ns (k=5, N=100) py_zoneinfo: mean: 1.57 µs ± 9.58 ns; min: 1.55 µs (k=5, N=20) dateutil: mean: 6.28 µs ± 86.61 ns; min: 6.16 µs (k=5, N=5) pytz: mean: 461.47 ns ± 2.07 ns; min: 458.91 ns (k=5, N=50) `utcoffset()` is very likely to be called possibly many times in certain hot loops (including implicitly as it's part of hash and equality checks). -- ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
Paul Ganssle added the comment: I mean, theoretically we don't "need" it, but it's much, much faster, and without it nearly every operation that needs time zone offsets will be slower than pytz (which has a mechanism for caching). Also, I've already written it, so I see no reason why not use it. -- ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40536] Addition of a "list of available time zones" function to zoneinfo
Change by Paul Ganssle : -- pull_requests: -19344 ___ Python tracker <https://bugs.python.org/issue40536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40536] Addition of a "list of available time zones" function to zoneinfo
Change by Paul Ganssle : -- keywords: +patch pull_requests: +19344 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19909 ___ Python tracker <https://bugs.python.org/issue40536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
Paul Ganssle added the comment: Thanks Thomas, that was super helpful. I've created GH-20034 to add in the compile-time arguments on POSIX systems at least, do you mind having a look? For the moment I have made it non-configurable on Windows, but I think the right thing to do is to add an argument to PCbuild\build.bat. Hopefully Steve can point me in the right direction for mapping that argument (or something else) to a new config variable in sysconfig. -- ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
Change by Paul Ganssle : -- pull_requests: +19343 pull_request: https://github.com/python/cpython/pull/20034 ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40536] Addition of a "list of available time zones" function to zoneinfo
Paul Ganssle added the comment: I have an initial implementation against the reference implementation here: https://github.com/pganssle/zoneinfo/pull/60 Once GH-19909 is merged, I will turn that into a PR against CPython. For the first pass I went with: 1. free-standing function 2. returning set() 3. no cache 4. available_timezones() -- ___ Python tracker <https://bugs.python.org/issue40536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
Paul Ganssle added the comment: I've separated this into two separate PRs, one for docs and one for tests/implementation. I have not yet implemented the logic for the ability to configure the TZPATH at compile time because I'm not quite sure how to start on that. How are other compile-time options implemented? Do I need to do something special to handle both Windows and POSIX systems? Is there already a configuration file somewhere that I should use for this? Adding Thomas to the nosy list because he's the only one listed for "autoconf/makefiles" – don't know if that extends to the Windows build as well. -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
Change by Paul Ganssle : -- pull_requests: +19318 pull_request: https://github.com/python/cpython/pull/20006 ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40536] Addition of a "list of available time zones" function to zoneinfo
New submission from Paul Ganssle :
One thing that I sort of overlooked in PEP 615 that I think will be a common
feature request for zoneinfo is the ability to get a list of time zones
available on the current TZPATH.
This is more complicated to implement than it sounds like, but luckily I
already did it in order to implement the property tests for the zoneinfo module:
https://github.com/pganssle/zoneinfo/blob/ffd21a6d065e04725e04b37bb430c2559fefd5fa/tests/test_zoneinfo_property.py#L23-L70
The biggest complication is that there are files on TZPATH that are not
necessarily time zones, and when I looked I couldn't easily find a list of all
available time zones, so the only way to tell which ones are time zones and
which ones aren't is to open each one and read the first 4 bytes. However,
`tzdata` does ship with a list of available time zones, so the way I've got the
function working right now is:
1. If `tzdata` is installed – despite the fact that it's technically the end of
the search path, convert the list of available zones that ships with `tzdata`
to your starting set (since you know these are all valid zones).
2. Walk the `tzpath`, and every time you find something not in the set of valid
keys, open it and read the first 4 bytes, then add that to the set.
The common cases will be that `tzdata` is not available (in which case no harm
done), or `tzdata` has the same set of keys as the TZPATH, in which case you
never have to open any of the TZif files. The fact that the search order is
inverted from what it normally is doesn't matter because the output is the
union of all the sets anyway.
I don't know that the PEP needs to be amended – if this were a feature request
for Python 3.10 I don't think it would need a PEP to go through, but I don't
mind amending the PEP to document it.
Design decisions (with my initial answers, loosely held):
1. Should this be a classmethod or a free-standing function?
I'm inclined towards free-standing function because zoneinfo.TZPATH is at the
module level and not the class level.
2. What should the return type be?
I think frozenset() or set(); a sorted list is also a reasonable option, but
for people who just want to use "in" or show some subset of available zones,
that would be wasteful.
We should go with frozenset() if we want there to be some possibility of
caching the result in the future.
3. Should we try to cache the result?
I would say no, at least for now. It would not be super easy to get the cache
invalidation right in the general case, and not many people are likely to be
sensitive to the performance of this operation – the people who are can easily
create their own cache.
4. What should it be called?
Naming things is hard. Options:
- zoneinfo.timezones()
- zoneinfo.all_timezones()
- zoneinfo.timezone_{list,set}()
- zoneinfo.valid_timezones()
- zoneinfo.valid_keys()
- zoneinfo.available_timezones()
`pytz` has a similar thing and calls it all_timezones. It also has something
called common_timezones, but that is a bit harder to pull off and I'm not
confident that we'll get something satisfactory before the feature freeze.
--
components: Library (Lib)
messages: 368285
nosy: belopolsky, lemburg, p-ganssle
priority: normal
severity: normal
status: open
title: Addition of a "list of available time zones" function to zoneinfo
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
Change by Paul Ganssle : -- keywords: +patch pull_requests: +19224 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/19909 ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40503] PEP 615: Add zoneinfo module
New submission from Paul Ganssle : This is an issue to track the implementation of PEP 615: https://www.python.org/dev/peps/pep-0615/ It should mostly involve migrating from the reference implementation: https://github.com/pganssle/zoneinfo/ -- assignee: p-ganssle components: Library (Lib) messages: 368076 nosy: belopolsky, lemburg, p-ganssle priority: high severity: normal stage: needs patch status: open title: PEP 615: Add zoneinfo module type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40236] datetime.datetime.strptime get day error
Change by Paul Ganssle : -- stage: -> needs patch ___ Python tracker <https://bugs.python.org/issue40236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40236] datetime.datetime.strptime get day error
Paul Ganssle added the comment: Likely relevant is bpo-23136, where they dealt with similar issues in the past. I don't see any explicit test for this behavior, but it seems that the solution is to try to be consistent and to not raise a ValueError. Looking at this issue, I think it's a manifestation of a similar bug that hits when a year starts with a Monday. It seems like the behavior is that the following days (%W-%w) should be sequential in any year: 00-1, 00-2, 00-3, 00-4, 00-5, 00-6, 00-0, 01-1, 01-2, ... Since 2024 starts in a Monday, the first day of the year should be 2024-01-1, and the 2024-00-1 week should start 2023-12-25 rather than duplicating the following week. I think there's an equivalent issue with dates of the form "%Y-%U-%w", but happening on years that start with a Sunday. -- ___ Python tracker <https://bugs.python.org/issue40236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40236] datetime.datetime.strptime get day error
Paul Ganssle added the comment:
I can reproduce this on Linux with Python 3.8.2.
I think this may be a bug, but it may also just be platform-specific weirdness.
Either way it's very curious behavior:
>>> datetime.strptime("2023-0-0", "%Y-%W-%w")
datetime.datetime(2023, 1, 1, 0, 0)
>>> datetime.strptime("2023-0-1", "%Y-%W-%w")
datetime.datetime(2022, 12, 26, 0, 0)
The definition for %W (and %U, which is related) goes like this:
> Week number of the year (Monday as the first day of the week) as a decimal
> number. All days in a new year preceding the first Monday are considered to
> be in week 0.
2024 starts on a Monday, so there should be no Week 0 in that year at all.
Seems to me like it's undefined what happens when you put in a string that puts
in an invalid value for "%Y-%W-%w".
Seems to me that we are just passing through the behavior of `time.strptime` in
this case (which just calls out to what the platform does):
>>> time.strptime("2024-0-3", "%Y-%W-%w")
time.struct_time(tm_year=2024, tm_mon=1, tm_mday=3, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=2, tm_yday=3, tm_isdst=-1)
I am open to discussion about trying to rationalize this behavior - it would be
a bit tricky but if we moved to our own implementation of the algorithm to
calculate %W we could detect this situation and throw an exception. I'd rather
see if this is intended behavior in the underlying C implementation first,
though. If this is consistent across platforms and not just some random
implementation detail, people may be relying on it.
I propose that we:
1. Determine what happens on different platforms (might be easy to just make a
PR that asserts the current behavior and see if/how it breaks on any of the
supported platforms).
2. Determine why it works the way it does.
After that, at the very least we should document the behavior with a warning or
a footnote or something. If we make any changes to the behavior they would be
3.9+, but the documentation changes can be backported.
Thanks for the bug report zhanying! Very interesting!
--
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue40236>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40173] test.support.import_fresh_module fails to correctly block submodules when fresh is specified
New submission from Paul Ganssle :
It seems that test.support.import_fresh_module gets tripped up with its module
blocking when you attempt to get a fresh copy of a submodule of a module where
you are also importing the module that you are trying to block (bit of a doozy
of a sentence there...). So, for example, with the following configuration in
mymodule/__init__.py:
from .other import other
try:
from ._a import attr
except ImportError:
from ._b import attr
(Assuming _a.attr = "A" and _b.attr = "B"), if you attempt to do:
m = test.support.import_fresh_module("mymodule",
fresh=("mymodule._other",), blocked=("mymodule._a"))
Then you'll find that m.attr is pulled from _a.attr. Here's a small script to
demonstrate:
from test.support import import_fresh_module
import sys
def import_ab(fresh_other):
fresh = ("mymodule._other", ) if fresh_other else ()
mods_out = []
for to_block in "_b", "_a":
blocked = (f"mymodule.{to_block}",)
mods_out.append(import_fresh_module("mymodule",
fresh=fresh, blocked=blocked))
return mods_out
for fresh_other in [True, False]:
mymodule_a, mymodule_b = import_ab(fresh_other)
qualifier = "With" if fresh_other else "Without"
print(f"{qualifier} a fresh import of mymodule._other")
print(f"a: {mymodule_a.attr}")
print(f"b: {mymodule_b.attr}")
print()
When you run it with a suitably configured module on Python 3.8:
$ python importer.py
With a fresh import of mymodule._other
a: A
b: A
Without a fresh import of mymodule._other
a: A
b: B
It also happens if you add `mymodule._a` or `mymodule._b` to the fresh list
when you are trying to block the other one.
I *think* the problem is that in the step where _save_and_remove_module is
called on fresh_name (see here:
https://github.com/python/cpython/blob/76db37b1d37a9daadd9e5b320f2d5a53cd1352ec/Lib/test/support/__init__.py#L328-L329),
it's necessarily populating `sys.modules` with a fresh import of the top-level
module we're trying to import (mymodule) *before* the blocking goes into
effect, then the final call to importlib.import_module just hits that cache.
I think either of the following options will fix this issue:
1. Switching the order of how "fresh" and "blocked" are resolved or
2. Deleting `sys.modules[name]` if it exists immediately before calling
`importlib.import_module(name)
That said, I'm still having some weird statefulness problems if I block a C
module's import and *then* block a Python module's import, so there may be some
other underlying pathology to the current approach.
--
components: Tests
files: test_support_repro.zip
messages: 365702
nosy: brett.cannon, eric.snow, ncoghlan, p-ganssle
priority: normal
severity: normal
status: open
title: test.support.import_fresh_module fails to correctly block submodules
when fresh is specified
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49031/test_support_repro.zip
___
Python tracker
<https://bugs.python.org/issue40173>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40136] add warning to datetime.replace documentation to not use it for setting tzinfo unless UTC or None
Paul Ganssle added the comment: That is a specific problem with the third-party library `pytz`, not a standard feature of the datetime module. Using `datetime.replace` is the intended way to set a time zone, see: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html As of Python 3.6, we've been recommending dateutil.tz instead of pytz, and assuming PEP 615 is accepted ( https://www.python.org/dev/peps/pep-0615/ ), we will have a built in time zone type that supports IANA time zones. I am going to close this because this is not a bug in CPython, but if you think otherwise feel free to continue using this ticket to make the case. -- nosy: +p-ganssle resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33262] Deprecate shlex.split(None) to read from stdin.
Paul Ganssle added the comment: New changeset 975ac326ffe265e63a103014fd27e9d098fe7548 by Zackery Spytz in branch 'master': bpo-33262: Deprecate passing None for `s` to shlex.split() (GH-6514) https://github.com/python/cpython/commit/975ac326ffe265e63a103014fd27e9d098fe7548 -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue33262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40076] isoformat function drops microseconds part if its value is 000000
Paul Ganssle added the comment: > isoformat function does not conform to the ISO 8601 and drops microseconds > part if its value is 00. I'm not sure why you think that this does not conform to ISO 8601 - ISO 8601 is a sprawling beast of a spec and allows some crazy formats. Some examples of perfectly valid ISO 8601 strings: --03-26 2020-W13-4T03 2020-03-26T03.5 2020-03-26T03,5 2020-03-26T03:30:40.334 There are *hundreds* of valid formats encompassed by ISO 8601. Anyway, that's an aside. The behavior of .isoformat() is pretty clearly documented. These are the first three line of the documentation: Return a string representing the date and time in ISO 8601 format: - -MM-DDTHH:MM:SS.ff, if microsecond is not 0 - -MM-DDTHH:MM:SS, if microsecond is 0 I believe Karthikeyan has adequately explained how to get the behavior you want, so I am going to go ahead and close this as working as intended. -- ___ Python tracker <https://bugs.python.org/issue40076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40058] Running test_datetime twice fails with: module 'datetime' has no attribute '_divide_and_round'
Paul Ganssle added the comment: This isn't exactly "working as intended", but I believe it's a known problem with either `import_fresh_module` or `datetime`, as you can see from these comments: https://github.com/python/cpython/blob/302e5a8f79514fd84bafbc44b7c97ec636302322/Lib/test/test_datetime.py#L14-L23 Based on the git blame, those TODO comments are from Georg Brandl, so I'm adding him to the nosy list in case he has some insight. -- nosy: +georg.brandl ___ Python tracker <https://bugs.python.org/issue40058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39970] Combined behavior of datetime.datetime.timestamp() and datetime.datetime.utcnow() on non-UTC timezoned machines
Paul Ganssle added the comment:
@Yi Luan
I think you may misunderstand what the `.timestamp()` function does - it
returns an epoch time, which is the amount of time (in seconds) elapsed since
the Unix epoch: https://en.wikipedia.org/wiki/Unix_time
The number is not different depending on your time zone:
>>> from datetime import *
>>> from dateutil import tz
>>> dt = datetime(2019, 1, 1, tzinfo=timezone.utc)
>>> print(f"{dt}: {dt.timestamp()}")
2019-01-01 00:00:00+00:00: 1546300800.0
>>> dt = dt.astimezone(tz.gettz("America/New_York"))
>>> print(f"{dt}: {dt.timestamp()}")
2018-12-31 19:00:00-05:00: 1546300800.0
>>> dt = dt.astimezone(tz.gettz("Asia/Tokyo"))
>>> print(f"{dt}: {dt.timestamp()}")
2019-01-01 09:00:00+09:00: 1546300800.0
Note how the timestamp number is always the same.
Alexander's suggestion of using `datetime.now(tz=timezone.utc).timestamp()` is
slightly misleading because `datetime.now().timestamp()` and
`datetime.now(tz=timezone.utc).timestamp()` will always return the same value.
I think he was just using that as shorthand for "replace datetime.utcnow() with
datetime.now(tz=timezone.utc) in all cases".
When you have a naive datetime (with no tzinfo), the only options are to pick
the time zone it represents and convert to UTC or to throw an error and say,
"We don't know what time zone this represents, so we cannot do this operation."
Python 2 used to throw an exception, but in Python 3 naive datetimes represent
local times.
If you want "nominal number of seconds since 1970-01-01T00:00:00 *in this time
zone*", you want something more like this:
def seconds_since(dt, epoch=datetime(1970, 1, 1)):
return (dt.replace(tzinfo=None) - epoch).total_seconds()
That does not take into account total elapsed time from DST transitions and the
like - to do that, you'll want something more like this:
def seconds_elapsed_since(dt, epoch=datetime(1970, 1, 1)):
if epoch.tzinfo is None and dt.tzinfo is not None:
epoch = epoch.replace(tzinfo=dt.tzinfo)
return (dt - epoch).total_seconds()
I urge you not to do this in any sort of interop protocol, though, because
integer timestamps are traditionally interpreted as Unix times, and if you
start passing around an integer timestamp that represents "unix time plus or
minus a few hours", you are likely to create bugs when someone mistakes it for
a unix time.
--
___
Python tracker
<https://bugs.python.org/issue39970>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39970] Combined behavior of datetime.datetime.timestamp() and datetime.datetime.utcnow() on non-UTC timezoned machines
Paul Ganssle added the comment: This is the intended behavior of these functions, and there is actually now a warning on both the utcnow and utcfromtimestamp functionsto reflect this: https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow I would say that the correct answer here is to stop using utcnow and utcfromtimestamp (except possibly in very limited circumstance), I have written about it here: https://blog.ganssle.io/articles/2019/11/utcnow.html The preferred way to do this is `datetime.now(tzinfo=datetime.timezone.utc)` or `datetime.fromtimestamp(ts, tzinfo=datetime.timezone.utc)`. The main thing to internalize is that the result of `.timestamp()` always has a time zone, because it is an epoch time, meaning that it is the number of seconds in UTC since 1970-01-01T00:00:00Z. In Python 2, any operations on naive datetimes that required them to represent absolute times were an error, but in Python 3 that was changed and they were treated as local times. Perhaps leaving that behavior as is and having a dedicated "local time" object would have been a good idea, but there are actually some serious problems with doing it that way because it's difficult to define "local time" in such a way that it may not change over the course of an interpreter lifetime, which would cause major issues for an aware datetime (guaranteed not to change over the course of the interpreter lifetime). Treating naive times as local for operations that require localization (without changing their equality and comparison semantics, which is what would cause the problems) is a neat solution to that. Sorry this causes confusion, perhaps in the future we can look into removing the `.utcnow()` and `.utcfromtimestamp()` functions, or renaming them to something else. I'm going to set the status of this as wontfix because this is an intended behavior, but feel free to continue to use the ticket for discussion. Thank you for taking the time to file an issue! -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26460] datetime.strptime without a year fails on Feb 29
Paul Ganssle added the comment: I don't think adding a default_year parameter is the right solution here. The actual problem is that `time.strptime`, and by extension `datetime.strptime` has a strange and confusing interface. What should happen is either that `year` is set to None or some other marker of a missing value or datetime.strptime should raise an exception when it's being asked to construct something that does not contain a year. Since there is no concept of a partial datetime, I think our best option would be to throw an exception, except that this has been baked into the library for ages and would start to throw exceptions even when the person has correctly handled the Feb 29th case. I think one possible "solution" to this would be to raise a warning any time someone tries to use `datetime.strptime` without requesting a year to warn them that the thing they're doing only exists for backwards compatibility reasons. We could possibly eventually make that an exception, but I'm not sure it's totally worth a break in backwards compatibility when a warning should put people on notice. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue26460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)
Change by Paul Ganssle : -- nosy: -p-ganssle ___ Python tracker <https://bugs.python.org/issue39763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39804] timezone constants in time module inaccurate with negative DST (e.g. Ireland)
New submission from Paul Ganssle :
>From a report on the dateutil tracker today, I found that `time.timezone` and
>`time.altzone` are not accurate in Ireland (at least on Linux, not tested on
>other platforms): https://github.com/dateutil/dateutil/issues/1009
Europe/Dublin in the modern era has the exact same rules as Europe/London, but
the values for `isdst` are switched, so for Ireland GMT is the "DST" zone with
a DST offset of -1H, and IST is the standard zone, while London has GMT as the
standard zone and BST as a DST zone of +1h.
The documentation for the timezone constants here pretty clearly say that the
DST zone should be the *second* value in tzname, and should be the offset for
altzone: https://docs.python.org/3/library/time.html#timezone-constants
But when setting my TZ variable to Europe/Dublin I get the same thing as for
Europe/London:
$ TZ=Europe/Dublin python -c \
"from time import *; print(timezone); print(altzone); print(tzname)"
0
-3600
('GMT', 'IST')
$ TZ=Europe/London python -c \
"from time import *; print(timezone); print(altzone); print(tzname)"
0
-3600
('GMT', 'BST')
This would be less of a problem if localtime() were *also* getting isdst wrong
in the same way, but it's not:
$ TZ=Europe/London python -c \
"from time import *; print(localtime())"
time.struct_time(tm_year=2020, tm_mon=3, tm_mday=1, tm_hour=2, tm_min=5,
tm_sec=6, tm_wday=6, tm_yday=61, tm_isdst=0)
$ TZ=Europe/Dublin python -c \
"from time import *; print(localtime())"
time.struct_time(tm_year=2020, tm_mon=3, tm_mday=1, tm_hour=2, tm_min=5,
tm_sec=18, tm_wday=6, tm_yday=61, tm_isdst=1)
So now it seems that there's no way to determine what the correct timezone
offset and name are based on isdst. I'm not entirely sure if this is an issue
in our code or a problem with the system APIs we're calling. This code looks
like a *very* dicey heuristic (I expect it would also have some problems with
Morocco in 2017, even before they were using a type of negative DST, since they
used DST but turned it off from May 21st to July 2nd):
https://github.com/python/cpython/blob/0b0d29fce568e61e0d7d9f4a362e6dbf1e7fb80a/Modules/timemodule.c#L1612
One option might be to deprecate these things as sort of very leaky
abstractions *anyway* and be done with it, but it might be nice to fix it if we
can.
--
messages: 363037
nosy: belopolsky, lemburg, p-ganssle
priority: normal
severity: normal
status: open
title: timezone constants in time module inaccurate with negative DST (e.g.
Ireland)
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39804>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30155] Add ability to get tzinfo from a datetime instance in C API
Paul Ganssle added the comment: So this bug is asking for two things: 1. An official accessor for the `tzinfo` component of an existing datetime, which I think is very reasonable in light of the fact that there are official accessors for all the other components of a datetime. 2. An official constructor for a timezone-aware datetime, which I think basically exists in the form of PyDatetime_CAPI->PyDateTimeAPI->DateTime_FromDateAndTime / ->DateTime_FromDateAndTimeAndFold, and we just need to document it. I think this is basically a separate issue, and I have opened #39604 to track it. I'm going to rename this bug to focus only on issue #1. I think we can accept a PR adding two new macros. I would suggest calling them: - PyDateTime_DATE_GET_TZINFO - PyDateTime_TIME_GET_TZINFO Please make sure to add tests to any PR you make. See the CapiTest case (https://github.com/python/cpython/blob/d68e0a8a165761604e820c8cb4f20abc735e717f/Lib/test/datetimetester.py#L5914) for examples. You may want to look at the git blame for a few of those tests to see the PRs that they were added in, since part of the tests are defined in a C file. (As an aside: I don't love that the accessor methods are not available on the struct, since all the "macro-only" code needs to be re-implemented in all other-language bindings. Since the accessors are already all macro-only, though, might as well keep with the tradition for now :P) -- stage: -> needs patch title: Add ability to get/set tzinfo on datetime instances in C API -> Add ability to get tzinfo from a datetime instance in C API versions: +Python 3.9 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue30155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39604] Document PyDateTimeAPI / PyDateTime_CAPI struct
New submission from Paul Ganssle : The entire public interface documented for the datetime C API is various C macros (see: https://docs.python.org/3/c-api/datetime.html) which are wrappers around function calls to the PyDateTimeAPI / PyDatetime_CAPI struct, but the struct itself is undocumented. Unfortunately (or fortunately, depending on how you think the C API should look), pretty much everyone has to know the implementation details of the C API struct anyway. Bindings in other languages usually can't use the C preprocessor macros and have to directly use the C API struct so projects like PyPy, PyO3 and Cython are using it. The struct also can do things that the macros can't do: consider bug #30155 which is looking for a way to create a datetime object with a tzinfo (which is possible using the C struct). I think we can should go ahead and make the `PyDateTimeAPI` struct "public" and document the functions on it. This may be a bit tougher than one would hope because the overlap between the macros and the struct functions isn't 100%, but it's pretty close, so I would think we'd want to document the two ways to do things rather close to one another. nosy-ing Victor on here in case he has any strong opinions about whether these kinds of struct should be exposed as part of the official public interface. -- assignee: docs@python components: C API, Documentation messages: 361733 nosy: belopolsky, docs@python, lemburg, p-ganssle, vstinner priority: normal severity: normal status: open title: Document PyDateTimeAPI / PyDateTime_CAPI struct versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39604> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39550] isinstance accepts subtypes of tuples as second argument
Paul Ganssle added the comment:
Serhiy: I think at least a test for this particular corner case should be
added, so that no implementations of `isinstance` that use the CPython test
suite hit an infinite recursion in that event, I guess?
Though I think it's maybe an open question as to what the correct behavior is.
Should we throw on any tuple subclass because there's no reason to support
tuple subclasses? Should we switch to using __iter__ when it's defined because
there are other cases where the custom behavior of the subclass is defined by
its __iter__? Should we make it a guarantee that __iter__ is *never* called?
I can't really think of a reason why defining __iter__ on a tuple subclass
would be anything other than a weird hack, so I would probably say either ban
tuple subclasses or add a test like so:
def testIsinstanceIterNeverCalled(self):
"""Guarantee that __iter__ is never called when isinstance is invoked"""
class NoIterTuple(tuple):
def __iter__(self): # pragma: nocover
raise NotImplemented("Cannot call __iter__ on this.")
self.assertTrue(isinstance(1, NoIterTuple((int,
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue39550>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39541] distutils: Remove bdist_wininst (Windows .exe installers) in favor of bdist_wheel (.whl)
Paul Ganssle added the comment: Per my reasoning in the discourse thread, I disagree with this move. I think that this should be handled in setuptools, which is where we tend to handle breaking changes or even enhancements to distutils. If we do this in setuptools, we'll get a backport of the deprecation and removal back to 3.5, and it will make it easier to maintain setuptools. The deprecation of bdist_wininst in Python 3.8 already made it harder to maintain setuptools with no real benefit to the CPython project, I would prefer to not repeat this mistake. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue39541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39280] Don't allow datetime parsing to accept non-Ascii digits
Paul Ganssle added the comment: > Yes, but not within the same format. If someone were to choose the format > '2014-04-10T24:00:00', they would have a reasonable expectation that there is > only one unique string that corresponds with that datetime That's a particularly bad example, because it's exactly the same as another string with the exact same format: 2014-04-11T00:00:00 Since ISO 8601 allows you to specify midnight (and only midnight) using previous day + 24:00. Admittedly, that is the only ambiguity I know of offhand (though it's a huge spec) *for a given format*, but also ISO 8601 does not really have a concept of format specifiers, so it's not like there's a way to unambiguously specify the format you are intending to use. Either way, I think we can explicitly dispense with "there will be an exact mapping between a given (format_str, datetime_str) pair and the datetime it produces" as a goal here. I can't think of any good reason you'd want that property, nor have we made any indication that I can see that we provide it (probably the opposite, since there are some formats that explicitly ignore whitespace). > Okay, since it seems like I'm the only one who wants this change, I'll let it > go. Thanks for your input. I wouldn't go that far. I think I am +0 or +1 on this change, I just wanted to be absolutely clear *why* we're doing this. I don't want someone pointing at this thread in the future and saying, "Core dev says that it's a bug in their code if they don't follow X standard / if more than one string produces the same datetime / etc". I think the strongest argument for making this or a similar change is that I'm fairly certain that we don't have the bandwidth to handle internationalized dates and I don't think we have much to gain by doing a sort of half-assed version of that by accepting unicode transliterations of numerals and calling it a day. I think there are tons of edge cases here that could bite people, and if we don't support this *now* I'd rather give people an error message early in the process and try to point people at a library that is designed to handle datetime localization issues. If all we're going to do is switch [0-9] to \d (which won't work for the places where it's actually [1-9], mind you), I think people will get a better version of that with something like: def normalize_dt_str(dt_str): return "".join(str(int(x)) if x.isdigit() else x for x in dt_str) There are probably more robust and/or faster versions of this, but it's probably roughly equivalent to what we'd be doing here *anyway*, and at least people would have to opt-in to this. I am definitely open to us supporting non-ASCII digits in strptime if it would be useful at the level of support we could provide, but given that it's currently broken for any reasonable use case and as far as I know no one has complained, we're better off resolving the inconsistency by requiring ASCII digits and considering non-ASCII support to be a separate feature request. CC-ing Inada on this as unicode guru and because he might have some intuition about how useful non-ASCII support might be. The only place I've seen non-ASCII dates is in Japanese graveyards, and those tend to use Chinese numerals (which don't match \d anyway), though Japanese and Korean also tends to make heavier use of "full-width numerals" block, so maybe parsing something like "２０２０－０２－０２" is an actual pain point that would be improved by this change (though, again, I suspect that this is just the beginning of the required changes and we may never get a decent implementation that supports unicode numerals). -- nosy: +inada.naoki ___ Python tracker <https://bugs.python.org/issue39280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39280] Don't allow datetime parsing to accept non-Ascii digits
Paul Ganssle added the comment: I don't love the inconsistency, but can you elaborate on the actual *danger* posed by this? What security vulnerabilities involve parsing a datetime using a non-ascii digit? The reason that `fromisoformat` doesn't accept non-ASCII digits is actually because it's the inverse of `datetime.isoformat`, which never *emits* non-ASCII digits. For `strptime`, we're really going more for a general specifier for parsing datetime strings in a given format. I'll note that we do accept any valid unicode character for the date/time separator. >From my perspective, there are a few goals, some of which may be in conflict >with the others: 1. Mitigating security vulnerabilities, if they exist. 2. Supporting international locales if possible. 3. Improving consistency in the API. If no one ever actually specifies datetimes in non-ascii locales (and this gravestone that includes the date in both Latin and Chinese/Japanese characters seems to suggest otherwise: https://jbnewall.com/wp-content/uploads/2017/02/LEE-MONUMENT1-370x270.jpg ), then I don't see a problem dropping our patchy support, but I think we need to carefully consider the backwards compatibility implications if we go through with that. One bit of evidence in favor of "no one uses this anyway" is that no one has yet complained that apparently this doesn't work for "%d" even if it works for "%y", so presumably it's not heavily used. If our support for this sort of thing is so broken that no one could possibly be using it, I suppose we may as well break it all the way, but it would be nice to try and identify some resources that the documentation can point to for how to handle international date parsing. > Note the "unique and unambiguous". By accepting non-Ascii digits, we're > breaking the uniqueness requirement of ISO 8601. I think in this case "but the standard says X" is probably not a very strong argument. Even if we were coding to the ISO 8601 standard (I don't think we claim to be, we're just using that convention), I don't really know how to interpret the "unique" portion of that claim, considering that ISO 8601 specifies dozens of ways to represent the same datetime. Here's an example from [my `dateutil.parse.isoparse` test suite](https://github.com/dateutil/dateutil/blob/110a09b4ad46fb87ae858a14bfb5a6b92557b01d/dateutil/test/test_isoparser.py#L150): ``` '2014-04-11T00', '2014-04-10T24', '2014-04-11T00:00', '2014-04-10T24:00', '2014-04-11T00:00:00', '2014-04-10T24:00:00', '2014-04-11T00:00:00.000', '2014-04-10T24:00:00.000', '2014-04-11T00:00:00.00', '2014-04-10T24:00:00.00' ``` All of these represent the exact same moment in time, and this doesn't even get into using the week-number/day-number configurations or anything with time zones. They also allow for the use of `,` as the subsecond-component separator (so add 4 more variants for that) and they allow you to leave out the dashes between the date components and the colons between time components, so you can multiply the possible variants by 4. Just a random aside - I think there may be strong arguments for doing this even if we don't care about coding to a specific standard. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue39280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30717] Add unicode grapheme cluster break algorithm
Paul Ganssle added the comment: > Oh, also, if y'all are fine with binding to Rust (through a C ABI) I'd love > to help y'all use unicode-segmentation, which is much less work that pulling > in ICU. Otherwise if y'all have implementation questions I can answer them. > This spec is kinda tricky to implement efficiently, but it's not super hard. Is the idea here that we'd take on a new dependency on the compiled `unicode-segmentation` binary, rather than adding Rust into our build system? Does `unicode-segmentation` support all platforms that CPython supports? I was under the impression that Rust requires llvm and llvm doesn't necessarily have the same support matrix as CPython (I'd love to be corrected if I'm wrong on this). (Note: I don't actually know what the process is for taking on new dependencies like this, just trying to point at one possible stumbling block.) -- ___ Python tracker <https://bugs.python.org/issue30717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13305] datetime.strftime("%Y") not consistent for years < 1000
Change by Paul Ganssle : -- versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue13305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39103] [linux] strftime renders %Y with only 3 characters
Paul Ganssle added the comment:
This is a duplicate of issue 13305.
Right now we have some shims around `strftime` to improve consistency in some
situations and for other reasons, but mostly we just call the libc version.
There is an open issue from 2008 (#3173) to ship our own implementation of
strftime that could smooth out some of these issues and try and make the
behavior more consistent (though presumably some people have started to rely on
platform-specific behaviors by now, so it may be a decent amount of work to
roll it out).
I'm going to close this in favor of 13305, but thanks for reporting it!
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> datetime.strftime("%Y") not consistent for years < 1000
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue39103>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38914] Clarify wording for warning message when checking a package
Paul Ganssle added the comment: For the future, we generally tend to keep distutils pretty "frozen", only making minor changes or the changes needed to build Python itself. Instead we generally make changes in setuptools, which for the moment monkey-patches distutils (and into which distutils will eventually be merged). One of the big reasons is that setuptools is used across all versions of Python, so the changes are automatically backported, whereas changes to distutils will only be seen by people using the most recent Python versions. In this case, it's not really a substantive change, so I think we can leave it in distutils, I just wanted to bring this up as an FYI. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue38914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38812] Comparing datetime.time objects incorrect for TZ aware and unaware
Paul Ganssle added the comment: I do not think this is a bug in pytz, but if it's a bug in Python it's one in reporting what the error is. The issue is that the time zone offset for "rules-based zones" like America/Denver (i.e. most time zones) is *undefined* for bare times, because the offset that apply depends on the *date* and the *time*. The documentation for `tzinfo.utcoffset` specifies that if the offset is unknown, a time zone offset should return None: https://docs.python.org/3/library/datetime.html#datetime.tzinfo.utcoffset The documentation for determining whether an object is aware or naive also specifies that if utcoffset() returns `None`, the object is naive (even if tzinfo is not None): https://docs.python.org/3/library/datetime.html#determining-if-an-object-is-aware-or-naive So basically, everyone is doing the right thing except the person who attached this `pytz` time zone to a time object (as a side note, it may be worth reading this blog post that explains why the way this time zone is attached to the `time` object is incorrect: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html). That said, we may be able to improve the error message raised here by distinguishing between the case where there's no `tzinfo` at all and the case where `utcoffset()` returns `None`. I think we can change the exception message to have a helpful hint like, "cannot compare offset-naive and offset-aware times; one of the operands is offset-naive because its offset is undefined." We could possibly be even more specific. -- components: +Library (Lib) versions: +Python 3.9 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue38812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37527] Timestamp conversion on windows fails with timestamps close to EPOCH
Paul Ganssle added the comment: Ah, my mistake. The examples all use `datetime.fromtimestamp`, so I didn't notice that it was failing only on the `timestamp` side. Re-opening, thanks! -- resolution: duplicate -> status: closed -> open superseder: [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6 -> ___ Python tracker <https://bugs.python.org/issue37527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0
Paul Ganssle added the comment: This has been coming up in a few different contexts lately, so I think it would be really good if we could get some sort of fix for it. One option is to implement our own versions of these APIs for use in Windows, but a thought occurred to me recently: we have not investigated the possibility of seeing if Microsoft would be willing to either add support for negative timestamps in their localtime() or gmtime() implementations or add a new API that *does* support negative timestamps. It would also be good to rule out the possibility that such APIs already exist but we just don't know about them (preliminary googling doesn't show anything, though possibly something can be done with the Win32 APIs? Not sure how or if those work in C and how big a lift it would be to maintain compatibility if can switch: https://docs.microsoft.com/en-us/windows/win32/sysinfo/time-functions?redirectedfrom=MSDN ). Adding Steve Dower to the nosy list in case he can shed some light onto the possibility of native support. -- nosy: +steve.dower ___ Python tracker <https://bugs.python.org/issue36439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38233] datetime.datetime.fromtimestamp have different behaviour on windows and mac
Paul Ganssle added the comment: Changing the superceder here as I think #36439 matches better than #37527. -- nosy: +p-ganssle resolution: duplicate -> status: closed -> open superseder: Timestamp conversion on windows fails with timestamps close to EPOCH -> Inconsistencies with datetime.fromtimestamp(t) when t < 0 ___ Python tracker <https://bugs.python.org/issue38233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37527] Timestamp conversion on windows fails with timestamps close to EPOCH
Paul Ganssle added the comment: This indeed seems to be a duplicate of 29097, which is fixed in Python 3.7, so we can close this bug. Thank you for your report Dschoni, and thank you for finding the duplicate Ma Lin! -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6 ___ Python tracker <https://bugs.python.org/issue37527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7980] time.strptime not thread safe
Paul Ganssle added the comment: >From what I can tell, this is a Python 2.7-only bug, and it's not a security >issue, so I think we can close the issue as either "wontfix" (because we won't >fix it in Python 2) or "fixed" (because it is already fixed in Python 3), >depending on your perspective. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue7980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35540] dataclasses.asdict breaks with defaultdict fields
Paul Ganssle added the comment: I checked and it appears that `attrs` handles this by creating *all* dicts using the default dict_factory (similar to my original suggestion of just using `dict` instead of the specific type), if I'm reading this right: https://github.com/python-attrs/attrs/blob/master/src/attr/_funcs.py#L102 Using `attr.asdict` seems to bear this out, as `defaultdict` attributes are converted to `dict` when the dict factory is not specified. I think changing the default behavior like that would be a backwards-incompatible change at this point (and one that it's really hard to warn about, unfortunately), but we could still use the "fall back to dict_factory" behavior by trying to construct a `type(obj)(...)` and in the case of an exception return `dict_factory(...)`. -- ___ Python tracker <https://bugs.python.org/issue35540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35540] dataclasses.asdict breaks with defaultdict fields
Paul Ganssle added the comment: Considering that `namedtuple` is special-cased, I think it's reasonable to special-case `defaultdict` as well, though it may be worth considering more general solutions that will also work for things other than the standard library. One would be to solve this the same way that other "subclasses may have a different constructor" problems are solved (e.g. `float`, `int`, formerly `datetime`) and ignore the subclass (or selectively ignore it if it's a problem), for example changing _asdict_inner to something like this: if isinstance(obj, dict): new_keys = tuple((_asdict_inner(k, dict_factory), _asdict_inner(v, dict_factory)) for k, v in obj.items()) try: return type(obj)(new_keys) except Exception: return dict(new_keys) Another more general alternative would be to add a type registry for `asdict`, either as an additional parameter or with a new transformer class of some sort. I created a quick proof of concept for this in GH-16356 to see one way it could look. In any case I think it's quite unfortunate that we can't easily just support anything that has a __deepcopy__ defined. There may be some crazy solution that involves passing a class with a custom __getitem__ to the `memo` argument of copy.deepcopy, but if it's even possible (haven't thought about it enough) I'm not sure it's *advisable*. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue35540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35540] dataclasses.asdict breaks with defaultdict fields
Change by Paul Ganssle : -- pull_requests: +15935 pull_request: https://github.com/python/cpython/pull/16356 ___ Python tracker <https://bugs.python.org/issue35540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38155] Add __all__ to the datetime module
Paul Ganssle added the comment: Closing this as resolved. I don't think we should backport this, as it's more of an enhancement than a bug fix (and since no one has ever complained about it to my knowledge, I don't think there's any big rush to see this released). Thanks Tahia and all the reviewers! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38155] Add __all__ to the datetime module
Paul Ganssle added the comment: New changeset 96b1c59c71534db3f0f3799cd84e2006923a5098 by Paul Ganssle (t k) in branch 'master': bpo-38155: Add __all__ to datetime module (GH-16203) https://github.com/python/cpython/commit/96b1c59c71534db3f0f3799cd84e2006923a5098 -- ___ Python tracker <https://bugs.python.org/issue38155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30367] Cannot build CPython3.6 with module “testcapimodule” statically
Paul Ganssle added the comment: Is this issue only in Python 3.6? I believe Python 3.6 is only receiving security fixes at the moment, so this could only be fixed in 3.7, 3.8 and 3.9. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue30367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Paul Ganssle added the comment: The current state of the PR doesn't hinge on the pure Python implementation, we went with a very simple tuple subclass to keep the two more closely in sync and because we don't need any of the additional functionality that namedtuple brings, but if it were any more complicated than what we did we probably would have just gone with a namedtuple. The only thing that's holding things up now is that we're working out a way to maintain the ability to pickle the object without making the class public. This is not really a hard requirement, but I'd like to give it an honest effort before calling it a day and just relying on "it's not in __all__, therefore it's not public." (I should note that we can only take that approach after issue #38155 is resolved, which is another reason for the delay). In any case, the bulk of the conversation on the implementation has been taking place on GH-15633, sorry for the split discussion location, folks. -- ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37555] _CallList.__contains__ doesn't always respect ANY.
Paul Ganssle added the comment: New changeset d6a9d17d8b6c68073931dd8ffa213b4ac351a4ab by Paul Ganssle (Elizabeth Uselton) in branch 'master': bpo-37555: Update _CallList.__contains__ to respect ANY (#14700) https://github.com/python/cpython/commit/d6a9d17d8b6c68073931dd8ffa213b4ac351a4ab -- ___ Python tracker <https://bugs.python.org/issue37555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38155] Add __all__ to the datetime module
Paul Ganssle added the comment: Actually, how about adding this simpler test into `Lib/test/datetimetester.py`, right above test_name_cleanup (https://github.com/python/cpython/blob/ff2e18286560e981f4e09afb0d2448ea994414d8/Lib/test/datetimetester.py#L65): def test_all(self): """Test that __all__ only points to valid attributes.""" all_attrs = dir(datetime_module) for attr in datetime_module.__all__: self.assertIn(attr, all_attrs) This will at least test that __all__ only contains valid attributes on the module. -- ___ Python tracker <https://bugs.python.org/issue38155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38155] Add __all__ to the datetime module
Paul Ganssle added the comment: Hi Tahia: Go ahead and make a PR, no need to worry about the test. I mainly put in the bit about tests because I was hoping to nerd-snipe someone into figuring out how to do it for me ;) It's not a particularly important test. -- ___ Python tracker <https://bugs.python.org/issue38155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38155] Add __all__ to the datetime module
New submission from Paul Ganssle : Currently the datetime module has no __all__, which means we only advertise what is public and private based on leading underscores. Additionally, because there are two implementations (Python and C), you actually get different things when you do `from datetime import *` depending on whether you have the C module installed or not. The "easy" part is to add an __all__ variable to Lib/datetime.py for all the documented attributes: __all__ = ["date", "datetime", "time", "timedelta", "timezone", "tzinfo", "MINYEAR", "MAXYEAR"] A "stretch goal" would be to add a test to ensure that `from datetime import *` imports the same set of symbols from the pure python module that it does from the C module. I haven't quite thought through how this would be achieved, probably something in test_datetime (https://github.com/python/cpython/blob/6a517c674907c195660fa9178a7b561de49cc721/Lib/test/test_datetime.py#L1), where we need to import both modules anyway. I think we can accept an "add __all__" PR without tests, though. -- components: Library (Lib) keywords: newcomer friendly messages: 352280 nosy: belopolsky, p-ganssle priority: normal severity: normal stage: needs patch status: open title: Add __all__ to the datetime module type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37488] Document the "gotcha" behaviors in utcnow() and utcfromtimestamp()
Paul Ganssle added the comment: Thanks Joannah! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37488> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38139] [BUG] datetime.strptime could not handle timezone
Paul Ganssle added the comment: Hi Yixing, thank you for your bug report. This issue has already been reported, and the discussion is in issue #22377. In the short term I believe the solution will be to document the current behavior. In the long term there are some solutions, though I imagine none of them will be amazingly satisfying, because the output of %Z is basically freeform and doesn't necessarily match to an unambiguous offset. The best you'd be able to do would be %Z%z or %z%Z, but there will be many implementation challenges there. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> %Z in strptime doesn't match EST and others ___ Python tracker <https://bugs.python.org/issue38139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22377] %Z in strptime doesn't match EST and others
Change by Paul Ganssle : -- stage: -> needs patch versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue22377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13927] Document time.ctime format
Paul Ganssle added the comment: We've merged the PR and I think it resolves this issue, so we can close this issue now. Please let me know if it's not fully resolved and we can re-open. Thanks Roger for reporting this and Harmandeep for making the PR and requested changes. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: behavior -> enhancement ___ Python tracker <https://bugs.python.org/issue13927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13927] Document time.ctime format
Paul Ganssle added the comment: New changeset 2d32bf1ef23c9e468b2e8afab3c24e7a2047ac36 by Paul Ganssle (Harmandeep Singh) in branch 'master': bpo-13927: time.ctime and time.asctime return string explantion (GH-11303) https://github.com/python/cpython/commit/2d32bf1ef23c9e468b2e8afab3c24e7a2047ac36 -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue13927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38096] Clean up the "struct sequence" / "named tuple" docs
Paul Ganssle added the comment: Sorry guys, my mistake. I think I was a bit caught up in the workflow at the sprint where I've been going through the review-cleanup-merge process a lot faster than I usually do (partially since I have the time and partially since the huge number of PRs getting merged is requiring a lot of rebases, so it's better to get them in quicker). No need to worry, I will not merge any of your PRs in the future unless you request it for some reason. -- ___ Python tracker <https://bugs.python.org/issue38096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38121] Synchronize importlib.metadata with importlib_metadata 0.22
Paul Ganssle added the comment: New changeset 8ed6503eca4e3ea4949479d8d7fd9ffd54f81038 by Paul Ganssle (Jason R. Coombs) in branch 'master': bpo-38121: Sync importlib.metadata with 0.22 backport (GH-15993) https://github.com/python/cpython/commit/8ed6503eca4e3ea4949479d8d7fd9ffd54f81038 -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue38121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38096] Clean up the "struct sequence" / "named tuple" docs
Change by Paul Ganssle : -- pull_requests: +15596 stage: backport needed -> patch review pull_request: https://github.com/python/cpython/pull/15962 ___ Python tracker <https://bugs.python.org/issue38096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38096] Clean up the "struct sequence" / "named tuple" docs
Change by Paul Ganssle : -- pull_requests: +15595 status: pending -> open pull_request: https://github.com/python/cpython/pull/15961 ___ Python tracker <https://bugs.python.org/issue38096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38096] Clean up the "struct sequence" / "named tuple" docs
Change by Paul Ganssle : -- resolution: -> fixed stage: patch review -> backport needed status: open -> pending ___ Python tracker <https://bugs.python.org/issue38096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38096] Clean up the "struct sequence" / "named tuple" docs
Paul Ganssle added the comment: New changeset 7117074410118086938044c7a4ef6846ec1662b2 by Paul Ganssle (Raymond Hettinger) in branch 'master': bpo-38096: Clean up the "struct sequence" / "named tuple" docs (GH-15895) https://github.com/python/cpython/commit/7117074410118086938044c7a4ef6846ec1662b2 -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue38096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36960] Make datetime docs more user-friendly
Change by Paul Ganssle : -- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue36960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36960] Make datetime docs more user-friendly
Paul Ganssle added the comment: New changeset 3fb1363fe87a24cdb2ee1dd9746f1c49046af958 by Paul Ganssle (Brad) in branch 'master': Overhaul datetime documentation (GH-13410) https://github.com/python/cpython/commit/3fb1363fe87a24cdb2ee1dd9746f1c49046af958 -- ___ Python tracker <https://bugs.python.org/issue36960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37499] test_gdb.test_pycfunction should use dedicated test functions
Paul Ganssle added the comment: This is done, thanks Petr and Jeroen! I don't see a need to backport this unless we also want to backport GH-14311 or something else that depends on it. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38082] datetime.time object incorrectly shows associated date in strftime() output
Paul Ganssle added the comment: Hi Abhisek, This is actually the expected / intended behavior, and it is documented under "strptime() and strftime() behavior": https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior (which is linked to by the time.strftime documentation: https://docs.python.org/3/library/datetime.html#datetime.datetime.strftime . The relevant section is: For time objects, the format codes for year, month, and day should not be used, as time objects have no such values. If they’re used anyway, 1900 is substituted for the year, and 1 for the month and day. If I were designing `datetime.time.strftime` from scratch, my instinct would be to throw an error in this case, but my philosophy on parsing interfaces tends towards the stricter side. At this point, I think it would do more harm than good to change this behavior. I imagine that the motivation is something like the Robustness Principle ( https://en.wikipedia.org/wiki/Robustness_principle ), but I wasn't involved in the original design so I can't be sure. Thank you for taking the time to make a bug report, it's very appreciated even when it turns out to not be a bug. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38065] Document the datetime capsule API
New submission from Paul Ganssle : The datetime module has a capsule API, which is very useful for other languages' bindings, but the C API documentation for datetime only covers the C macros: https://docs.python.org/3/c-api/datetime.html The current extent of the documentation is that everyone who wants to bind to the C API (PyO3, Cython, pypy, etc), you need to just read the struct definition ( https://github.com/python/cpython/blob/master/Include/datetime.h#L150 ) and reads `_datetimemodule.c`. There's even some question as to whether the capsule is public (see, e.g. https://github.com/PyO3/pyo3/pull/393#issuecomment-476664650 ), when in fact I'm fairly certain that it's actually *preferred* to use the capsule API. Most or many of the macros are thin wrappers around the capsule API, so we may need to figure out whether we want to try and use the same "documentation" for both versions, e.g.: .. c:function:: PyObject* PyDateTime_CAPI.Date_FromDate(int year, int month, int day, PyTypeObject* cls) .. c:function:: PyObject* PyDate_FromDate(int year, int month, int day) Return a :class:`datetime.date` object with the specified year, month and day. The version of this function in the capsule module takes an additional argument representing the specific subclass to construct. Could replace: .. c:function:: PyObject* PyDate_FromDate(int year, int month, int day) Return a :class:`datetime.date` object with the specified year, month and day. I would say that we also need a paragraph or two at the beginning of the C API document explaining why there are two ways to access most of these things? A more minor bikeshedding-y issue is how we should stylize these: PyDatetime_CAPI.x? PyDatetime_CAPI->x? A dedicated RST directive? Something else? -- assignee: docs@python components: Documentation messages: 351427 nosy: belopolsky, docs@python, eric.araujo, ezio.melotti, mdk, p-ganssle, willingc priority: normal severity: normal status: open title: Document the datetime capsule API type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Paul Ganssle added the comment: I have compiled both versions with optimizations on, looks like the gap gets a bit smaller (percentage-wise) after that: benchmark| master (ns) | PR 15633 (ns) | Δ (%) +---+-+-- call only (datetime)| 73 (±3) | 92.3 (±7) | 26 constructor + call (datetime) |228 (±9) | 260 (±16) | 14 timedelta + call (datetime) |108 (±5) | 128 (±9)| 18 If this were something fundamental like a performance regression in building a tuple or constructing a dictionary or something I'd be concerned, but this just reinforces my feeling that, on balance, this is worth it, and that we are probably not going to need a "fast path" version of this. -- ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Paul Ganssle added the comment: I haven't had time to try this with an optimized build, I have done a few more benchmarks using a standard build, I'm seeing almost a 50% regression on isocalendar() calls, but the picture is a little rosier if you consider the fact that you need to construct a `date` or `datetime` object in the first place and anyone concerned with performance will likely be making exactly one `isocalendar()` call per datetime object. The common case is that they construct the datetime with a datetime literal or something equivalent. The "worst case scenario" is that they construct a single "seed" datetime and then construct many new datetimes with faster operations like adding a timedelta. I have compared the following cases: call only: -s 'import datetime; dt = datetime.datetime(2019, 1, 1)' 'dt.isocalendar()' constructor + call: -s 'import datetime' 'dt = datetime.datetime(2019, 1, 1); dt.isocalendar()' timedelta + call: -s 'import datetime; dt = datetime.datetime(2019, 1, 1); td = timedelta(days=1)' '(dt + td).isocalendar()' The results are summarized below, the most likely real practical impact on performance-sensitive "hot loops" would be a 29% performance regression *if* isocalendar() is the bottleneck: benchmark| master (ns) | PR 15633 (ns) | Δ (%) +---+-+-- call only (datetime)|349 (±14) | 511 (±22) | 46 constructor + call (datetime) |989 (±48) |1130 (±50) | 14 timedelta + call (datetime) |550 (±14) | 711 (±22) | 29 The numbers for `datetime.date` are basically similar: benchmark| master (ns) | PR 15633 (ns) | Δ (%) +---+-+-- call only (date)|360 (±18) | 530 (±41) | 47 constructor + call (date) |824 (±17) | 975 (±29) | 18 timedelta + call (datetime) |534 (±20) | 685 (±24) | 28 This is a bit disheartening, but I think the fact that these performance sensitive situations are rare and the "grab a single component" use is overwhelmingly the common case, I think it's worth it in the end. If there are significant complaints about the performance regression, we may be able to create a variant method similar to the way that `chain` has `chain.from_iterables`, something like `dt.isocalendar.as_tuple()` for the performance-sensitive folks. That said, that's very YAGNI, we should not do that unless someone comes forward with a real use case that will be adversely affected here. -- ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Paul Ganssle added the comment: In an effort to get a sense of how useful this would actually be, I did a code search for `.isoformat()` on github. I saw a few doctests that will break (if they're even being run) if we make this change, but I also found that the *vast* majority of uses of `isocalendar` seem to be people pulling out a single component of it, like: `return datetime.datetime.now().isocalendar()[1]`. That is not the kind of usage pattern I was envisioning when I said that this was a marginal improvement, a *lot* of this code could be made considerably more readable with named fields. If indeed the performance is similar or the same and this won't impact consumers of the pure python version of the module unduly (I checked in #pypy and they think that it shouldn't be more than a minor irritation if anything), then I am changing my -1 to a +1. -- assignee: tim.peters -> p-ganssle ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Paul Ganssle added the comment: > What IS unprecedented is having a C function bend over backwards to return an > instance of collections.namedtuple(). Is this an issue that anyone is currently insisting upon? From what I can tell the current implementation uses a structseq and none of my objections had to do with the properties of a structseq. > ISTM the cross-version pickling issue is minor red herring. We've cheerfully > upgraded tuples to structseqs on a number of occasions and it hasn't been an > issue. I generally agree with this - it is nice to not break this compatibility when there's no good reason to do so, but pickling data in one version of Python and unpickling it in another is not something that's supported by the pickle module anyway. > Tim, would you please weigh in on this so we can put this to bed, either > closing the request because we're too meek to make any change, upgrading to structseq to provide the requested functionality, or twisting our code in weird ways to have a C function become dependent on a pure python module. I must take some umbrage at this framing of the question. I don't even know where meekness comes into it - adding *any* new functionality brings support burdens and additional code complexity and changes to code that's been stable for a long time like `dateutil.isocalendar` is particularly likely to cause breakages if only because of the time people have had to start relying on the specific implementation. I have merely asked for a justification and an argument other than your subjective judgement that this is a nice improvement. -- ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Paul Ganssle added the comment: > Dong-hee Na, if you want to make a fresh PR for this and bring it to > fruition, I would be happy to review and apply it. It seems premature to say that you will accept a PR for this when there's no consensus for actually adding the feature, and it would be good to probably work out if it's even desirable before asking contributors to do more work on it. It seems like it would be better to argue the point of *why* you think a structseq actually solves the problem here. Is a struct sequence more backwards compatible than a namedtuple? Less? Is it as performant? Will it make it easier or harder to maintain compatibility between the C and pure Python implementations of the datetime module? -- ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Paul Ganssle added the comment: > But I'm wondering how the `fromisocalendar` API relates to this patch. > Rather, wouldn't this patch contribute to improving the usability of the > `fromisocalendar` API? The `fromisocalendar` API relates to this patch only insofar as it is the inverse function of `isocalendar` and in some sense it allows specifying the parameters by keyword rather by position. I was merely bringing up that we didn't choose that API because we thought people would or should want or need to specify the individual components by keyword but because we didn't have an easy way to maintain the same API in the pure Python and C APIs at the time. By contrast, returning a plain tuple from `isocalendar()` is the easier *and* more performant thing to do, and given that any benefits seem marginal I'm against the switch. I think that the usability of `fromisoformat` with the output of `isocalendar` will be largely unchanged if we were to switch to returning a namedtuple. -- ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Paul Ganssle added the comment: Sorry for the late response after a patch, but I'm actually -1 on this patch. I don't think it buys us very much in terms of the API considering it only has 3 parameters, and it adds some complexity to the code (in addition to the performance issue). Honestly, I think the main reason we didn't go with positional-only parameters in `fromisocalendar` was that the "/" syntax didn't exist yet. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
