New submission from Paul Ganssle :
Currently, the `datetime` documentation has this to say about naïve datetimes:
> A naive object does not contain enough information to unambiguously locate
> itself relative to other date/time objects. Whether a naive object represents
> Co
New submission from Paul Ganssle :
In bpo-9305, Fred Drake recommends preferring `Returns ...` over the imperative
`Return ...`: https://bugs.python.org/issue9305#msg110912
Currently we're pretty consistent about `Return ...`, which is consistent with
PEP 257: https://peps.python.org/pep
Paul Ganssle added the comment:
I think this approach is probably the best we can do, but I could also imagine
that users might find it to be confusing behavior. I wonder if there's any
informal user testing we can do?
I guess the ISO 8601 spec does call "Z" the "UTC
Paul Ganssle added the comment:
I don't think it's necessary to add a feature to `isoformat()` just for the
purpose of being able to add the corresponding parser, particularly when the
plan is to implement a much broader ISO 8601 parser for Python 3.11 (I've done
most of the implementation
New submission from Paul Ganssle :
As part of bpo-35829, it was suggested that we add the ability to output the
"Z" suffix in `isoformat()`, so that `fromisoformat()` can both be the exact
functional inverse of `isoformat()` and parse datetimes with "Z" outputs.
Paul Ganssle added the comment:
Sorry I missed this! Thank you for taking the time to write this up and to make
a PR.
Unfortunately, I don't think I agree with the idea of warning about this. The
warnings about `utcnow` and `utcfromtimestamp` are a problem because `utcnow
Paul Ganssle added the comment:
> from practical experience, it is a whole lot better to not deal with
> timezones in data processing code at all, but instead only use naive UTC
> datetime values everywhere, expect when you have to prepare reports or output
> which has a require
Paul Ganssle added the comment:
Yes, this is the documented behavior, including a warning against using UTC now
in the documentation!
There is some possibility of removing utcnow entirely as an "attractive
nuisance", but I suspect that this will lead to much consternation and
han
Paul Ganssle added the comment:
Jason's patch looks good to me, but I don't understand why Karthikeyan
originally suggested using `normalize_path`. Trying to dig through exactly how
`files().joinpath().open` is implemented has so many layers of indirection and
abstract classes that I can't
Paul Ganssle added the comment:
Updating this issue to cover the problem in date, time and datetime.
--
title: datetime: strftime method takes different keyword argument: fmt (pure)
or format (C) -> datetime, date and time: strftime method takes different
keyword argument: fmt (p
Paul Ganssle added the comment:
I think this is mostly a duplicate of bpo-41260, which has an open PR on it. I
think that got lost in the shuffle, I'm sad we didn't fix it in Python 3.10. I
think we should migrate all of these signatures that differ to whichever one
the C implementation
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +27309
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29038
___
Python tracker
<https://bugs.python.org/issu
New submission from Paul Ganssle :
Right now the datetime documentation recommends using `dateutil.tz` for IANA
time zones, but we should update this to point to `zoneinfo`.
--
assignee: p-ganssle
components: Documentation
messages: 404207
nosy: p-ganssle
priority: low
severity
Paul Ganssle added the comment:
This is a great bug report, but for anyone else who gets a bit lost in the
details, here's the core of the issue:
>>> p = Path("/1/2")
>>> q = Path("1/2")
>>> p.parents[-1] # This is correct
PosixPath('/')
>
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue45414>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I think this is a rounding issue. `time.time()` returns an epoch timestamp as a
float and at the current epoch time, floats are spaced ~500ns apart.
`datetime.datetime.now` does a floor division when rounding:
https://github.com/python/cpython/blob
Paul Ganssle added the comment:
Sorry you didn't receive a response to your security@ email, I guess my
response just went to the PSRT, not to you as well. I believe we determined
that this was an issue in importlib.resources generally, not specific to
zoneinfo.
I think
Change by Paul Ganssle :
--
stage: resolved ->
___
Python tracker
<https://bugs.python.org/issue44603>
___
___
Python-bugs-list mailing list
Unsubscrib
Paul Ganssle added the comment:
Re-opening this because I think the discussion is not done and I don't see any
reason why this was rejected.
> Related 2005 python-dev discussion:
> https://mail.python.org/archives/list/python-...@python.org/thread/VNGY2DLML4QJUXE73JLVBIH5WFBZNIKG/
Paul Ganssle added the comment:
At this point I think we should probably start a thread on python-dev to see
how people feel about it. I'd be happy to author or co-author a PEP for this if
need be.
--
___
Python tracker
<https://bugs.python.
Paul Ganssle added the comment:
> In fact, you're proposing to use exit as a keyword, but lying about it to the
> users. If it were really so important, then it _should_ be a keyword, and at
> least I'd know that I can't use it for my variables anymore. (It's not the
>
Paul Ganssle added the comment:
I'm +1 for Pablo's approach. That's approximately what I meant by "special-case
it in the REPL layer" anyway.
Are there any downsides to doing it this way? It seems tightly scoped and with
minima
Paul Ganssle added the comment:
If we want to confine the behavior to just the repl, we could possibly have the
repl set an environment variable or something of that nature for interactive
sessions, so that `__repr__` of `exit` can tell the difference between being
invoked in a REPL
Paul Ganssle added the comment:
Yeah, I knew this was slower and it's been on my long list to look at it (tied
to this is the fact that `datetime.today()` is basically just a slow version of
`datetime.now()`, in defiance of user expectations).
My inclination is that we shouldn't re
Paul Ganssle added the comment:
> I use hypothesis during development, but don't have a need for in the the
> standard library. By the time code lands there, we normally have a specific
> idea of what edge cases needs to be in the tests.
The suggestion I've made here is that we use
Paul Ganssle added the comment:
New changeset c87b81dcb2c22b6d151da39a0f65d5db304f59a8 by Miss Islington (bot)
in branch '3.9':
bpo-43295: Fix error handling of datetime.strptime format string '%z'
(GH-24627) (#25695)
https://github.com/python/cpython/commit
Paul Ganssle added the comment:
I do not want to dissuade you from figuring out how minithesis / hypothesis
works (far from it), but I'm wondering if the question of how shrinking works
is germane to the issue at hand, which is whether or not hypothesis /
property-based-testing is suitable
Paul Ganssle added the comment:
I also commented on GH-26215 ( https://github.com/python/cpython/pull/26215 ),
but for posterity, I'll note a few things:
1. It seems that (and this may have changed since 2015), `_strptime._strptime`
now has a stage that (unconditionally?) constructs
Paul Ganssle added the comment:
@Terry
> The problem with random input tests in not that they are 'flakey', but that
> they are useless unless someone is going to pay attention to failures and try
> to find the cause. This touches on the difference between regression testing
Paul Ganssle added the comment:
> I don't think full nanosecond support is feasible to complete in the
> remaining weeks
This may be so, but I think the important part of that question is "what work
needs to be done and what questions need to be answered?" If the answer
Paul Ganssle added the comment:
> That it allows creating the datetime instance looks like a bug to me, i.e. a
> time before 0001-01-01 00:00 UTC is invalid. What am I misunderstanding?
`datetime.datetime(1, 1, 1, tzinfo=timezone(timedelta(hours=1)))` is a valid
datetime, it'
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue43382>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 they have
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://github.com/python
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 of `-q
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:
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
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:
> 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
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:
> 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's a si
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&q
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
Paul Ganssle added the comment:
New changeset 79d2e62c008446fbbc6f264bb8a30e2d38b6ff58 by Yaroslav Pankovych in
branch 'master':
Added support for negative indexes to PurePath.parents (GH-21799)
https://github.com/python/cpython/commit/79d2e62c008446fbbc6f264bb8a30e2d38b6ff58
Paul Ganssle added the comment:
New changeset 79d2e62c008446fbbc6f264bb8a30e2d38b6ff58 by Yaroslav Pankovych in
branch 'master':
Added support for negative indexes to PurePath.parents (GH-21799)
https://github.com/python/cpython/commit/79d2e62c008446fbbc6f264bb8a30e2d38b6ff58
New submission from Paul Ganssle :
Currently, it seems that the pathlib module uses `.. data::` to annotate the
properties of the PurePath type (e.g. .parts, .drive, .root, etc). See:
https://github.com/python/cpython/blob/ff420f0e08a2443339da0df7ace95e14177bac53/Doc/library/pathlib.rst
Paul Ganssle added the comment:
I think you may have confused my thoughts as to why this might be considered
ambiguous with an actual suggestion for what the semantics should be.
I think that we should stick with `p.parents[x] == tuple(p.parents)[x]` for any
valid value of `x`, which means
Change by Paul Ganssle :
--
dependencies: -pathlib.PurePath.parents rejects negative indexes
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
New changeset 452058448335b39c784af9a047f9c4a1767c0b00 by Joshua Cannon in
branch 'master':
bpo-35498: Added slice support to PathLib parents attribute. (GH-11165)
https://github.com/python/cpython/commit/452058448335b39c784af9a047f9c4a1767c0b00
Paul Ganssle added the comment:
One question I would have about this is that `.parents` is a lazily-calculated
sequence, not a list or a tuple, so it's not immediately obvious what the
return type of a slice would be. I don't think it makes sense to return, e.g. a
`_PathParents` object
Paul Ganssle added the comment:
I am not seeing any compelling reasons to avoid supporting negative indexes
*or* slices here.
If I had to guess about the confusing semantics of negative indices, I would
guess it's the fact that the index in the -1 position for a non-empty Path will
always
Paul Ganssle added the comment:
What is an example of another Python implementation that has this property? Is
there a concrete issue open somewhere that this is solving?
I am not unsympathetic to the idea of accommodating other implementations of
Python, but this is very abstract and I
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 us
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:
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
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:
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 might
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't think I'd
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:
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 :
--
keywords: +patch
pull_requests: +21805
pull_request: https://github.com/python/cpython/pull/22863
___
Python tracker
<https://bugs.python.org/issue42
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
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 doing
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/2e4dd336e5b50fd30947fdecb605ddcd71f7f6f5
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 -> resolved
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:
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:
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 improved
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:
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
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
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:
Ł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
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/33d3c64095bcdf9066a3441f6dda5d2e2f4118a8
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/87d8287865e5c9f137f6b5cf8c34c2c509eb5e9d
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:
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 constructor should
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:
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:
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 around 50
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 format for time
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:
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're
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 asking people t
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 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 than `fmt
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:
> 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:
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 in, so
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/6c56356109616ea1292aafa48d30536279ec0937
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/bc43f6e21244f31d25896875430174cd4ac7604c
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
Change by Paul Ganssle :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue41059>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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 :
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 Apr 2 22:
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
>&
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 res
1 - 100 of 482 matches
Mail list logo
