Change by Paul Ganssle :
--
pull_requests: +19849
pull_request: https://github.com/python/cpython/pull/20624
___
Python tracker
<https://bugs.python.org/issue40
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue40777>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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:
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
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" re
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
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
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:
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
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:
> 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 se
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 track
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
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
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:
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
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
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
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
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:
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
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:
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:
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
Change by Paul Ganssle :
--
pull_requests: -19344
___
Python tracker
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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:
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
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
Change by Paul Ganssle :
--
pull_requests: +19318
pull_request: https://github.com/python/cpython/pull/20006
___
Python tracker
<https://bugs.python.org/issue40
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 :
--
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 :
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 :
--
stage: -> needs patch
___
Python tracker
<https://bugs.python.org/issue40236>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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")
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
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
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
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
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/302e5a8f79514fd84bafbc44b7c97ec63630232
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
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
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
Change by Paul Ganssle :
--
nosy: -p-ganssle
___
Python tracker
<https://bugs.python.org/issue39763>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 m
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
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
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
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
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
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
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 s
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-bug
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
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
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 time
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.fromtimes
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
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 -> Incons
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
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 P
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
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
Change by Paul Ganssle :
--
pull_requests: +15935
pull_request: https://github.com/python/cpython/pull/16356
___
Python tracker
<https://bugs.python.org/issue35
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
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
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
<ht
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
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
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
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
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
Paul Ganssle added the comment:
Thanks Joannah!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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/issu
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
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
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
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
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/issu
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/issu
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> backport needed
status: open -> pending
___
Python tracker
<https://bugs.python.or
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/p
Change by Paul Ganssle :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.or
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
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 -&g
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 doc
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
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) | Δ
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
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
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
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
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
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
101 - 200 of 482 matches
Mail list logo
