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 th
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:
> 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:
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`
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. I
thi
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
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 "
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.or
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
Paul Ganssle added the comment:
New changeset 27b38b99b3a154fa5c25cd67fe01fb4fc04604b0 by Paul Ganssle in
branch '3.8':
bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15227)
https://github.com/python/cpython/commit/27b38b99b3a154fa5c25cd67fe01fb
Paul Ganssle added the comment:
New changeset ed44b84961eb0e5b97e4866c1455ac4093d27549 by Paul Ganssle in
branch '3.7':
bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15226)
https://github.com/python/cpython/commit/ed44b84961eb0e5b97e4866c1455ac
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
> I would support this addition. The timedelta class already has accessors for
> days and seconds, why not for hours and minutes?
The `timedelta.days` and `timedelta.seconds` accessors do not do what is being
requested here. The component accessors jus
Paul Ganssle added the comment:
This is a duplicate of #35829.
The reason that 'Z' is not supported is that `fromisoformat()` is not a general
ISO 8601 parser, but rather is intended to be the inverse of `isoformat()`. See
the documentation here:
https://docs.python.org/d
Paul Ganssle added the comment:
> Defining isoformat() and fromisoformat() as functional inverses is misguided.
> Indeed, it's not even true:
`isoformat()` is not the inverse of `fromisoformat()`, that doesn't work
because there are multiple strings that isoformat() can
New submission from Paul Ganssle :
Per Antoine's comment in the discourse thread (
https://discuss.python.org/t/parse-z-timezone-suffix-in-datetime/2220/6 ):
> ... the doc isn’t helpful, as it doesn’t give any alternative.
I think we can link to dateutil.parser.isoparse as an alt
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +15272
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/15596
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
This is only a semi-arbitrary restriction. Realistically, `datetime` is not a
particularly good way to represent times much older than the 17th or 18th
century (and if you're using time zones, it gets increasingly inaccurate as you
go further back from
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)
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
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
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:
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 us
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
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) | Δ
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
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
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: ope
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/3fb1363fe87a24cdb2ee1dd9746f1c
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 7117074410118086938044c7a4ef6846ec1662b2 by Paul Ganssle (Raymond
Hettinger) in branch 'master':
bpo-38096: Clean up the "struct sequence" / "named tuple" docs (GH-15895)
https://gi
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> backport needed
status: open -> pending
___
Python tracker
<https://bugs.python.or
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 :
--
pull_requests: +15596
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/15962
___
Python tracker
<https://bugs.python.org/issu
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/8ed6503eca4e3ea4949479d8d7fd9f
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 o
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/cpyt
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 requeste
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:
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
Paul Ganssle added the comment:
Thanks Joannah!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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:
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
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:
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/d6a9d17d8b6c68073931dd8ffa213b
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
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:
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/96b1c59c71534db3f0f3799cd84e20
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).
Than
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:
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
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/
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
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:
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 -> Inconsisten
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:
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.from
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's j
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 answe
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
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?) constru
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 sui
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/p
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 t
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
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 and not
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 a
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
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.py
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/VNGY2DLML4QJUXE73JLVBIH5WFBZN
Change by Paul Ganssle :
--
stage: resolved ->
___
Python tracker
<https://bugs.python.org/issue44603>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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
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:
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(&#x
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
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
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 impleme
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 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
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:
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
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:
> 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 answe
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 actuall
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 particula
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 backpo
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
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
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
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
Change by Paul Ganssle :
--
nosy: -p-ganssle
___
Python tracker
<https://bugs.python.org/issue39763>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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:
@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
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/302e5a8f79514fd84bafbc44b7c97
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 fo
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
-
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
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
1 - 100 of 482 matches
Mail list logo
