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")
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 i
Change by Paul Ganssle :
--
stage: -> needs patch
___
Python tracker
<https://bugs.python.org/issue40236>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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/issu
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
Change by Paul Ganssle :
--
pull_requests: +19318
pull_request: https://github.com/python/cpython/pull/20006
___
Python tracker
<https://bugs.python.org/issue40
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
co
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
Change by Paul Ganssle :
--
pull_requests: +19343
pull_request: https://github.com/python/cpython/pull/20034
___
Python tracker
<https://bugs.python.org/issue40
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 a
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/issu
Change by Paul Ganssle :
--
pull_requests: -19344
___
Python tracker
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe:
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, s
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
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/
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
Change by Paul Ganssle :
--
pull_requests: +19420
pull_request: https://github.com/python/cpython/pull/20113
___
Python tracker
<https://bugs.python.org/issue24
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/1b97b9b0ad9a2ff8eb5c8f2e2e7c2a
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
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 t
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/b17e49e0def23238b9e7f48c8
Change by Paul Ganssle :
--
pull_requests: +19461
pull_request: https://github.com/python/cpython/pull/20158
___
Python tracker
<https://bugs.python.org/issue40
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
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/e527ec8abe0849e784ce100f53c273
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!
--
___
Py
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
New submission from Paul Ganssle :
This is a code style issue — in https://github.com/python/cpython/pull/23614, a
regression was deliberately introduced to satisfy an overzealous compiler. The
`day` variable has logical bounds `0 <= day <= 6`. In the original code, both
sides o
Paul Ganssle added the comment:
As I mentioned, it's a style issue. Yes this did not introduce any
user-observable bugs, nor should it have changed the machine code emitted by
the assembly on any competent compiler.
The issue is that I had deliberately chosen to do a "redundant
Paul Ganssle added the comment:
> Just my two cents, this isn't just "some compilers". Everything from gcc,
> msvc, C# to the rust compiler complain about this sort of code. As they
> should, this is effectively dead code.
They complain because most of the time it&#
Paul Ganssle added the comment:
There are at least two issues with this:
1. This is a constructor for a struct, and the struct would really
unnecessarily balloon in size if we switched everything over to be 32-bit
integers (which I think is your suggestion?). This is not a major concern
Paul Ganssle added the comment:
> Adding a static assertion about the signedness of uint8_t looks meaningless
> to me.
My proposal is to add a static assertion that `day` is an unsigned type. In the
code it would look something like it does in the backports.zoneinfo code
New submission from Paul Ganssle :
TZif files consist of a list of transitions followed by a POSIX TZ var-style
string of a form like "AAA3BBB,M3.2.0/01:30,M11.1.0/02:15:45", which decodes to
"AAA (UTC-3) is the standard time and BBB (UTC-2) is the DST time, DST applies
start
Paul Ganssle added the comment:
For future reference, this bug is triggered only when `.fromutc` is called on a
subclass of `datetime` and the resulting date is the second ambiguous time
(e.g. if there's a DST transition from 02:00 → 01:00, and the result of the
`.fromutc` call i
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +23025
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24200
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
This particular grep statement is used to validate the `tzpath` variable.
Apparently it is easy enough to achieve what I was going for using vanilla grep
with no options, so I've created GH-24200 to fix the issue.
I notice that there are other uses o
Paul Ganssle added the comment:
Re-opening because this was merged without tests.
@ZackerySpytz would you mind adding tests to hit these error cases? I've spent
some time satisfying myself that it's indeed possible, and I've detailed a
general outline here:
https://gi
Paul Ganssle added the comment:
The evidence you have here seems pretty compelling and this change seems
straightforward enough. I don't see an expert listed here, but I'm happy to
merge a docs PR fixing this.
Probably a good idea to make a PR to typeshed in parallel, in case
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue43382>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
$ b
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
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/issu
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
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/2abededbc4165d2daa14ae9d74b1f3
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&quo
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
Change by Paul Ganssle :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue40705>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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/06a1b8915d6674e40f0dccc42
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
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue40777>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
pull_requests: +19849
pull_request: https://github.com/python/cpython/pull/20624
___
Python tracker
<https://bugs.python.org/issue40
Paul Ganssle added the comment:
This is a duplicate of bpo-13305 and is due to platform-specific
implementations of %Y. On Linux, `strftime()` does not zero-pad to 4, and if
you need to represent years <1000, you should use "%4Y" to zero-pad the output.
I think the ideal resolu
New submission from Paul Ganssle :
While developing a shim for deprecating pytz, I discovered this issue with the
Pacific/Rarotonga zone:
>>> from datetime import datetime, timedelta
>>> from backports.zoneinfo import ZoneInfo
>&
New submission from Paul Ganssle :
Apparently in 1938, Madrid had a "double daylight saving time", where they
transitioned from WET (+0) → WEST (+1) → WEMT (+2) → WEST (+1) → WET (+0):
$ zdump -V -c 1938,1940 'Europe/Madrid'
Europe/Madrid Sat Apr 2 22:59:59 1938 UT = Sat
New submission from Paul Ganssle :
Related to bpo-40930 and bpo-40931, it *seems* that in 1942 only,
`zoneinfo.ZoneInfo` returns -01:00 for DST in Europe/Minsk:
>>> from datetime import datetime, timedelta
>>> from backports.zoneinfo import ZoneInfo
>>>
New submission from Paul Ganssle :
In the C implementation of zoneinfo.ZoneInfo, __init_subclass__ is not declared
as a classmethod, which prevents it from being subclassed. This was not noticed
because the tests for ZoneInfo subclasses in C are actually testing
zoneinfo.ZoneInfo, not a
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +20143
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/20965
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Ganssle :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue41059>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
nosy_count: 3.0 -> 4.0
pull_requests: +20249
pull_request: https://github.com/python/cpython/pull/21083
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
New changeset bc43f6e21244f31d25896875430174cd4ac7604c by Ram Rachum in branch
'master':
bpo-41065: Use zip-strict in zoneinfo (GH-21031)
https://github.com/python/cpython/commit/bc43f6e21244f31d25896875430174
Paul Ganssle added the comment:
New changeset 6c56356109616ea1292aafa48d30536279ec0937 by Paul Ganssle in
branch '3.9':
[3.9] bpo-41056: Fix a possible MemoryError leak within zoneinfo. (GH-21007)
https://github.com/python/cpython/commit/6c56356109616ea1292aafa48d3053
Paul Ganssle added the comment:
There's a pretty clear warning on the documentation that utcfromtimestamp is
unsuitable for this purpose:
https://docs.python.org/3/library/datetime.html#datetime.datetime.utcfromtimestamp
What you want is a datetime that knows what time zone it's i
Paul Ganssle added the comment:
> bout _strptime, I see that the time.strptime() imports internally the
> _strptime module.
Ah, sorry, my remark about including `_strptime` was off the cuff — I thought
it was only used in `datetime`, which is why I said "possibly _strptime"
Paul Ganssle added the comment:
As for deciding between moving to `datetime/` and moving to `_pydatetime`, I
think we should send an e-mail to Python-Dev about it to get a wider
perspective, because the import machinery is a lot of black magic, and I know
that there are large proprietary
Paul Ganssle added the comment:
I think a positional-only argument would be the best option if we could do it,
but it would be a backwards-incompatible change and it's probably not worth the
hassle.
If anyone is using the keyword argument, they're probably using `format=`
rather
Paul Ganssle added the comment:
> So what is the plan to continue to support building cpython itself which
> depends on Distutils? Currently the build bootstraps itself without the aid
> of an existing Python interpreter instance. There would also be major impacts
> across the w
Paul Ganssle added the comment:
> I don't think it's a good idea to replace bad habits from distutils with bad
> habits in setuptools._distutils. And this is exactly what you get with
> pointing directly to setuptools.
These are two different questions. We're not ask
Paul Ganssle added the comment:
Oops, just realized my previous post said `pip install distutils`. I meant to
say that `pip install setuptools` will provide the `distutils` module (right
now you do `import setuptools; import distutils` and you get the
setuptools-provided version; we&#x
Paul Ganssle added the comment:
Hi dh4931 — this is the expected result, assuming that the offsets changed
between those two dates in your system local time.
The .timestamp() method returns an epoch time, which is the number of seconds
since 1970-01-01T00:00:00 UTC, and so it is inherently
Paul Ganssle added the comment:
I think it is unlikely that we'll want to experiment with this directly in
CPython. I don't think a fixed format (other than the annoying one that you
already get from calling `str` on a timedelta) is appropriate, but designing a
modular forma
Paul Ganssle added the comment:
I think for now skipping the tests when lzma is missing is the easiest thing,
though another option would be to drop the compression on the input test data
so that the tests don't depend on lzma.
Taking a look at the data files, it looks like we get arou
Paul Ganssle added the comment:
Thanks Filipe!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.8
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
Now that issue #16995 is resolved, I think we can move forward with updating
the text.
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue36
Paul Ganssle added the comment:
I think that `ZoneInfo('__init__.py')` is also a problem, but a slightly
different one. That comes from the fact that in order to support
`importlib.resources`, each of the zoneinfo subdirectories needs an
`__init__.py`, but the ZoneInfo construc
Paul Ganssle added the comment:
By the way, it might be easiest to start with a PR against backports.zoneinfo,
because I have a lot more linting, coverage and format checks set up there:
https://github.com/pganssle/zoneinfo
--
___
Python tracker
Paul Ganssle added the comment:
New changeset 87d8287865e5c9f137f6b5cf8c34c2c509eb5e9d by Paul Ganssle in
branch 'master':
bpo-41025: Fix subclassing for zoneinfo.ZoneInfo (GH-20965)
https://github.com/python/cpython/commit/87d8287865e5c9f137f6b5cf8c34c2
Paul Ganssle added the comment:
New changeset 33d3c64095bcdf9066a3441f6dda5d2e2f4118a8 by Miss Islington (bot)
in branch '3.9':
bpo-41025: Fix subclassing for zoneinfo.ZoneInfo (GH-20965) (GH-21876)
https://github.com/python/cpython/commit/33d3c64095bcdf9066a3441f6dda5d
Paul Ganssle added the comment:
Łukasz: Would it be possible to backport / cherry-pick the changes from PR
GH-21876 (https://github.com/python/cpython/pull/21876) into the 3.9.0 branch?
I think this is a fairly severe issue considering that pendulum is planning to
use a zoneinfo subclass
Change by Paul Ganssle :
--
stage: patch review -> backport needed
___
Python tracker
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mai
Paul Ganssle added the comment:
Marking as release blocker to put it on the checklist. Feel free to demote it
if you decide it should be deferred to 3.9.1.
--
priority: high -> release blocker
resolution: -> fixed
___
Python tracker
Paul Ganssle added the comment:
There are two refleaks here. One is a reference leaking to the weak cache in
`__init_subclass__` (one leak every time a subclass is created), and the other
is that when `subclass.clear_cache()` is called, it sets `ZONEINFO_STRONG_CACHE
= NULL`, thus causing a
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +21023
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21907
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
I think that we should re-examine this issue after GH-20472 is merged. I'm not
really sure how that will affect this and indeed *how* it should affect this. I
am not sure whether people are relying on the current behavior, or what use
cases would be imp
Paul Ganssle added the comment:
I agree with Filipe here — I think the b32encode/b32decode tests were
originally written before subtests were available, and this PR has this and
other real improvements.
I understand why you'd want to have a policy of "no refactoring for its own
Paul Ganssle added the comment:
This is fixed in the 3.9 and master branches, it needs to be cherry-picked into
the 3.9.0 release (at Łukasz's discretion, of course).
Łukasz: If you cherry-pick GH-20965/GH-21876 into the 3.9.0 release, please
also cherry-pick GH-21907/GH-21912, since
Paul Ganssle added the comment:
Thanks Łukasz. Sorry I forgot to respond last time. We've had no feedback on
this whatsoever, and I think we've probably made the right choice, so we can go
ahead and call this resolved.
--
resolution: -> fixed
stage: patch review ->
Paul Ganssle added the comment:
New changeset 2e4dd336e5b50fd30947fdecb605ddcd71f7f6f5 by Zackery Spytz in
branch 'master':
bpo-30155: Add macros to get tzinfo from datetime instances (GH-21633)
https://github.com/python/cpython/commit/2e4dd336e5b50fd30947fdecb605dd
Paul Ganssle added the comment:
That's a reasonable enough objection, though what use case do you have for
storing the IsocalendarDate object? The main reason we switched to using a
named tuple like this was because the vast majority of uses of `isocalendar()`
that I saw were people
New submission from Paul Ganssle :
Following up on this year's language summit, I would like to propose that we
start integrating property tests into the standard library. Zac Hatfield-Dodds
(along with myself and Carl Friedrich Bolz-Tereick) have put together this
repository of tests
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +21805
pull_request: https://github.com/python/cpython/pull/22863
___
Python tracker
<https://bugs.python.org/issue42
Paul Ganssle added the comment:
Yeah, people are very confused by this, which is why I wrote that article.
Maybe there is a place for big warnings somewhere? I have been mulling over the
possibility of proposing a backwards-incompatible (though minimally so,
hopefully) change to arithmetic
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
Even if it were accidental (and it wasn't — it was actually somewhat difficult
to achieve), I'd still argue for not changing it in 3.9, because it would mean
that pickles created in 3.9.(n+1) would not be readable in 3.9.n.
Still, I don'
Paul Ganssle added the comment:
I'm glad that Terry brought up documentation, though, because I realized that
this is not a documented behavior:
https://docs.python.org/3/library/datetime.html#datetime.date.isocalendar
We should maybe document it? Though if we document it it mig
Paul Ganssle added the comment:
This is the expected behavior of `.fromisoformat()`. A similar issue is
https://bugs.python.org/issue35829, which asks for the "Z" suffix to be
supported.
There is a note about this in the documentation:
https://docs.python.org/3/library/dat
Paul Ganssle added the comment:
Is this an actual problem for another implementation of Python?
Is there some reason to think that we intended the repr of a `datetime` object
to be implementation-defined?
--
nosy: +p-ganssle
___
Python tracker
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue42094>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
This is probably more feasible than the proposal in bpo-41254 since it's a
well-defined spec (mostly — it includes an optional alternative format and the
number of digits allowed is defined "by agreement", thus defeating the purpose
of usin
101 - 200 of 482 matches
Mail list logo
