[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments

2020-11-23 Thread Paul Ganssle


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


--

___
Python tracker 
<https://bugs.python.org/issue35498>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21041] pathlib.PurePath.parents rejects negative indexes

2020-11-23 Thread Paul Ganssle


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


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue21041>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42444] pathlib.PurePath properties annotated with .. data directive

2020-11-23 Thread Paul Ganssle

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

According to the documentation 
(https://devguide.python.org/documenting/#information-units), `data` is for 
module-level constants, specifically:

> Describes global data in a module, including both variables and values used
> as “defined constants.” Class and object attributes are not documented using
> this directive.

I believe that we should switch these over to use the `.. attribute:` directive 
instead.

>From what I can tell, you can still link to these attributes using the 
>`:attr:` role. I haven't checked if you can link to `:attribute:`s using the 
>`:data:` role, though. If not, it might break some links to change these to 
>`:attribute:`.

--
assignee: docs@python
components: Documentation
messages: 381673
nosy: docs@python, eric.araujo, ezio.melotti, mdk, p-ganssle, willingc
priority: low
severity: normal
status: open
title: pathlib.PurePath properties annotated with .. data directive
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42444>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21041] pathlib.PurePath.parents rejects negative indexes

2020-11-23 Thread Paul Ganssle


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 that `p.parents[-1]` will always be `Path('.')` 
for any non-empty `p`.

--

___
Python tracker 
<https://bugs.python.org/issue21041>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments

2020-11-20 Thread Paul Ganssle


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.org/issue35498>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments

2020-11-20 Thread Paul Ganssle


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


--

___
Python tracker 
<https://bugs.python.org/issue35498>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments

2020-11-19 Thread Paul Ganssle


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 with fewer parts, but I don't know if there's any 
traditional choice here, other than that the result of slicing Sequence is 
another Sequence.

The PR returns a list, but I'm inclined to say we should return a tuple.

--
nosy: +p-ganssle
versions: +Python 3.10 -Python 3.8

___
Python tracker 
<https://bugs.python.org/issue35498>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21041] pathlib.PurePath.parents rejects negative indexes

2020-11-19 Thread Paul Ganssle

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 be `Path('.')`. Since that's not terribly useful, it might be reasonable 
to have negative indices start counting at `len(p)-2`.

That said, I don't think this is a big deal, and I think we have more 
speculation on why this was avoided in the first place than we have actual 
objections to changing it, so I vote for changing it.

I think our best option is to say that the semantics of indexing `.parents` 
should be the same as indexing the result of casting it to a tuple, so this 
should be true:

p = Path(x)
assert p.parents[y] == tuple(p.parents)[y]

For all values of `x` and `y`.

I've gone ahead and changed the version support matrix to 3.10 only, since I 
think that this was a deliberate choice and we should be considering this an 
enhancement rather than a bugfix. That said, I'll admit that it's on the 
borderline — the semantics of sequences are unambiguous (see, which says that 
sequences support both slices and negative indices: 
https://docs.python.org/3/library/stdtypes.html#typesseq ), and PEP 428 
explicitly says that .parents returns a "an immutable sequence of the path's 
logical ancestors": 
https://www.python.org/dev/peps/pep-0428/#sequence-like-access . So if someone 
is motivated to try and make the case that this is a bugfix that could be 
backported to earlier supported versions, I won't stand in their way.

--
nosy: +p-ganssle
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue21041>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42390] Other Python implementations may not expose the module name in datetime type names

2020-11-17 Thread Paul Ganssle


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 think the assumption is probably that 
if we're explicitly testing for something and we don't say it's 
implementation-defined that it is part of the language spec.

If there's some evidence that stuff like this is intended to be 
implementation-defined always, or there's some concrete problem that we can 
solve (and possibly also add tests to avoid regressions), I'd be much more 
comfortable with something like this.

--

___
Python tracker 
<https://bugs.python.org/issue42390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42094] isoformat() / fromisoformat() for datetime.timedelta

2020-11-17 Thread Paul Ganssle

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 using a spec in the first place) that's not even particularly difficult to 
implement, but there are still a few problems (and one reason I've never 
implemented this, despite desperately wanting a better string representation 
for time deltas). Two minor problems first:

1. Unlike ISO 8601 datetimes, these are not especially "human-friendly" 
formats, so I don't think they're especially useful for displaying timedeltas.

2. Also unlike ISO 8601 datetimes, I don't think these are in particularly wide 
use, or widely supported. That's not a major strike against it, but if it's not 
useful as something to show to humans and it's not especially useful as 
something to show to / read from other computers, that weighs against its 
inclusion in the standard library.

The biggest problem, however, is that `timedelta` does not and cannot represent 
"Year" or "Month", which means that `P1Y` or `P1M` would always need to be 
invalid to parse. We could eliminate this format, but it means that we would 
never at any point in the future be able to implement a parser for the full 
spec. Since the concept of a year and a month are ambiguous and at least the 
2016 version of ISO 8601 doesn't seem to define what it means for a duration to 
last 1 year or 1 month, you can't even really count on such a thing as an 
interchange format, because different implementations might give you different 
results! What does `20200131T00:00:00/P1M` represent? The interval (2020-01-31, 
2020-02-29)? (2020-01-31, 2020-03-02)? Something else?

A better target for parsing ISO 8601 durations would be something like 
`dateutil.relativedelta`, which does have defined semantics for years and 
months (though as I mentioned above, those are not necessarily consistent with 
the semantics of other libraries parsing or writing out this format).

I am also not entirely clear on whether "weeks" is just an alias for "7 days" 
or if it means something related to weeks in the ISO calendar (and if that 
makes a difference for durations).

I imagine that generating these formats is a bit more forgiving, because you 
would simply never generate the forbidden formats, and we can offer 
configuration options in the formatter method to allow the user to tweak the 
various ambiguities in the spec.

--

___
Python tracker 
<https://bugs.python.org/issue42094>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42094] isoformat() / fromisoformat() for datetime.timedelta

2020-11-17 Thread Paul Ganssle


Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 
<https://bugs.python.org/issue42094>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42390] Other Python implementations may not expose the module name in datetime type names

2020-11-17 Thread Paul Ganssle


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 
<https://bugs.python.org/issue42390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42371] datetime.fromisoformat(): Omitted colon in timezone suffix raises ValueError

2020-11-16 Thread Paul Ganssle


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/datetime.html#datetime.datetime.fromisoformat

"Caution This does not support parsing arbitrary ISO 8601 strings - it is only 
intended as the inverse operation of datetime.isoformat(). A more full-featured 
ISO 8601 parser, dateutil.parser.isoparse is available in the third-party 
package dateutil."

At some point we will work out the kinks in offering as full an ISO 8601 
datetime parser as possible, but the ISO 8601 datetime spec is very complicated 
and includes many optional features. We deliberately chose to keep the scope of 
`.fromisoformat()` minimal at first, whereas `dateutil.parser.isoparse` 
attempts to be a full-featured ISO8601 parser.

Changing the version affected to 3.10, since this is a feature request.

--
type: behavior -> enhancement
versions: +Python 3.10 -Python 3.8

___
Python tracker 
<https://bugs.python.org/issue42371>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42070] Revisit IsoCalendarDate being private from pickle perspective

2020-10-23 Thread Paul Ganssle


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 be considered 
more of a breaking change to change the behavior than if it's an undocumented 
feature.

--

___
Python tracker 
<https://bugs.python.org/issue42070>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42070] Revisit IsoCalendarDate being private from pickle perspective

2020-10-23 Thread Paul Ganssle

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 be convinced without some real-life use cases. The SO 
question is asking about the reasoning for this in the abstract — the poster 
noticed that we designed it this way and saw a possible objection to this, but 
it was one that we had considered and decided to make the trade-off a different 
way.

I informally asked many people about this, since it was by far the weirdest 
design decision made in that issue (I say that in the passive tense not to 
deflect from the fact that I made the decision, but to own the fact that it was 
weirder than any of the design decisions made by anyone else, either ), and 
generally they could not give me any concrete reasons it would break (but they 
also all counseled not to try to get too clever with pickling logic).

I think I'm happy with the decision if we remain in the realm of the abstract, 
but I recognize how weird it is, and I think if someone came up with a 
compelling workflow that this breaks, we could change it (in a feature 
release). This was specifically proposed to avoid backwards-compatibility 
problems, so it wouldn't be any more of a breakage to change it in future 
feature releases than it would have been to do it in 3.9.

--

___
Python tracker 
<https://bugs.python.org/issue42070>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41056] minor NULL pointer and sign issues reported by Coverity

2020-10-21 Thread Paul Ganssle


Change by Paul Ganssle :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41056>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30155] Add ability to get tzinfo from a datetime instance in C API

2020-10-21 Thread Paul Ganssle


Change by Paul Ganssle :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue30155>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42025] zoneinfo: wrong time difference across transition when tzinfo is equal

2020-10-21 Thread Paul Ganssle

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 semantics that would work well with how people 
think this should work, but I think any such backwards-incompatible change 
would be a Big Deal™, and unfortunately quite hard to warn about with a proper 
deprecation period.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 
<https://bugs.python.org/issue42025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42109] Use hypothesis for testing the standard library, falling back to stubs

2020-10-21 Thread Paul Ganssle


Change by Paul Ganssle :


--
keywords: +patch
pull_requests: +21805
pull_request: https://github.com/python/cpython/pull/22863

___
Python tracker 
<https://bugs.python.org/issue42109>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42109] Use hypothesis for testing the standard library, falling back to stubs

2020-10-21 Thread Paul Ganssle


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 that we run against the standard library as is: 
https://github.com/Zac-HD/stdlib-property-tests

Here is the blog post covering the proposal from the language summit: 
https://pyfound.blogspot.com/2020/05/property-based-testing-for-python.html

The biggest challenges here are logistical:

1. Pulling in third party dependencies is difficult to do reliably on CI, but 
checking in hypothesis's entire dependency tree is probably not feasible.
2. We don't necessarily want to require developers running their tests locally 
to have to set up a hypothesis environment just to run the tests.
3. Hypothesis tests are not (by default) deterministic, which some are 
concerned may lead to flakiness by themselves.


To allay these concerns, I propose that we implement a compatibility interface 
for hypothesis that uses the third party module when it's installed, but 
otherwise falls back to stubs. The way I see the stubs working is that `@given` 
*without* `@example`s would simply skip the test. If you specify `@given` and 
one or more `@example`s, the test falls back to a simple parameterized test 
when hypothesis is not available.

At least at first, we won't attempt to add a mandatory PR job that runs with 
hypothesis installed. Instead, I'd like to run either an optional job on PR or 
have one or more buildbots that runs the hypothesis tests.

I would also like to suggest a policy of including at least one example in each 
property test, so that on PR at least some of the inputs are tested.

--
assignee: p-ganssle
components: Tests
messages: 379226
nosy: Zac Hatfield-Dodds, p-ganssle, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Use hypothesis for testing the standard library, falling back to stubs
type: enhancement
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42109>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42070] I think the rationale to keep IsoCalendarDate private from the pickle perspective should get revisited

2020-10-18 Thread Paul Ganssle


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 stuff like `dt.isocalendar()[0]`, rather than 
destructuring the tuple or accessing more than one element from the result.

It seems to me that if you are using a pickle for a cache, you'd either pickle 
the `datetime` itself (and call `.isocalendar()` in the process that has read 
from the cache already), or you'd store one or more of the fields directly on 
the object that you are caching.

A real life use case for this would help.

--

___
Python tracker 
<https://bugs.python.org/issue42070>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue30155] Add ability to get tzinfo from a datetime instance in C API

2020-09-23 Thread Paul Ganssle


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


--

___
Python tracker 
<https://bugs.python.org/issue30155>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-09-14 Thread Paul Ganssle

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
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41025] C implementation of ZoneInfo cannot be subclassed

2020-09-11 Thread Paul Ganssle

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 that fixes the refleak. (PRs are 
listed as "master"/"backport" since I don't know your workflow).

--

___
Python tracker 
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41734] Refactor b32{encode,decode} tests

2020-09-08 Thread Paul Ganssle

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 
sake", but as I argued in the PR 20441 
(https://github.com/python/cpython/pull/20441#issuecomment-634773049), it's 
safer to leave existing tests alone when making changes to the code under test, 
since there's the possibility that you both introduce an error *and* modify the 
tests in such a way that doesn't catch the error you introduced. In that case, 
"refactoring as you go" doesn't really work, and you need a separate PR for 
improvements like these.

I'm re-opening the ticket for now because I think we should at least discuss 
this before rejecting it out of hand.


> I am a bit confused, in PR 20441 I first just copied the current 
> b32{encode,decode} tests but was given feedback which resulted in the 
> proposed tests, but now I am being told the opposite, that the tests are 
> better as they currently are.

Sorry about the mixed messages. I think you simply chalk this up to the fact 
that Serhiy and I apparently disagree about test structure. I reviewed the 
previous PR and specifically asked for this change, so I think it was a bit 
rash to close the issue right away (though as someone who has probably 
prematurely closed his fair share of issues, I should probably not be tossing 
about stones in the vicinity of my decidedly double-paned domicile).

--
resolution: rejected -> 
stage: resolved -> patch review
status: closed -> open
versions: +Python 3.10

___
Python tracker 
<https://bugs.python.org/issue41734>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32313] Wrong inspect.getsource for datetime

2020-08-27 Thread Paul Ganssle

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 if we had a different behavior.

With regards to this:

> The documentation for getfile says "This will fail with a TypeError if the 
> object is a built-in module, class, or function."

> https://docs.python.org/3/library/inspect.html#inspect.getfile

This is a bit unclear to me, and I'm not entirely sure if `datetime` qualifies. 
I think of built-in classes as things like `int` and `float`, and built-in 
functions as things like `abs` and `sum`, and `datetime` is an extension module 
— albeit one with a C implementation, and one that is in the standard library.

We should probably clarify the wording of `inspect.getsource` and determine 
what the intended semantics are for PEP-399-style modules, with both a C and 
pure Python implementation and the C implementation is what's being used. 
Error? Point to the Python implementation?

--

___
Python tracker 
<https://bugs.python.org/issue32313>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41568] test_zoneinfo leaked [84, 84, 84] references

2020-08-17 Thread Paul Ganssle


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/issue41568>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41025] C implementation of ZoneInfo cannot be subclassed

2020-08-17 Thread Paul Ganssle


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 reference leak to the parent class's strong cache.

I'll send a PR to fix it shortly.

--

___
Python tracker 
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41025] C implementation of ZoneInfo cannot be subclassed

2020-08-14 Thread Paul Ganssle


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 
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41025] C implementation of ZoneInfo cannot be subclassed

2020-08-14 Thread Paul Ganssle


Change by Paul Ganssle :


--
stage: patch review -> backport needed

___
Python tracker 
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41025] C implementation of ZoneInfo cannot be subclassed

2020-08-14 Thread Paul Ganssle

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.

It was merged as commit 33d3c64095bcdf9066a3441f6dda5d2e2f4118a8.

Thanks!

--
nosy: +lukasz.langa

___
Python tracker 
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41025] C implementation of ZoneInfo cannot be subclassed

2020-08-14 Thread Paul Ganssle


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


--

___
Python tracker 
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41025] C implementation of ZoneInfo cannot be subclassed

2020-08-13 Thread Paul Ganssle


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


--

___
Python tracker 
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41530] zoneinfo: ZoneInfo raises IsADirectoryError instead of ZoneInfoNotFoundError

2020-08-12 Thread Paul Ganssle


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 
<https://bugs.python.org/issue41530>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41530] zoneinfo: ZoneInfo raises IsADirectoryError instead of ZoneInfoNotFoundError

2020-08-12 Thread Paul Ganssle


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 probably ignore those, since 
they are added by `tzdata` and not actually part of a tzdata distribution.

--

___
Python tracker 
<https://bugs.python.org/issue41530>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36700] base64 has old references that should be updated

2020-08-10 Thread Paul Ganssle


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/issue36700>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached)

2020-08-10 Thread Paul Ganssle


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.org/issue16995>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41371] test_zoneinfo fails when lzma module is unavailable

2020-08-04 Thread Paul Ganssle


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% compression 
using either lzma or gzip, but the uncompressed file is only 32k to start with:

$ du -b tests/data/*
31054   tests/data/zoneinfo_data.json
15127   tests/data/zoneinfo_data.json.gz
12895   tests/data/zoneinfo_data.json.lz

We're also currently using the "fat" binaries that `zic` produces (which 
includes hard-coded transitions all the way until 2038). The new default for 
`zic` is to produce "slim" binaries, and the script to update test data does 
nothing to explicitly request fat binaries. If we were to switch over to "slim" 
binaries, the result would be more like this:

$ du -b tests/data/*
8297tests/data/zoneinfo_data_slim.json.gz
7750tests/data/zoneinfo_data_slim.json.lz
15551   tests/data/zoneinfo_data_unc_slim.json

So we're still looking at ~2:1 compression for both gzip and lzma, but the 
overall file size is 50% of what it was to start with. The biggest downside to 
this is that the way the "slim" binaries work is that once a rule repeats 
indefinitely, `zic` stops producing explicit transitions for it, and falls back 
to a simple repeating rule, meaning that the current set of tests would take a 
different code path.

I think we can go with the following course of action (3 or 4 different PRs):

1. Start by skipping the tests when `lzma` is missing.
2. Update the test suite so that it is testing more or less the same thing when 
the binaries are compiled with `-b slim`.
3. Change `Lib/test/test_zoneinfo/data/update_test_data.py` so that it pulls 
the raw data from the `tzdata` module on PyPI (which is compiled with `-b 
slim`) instead of the user's machine.
4. Change `update_test_data.py` to stop using `lzma` and change the tests so 
that they are able to process the new format of the JSON files.

If we ever decide that we really want the compression again, I assume that 
`gzip` is found more commonly than `lzma` among systems that don't build the 
whole standard library, so it might be mildly preferable to switch to `gzip`.

--

___
Python tracker 
<https://bugs.python.org/issue41371>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41254] Add to/from string methods to datetime.timedelta

2020-07-20 Thread Paul Ganssle


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 differences is more complicated than it might seem. I 
have had an open issue on dateutil to implement this for ages, but I haven't 
seen or come up with any proposals for a DSL for specifying timedelta formats: 
https://github.com/dateutil/dateutil/issues/444

It is annoyingly complicated to do this, and I'd rather it be tried out in 
other libraries with more flexibility to make breaking changes and a shorter 
release cadence. Dateutil is a good choice, but a clear and thorough proposal 
(or at least examples of this done well in other ecosystems we can crib from) 
is necessary.

--

___
Python tracker 
<https://bugs.python.org/issue41254>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41321] Calculate timestamp is wrong in datetime.datetime

2020-07-20 Thread Paul Ganssle

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 timezone-aware. In 
Python 3, naïve datetimes went from being "unitless datetimes" to representing 
"local datetimes", and in certain situations (like calling `.timestamp()`), 
your system's time zone is used.

If you want something that gives the number of seconds that has elapsed between 
two naïve datetimes on the calendar and ignoring any daylight saving time 
transitions, subtract them directly to get a timedelta, then divide the result 
by a timedelta representing 1 second, like so:

>>> (datetime.datetime(1986, 5, 4, 7, 13, 22) - datetime.datetime(1986, 5, 
4, 0, 0, 0)) / datetime.timedelta(seconds=1)
26002.0


>>> (datetime.datetime(1986, 5, 2, 7, 13, 22) - datetime.datetime(1986, 5, 
2, 0, 0, 0)) / datetime.timedelta(seconds=1)
26002.0

--
resolution:  -> not a bug
stage:  -> resolved
type:  -> behavior

___
Python tracker 
<https://bugs.python.org/issue41321>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41282] Deprecate and remove distutils

2020-07-14 Thread Paul Ganssle


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 working on a version where `import 
distutils` comes from `setuptools` regardless of the import order).

--

___
Python tracker 
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41282] Deprecate and remove distutils

2020-07-14 Thread Paul Ganssle

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 to migrate to 
`setuptools._distutils` (a private module which may not continue to exist in 
that location), `setuptools` is *adopting* `distutils`, such that `distutils` 
is a project provided by `pip install distutils` (mind you, this is happening 
independent of what the standard library does — the only question is whether 
`import distutils` continues to work if you don't have `setuptools` installed).

> While splitting out distutils to a separate package in a Linux distro, I 
> found some creative usages at runtime of a package (see my lightning talk at 
> the language summit 2018, and [1]).  From my point of view, CPython should 
> provide documentation how to forward-port these issues without using 
> setuptools._distutils.

At this point, the extent of CPython's documentation on this should probably 
be, "We are removing `distutils` and moving it into the `setuptools` namespace. 
In future versions, you will need to install `setuptools` to import the 
`distutils` package." `setuptools` should almost certainly deprecate 
`distutils` and probably remove large swathes of it in the process, but that's 
probably on a case-by-case basis, and it's a separate issue from what needs to 
happen in CPython.

> Currently setuptools only has one component (pkg_resources, [2]) which is 
> used at runtime.  I dislike it if more than that is used at runtime of a 
> package.

I don't think anyone is planning to recommend the use of *any* 
`setuptools`-provided packages at runtime, including `pkg_resources`. This move 
is actually a good one from that point of view, because it will require that 
projects using `distutils` declare a *runtime* dependency on `setuptools`, 
which will, hopefully, raise some eyebrows. Better than the current situation, 
where these dependencies are totally undeclared (though probably worse than if 
`setuptools`, `pkg_resources` and `distutils` were all separate PyPI packages).

--

___
Python tracker 
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41282] Deprecate and remove distutils

2020-07-13 Thread Paul Ganssle


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 whole cpython development process.

My understanding was that the plan was to move the standard library distutils 
into a private module somewhere in the standard library and presumably to slim 
it down to only the bare minimum required for what is necessary to build Python 
itself. We're really only concerned with the use of distutils to build packages.

> For example, there are many open Distutils issues in the bugs.python.org bug 
> tracker. We need a plan on how those are to be handled (and that should take 
> into account the expected transition from b.p.o to GitHub issues).  People 
> will continue to submit issues agains Distutils there so triage team members 
> and core developers need to know how to handle such issues. What if an issue 
> applies also or only to a previous release branch (i.e. where Distutils is 
> still in the repo)?

As far as I can tell we've already been telling people that issues in distutils 
should be fixed in setuptools instead for a few years. I don't think anything 
needs to be done about the currently open distutils tickets before we 
*deprecate* distutils, though during the deprecation period we'll probably want 
to decide whether we want to migrate them, do a mass closure or just leave them 
to be ad hoc closed as people stumble upon them later. Mass closure may be 
complicated because tickets affecting CPython itself will still need to be 
addressed.

> What about Distutils documentation in the Python docset?  THose are just some 
> off the top of my head.

The distutils documentation is already basically just a warning page that says 
"stop using distutils": 
https://docs.python.org/3/library/distutils.html#module-distutils

Before these reference materials are removed from the docs we'll need to make 
sure that all the stuff that's still supported is documented on the setuptools 
side.

> I don't think any of these issues are necessarily blockers but they need to 
> be planned for and reviewed.  I think a PEP is definitely in order for a 
> change of this magnitude.

A PEP may be a good idea, but I do think the change doesn't have a particularly 
large magnitude. Anyone using setuptools or pip has already been getting 
setuptools' monkey-patched version of distutils for ages now, and soon they 
will be getting setuptools' vendored version. The documentation already 
indicates that distutils is at least soft-deprecated in favor of setuptools and 
we've already been directing issues and PRs to setuptools instead of distutils. 
This last piece is really formalizing something we've been incrementally 
working towards for a long time now. Doesn't mean we shouldn't do it carefully 
and with a lot of notice, but it's also not a sudden and massive shift.

--
nosy: +p-ganssle

___
Python tracker 
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41260] datetime: strftime method takes different keyword argument: fmt (pure) or format (C)

2020-07-09 Thread Paul Ganssle


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=`, since it's pretty rare for anyone to use the pure python 
version of datetime. PyPy uses it, but I think they tend to aim for consistency 
with the C API of CPython, and it seems like they already patch s/fmt/format/ 
themselves: 
https://foss.heptapod.net/pypy/pypy/-/blob/branch/default/lib_pypy/datetime.py#L781

If anyone wants to make a PR I think we can fix this for 3.10, though 
unfortunately because it is an API change it can't be backported. I think in 
typeshed they can safely change from `fmt` to `format` even today (which would 
almost certainly be more accurate to end user use cases).

--
nosy:  -rkm
stage:  -> needs patch

___
Python tracker 
<https://bugs.python.org/issue41260>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40799] Create Lib/_pydatetime.py file to optimize "import datetime" when _datetime is available

2020-06-26 Thread Paul Ganssle


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 code bases out there that pile weird stuff on 
top of it. I'm not sure I can fully appreciate the trade-offs.

The biggest advantage I see to moving `datetime` into its own folder is that it 
gives us a lot more freedom to expand into smaller sub-modules in the future. 
For example, in `zoneinfo`, we have zoneinfo/_common.py 
(https://github.com/python/cpython/blob/2e0a920e9eb540654c0bb2298143b00637dc5961/Lib/zoneinfo/_common.py),
 which is some logic shared between the C and Python implementations; 
`_zoneinfo.c` is able to rely directly on `_common.py` without importing 
`zoneinfo/_zoneinfo.py` (which saves us a bunch of other module imports as 
well).

Right now the C implementation of `datetime` only directly imports `time` and 
`_strptime`, but I could imagine future enhancements that would be stupidly 
inconvenient to implement in C, but where we wouldn't want to implement all of 
_pydatetime just to get a pure-Python implementation. Having a namespace 
available for such packages would be useful.

--

___
Python tracker 
<https://bugs.python.org/issue40799>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40799] Create Lib/_pydatetime.py file to optimize "import datetime" when _datetime is available

2020-06-26 Thread Paul Ganssle

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". If 
it's used for `time` as well, we should leave it where it is.

--

___
Python tracker 
<https://bugs.python.org/issue40799>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41118] datetime object does not preserve POSIX timestamp

2020-06-25 Thread Paul Ganssle


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 that it can 
be translated back into the absolute number of seconds since UTC. The correct 
way to do that is to tell the datetime it's in UTC by attaching the 
`datetime.timezone.utc` object (or any equivalent `tzinfo`).

I have written a blog post explaining in detail why you should not use `utcnow` 
or `utcfromtimestamp`: https://blog.ganssle.io/articles/2019/11/utcnow.html

Hopefully that is helpful to you.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41118>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41056] minor NULL pointer and sign issues reported by Coverity

2020-06-24 Thread Paul Ganssle


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


--

___
Python tracker 
<https://bugs.python.org/issue41056>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41065] Use zip-strict in zoneinfo

2020-06-23 Thread Paul Ganssle


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


--

___
Python tracker 
<https://bugs.python.org/issue41065>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41056] minor NULL pointer and sign issues reported by Coverity

2020-06-23 Thread Paul Ganssle


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/issue41056>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41059] Large number of Coverity reports for parser.c

2020-06-20 Thread Paul Ganssle


Change by Paul Ganssle :


--
nosy: +pablogsal

___
Python tracker 
<https://bugs.python.org/issue41059>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41025] C implementation of ZoneInfo cannot be subclassed

2020-06-18 Thread Paul Ganssle


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/issue41025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41025] C implementation of ZoneInfo cannot be subclassed

2020-06-18 Thread Paul Ganssle

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 subclass, due to a mistake in the inheritance tree: 
https://github.com/python/cpython/blob/8f192d12af82c4dc40730bf59814f6a68f68f950/Lib/test/test_zoneinfo/test_zoneinfo.py#L465-L487


Originally reported on the backport by Sébastien Eustace: 
https://github.com/pganssle/zoneinfo/issues/82

The fix in the backport is here: https://github.com/pganssle/zoneinfo/pull/83

--
assignee: p-ganssle
components: Library (Lib)
messages: 371817
nosy: p-ganssle
priority: high
severity: normal
stage: needs patch
status: open
title: C implementation of ZoneInfo cannot be subclassed
versions: Python 3.10, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40933] zoneinfo may give incorrect dst() in Europe/Minsk in 1942

2020-06-09 Thread Paul Ganssle


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
>>> datetime(1942, 1, 1, tzinfo=ZoneInfo("Europe/Minsk")).dst() // 
timedelta(hours=1)

It looks like this occurs because they transitioned directly from MSK to CEST, 
jumping back 1 hour, then started switching between CEST and CET.

$ zdump -V -c 1941,1944 'Europe/Minsk'
Europe/Minsk  Fri Jun 27 20:59:59 1941 UT = Fri Jun 27 23:59:59 1941 MSK 
isdst=0 gmtoff=10800
Europe/Minsk  Fri Jun 27 21:00:00 1941 UT = Fri Jun 27 23:00:00 1941 CEST 
isdst=1 gmtoff=7200
Europe/Minsk  Mon Nov  2 00:59:59 1942 UT = Mon Nov  2 02:59:59 1942 CEST 
isdst=1 gmtoff=7200
Europe/Minsk  Mon Nov  2 01:00:00 1942 UT = Mon Nov  2 02:00:00 1942 CET 
isdst=0 gmtoff=3600
Europe/Minsk  Mon Mar 29 00:59:59 1943 UT = Mon Mar 29 01:59:59 1943 CET 
isdst=0 gmtoff=3600
Europe/Minsk  Mon Mar 29 01:00:00 1943 UT = Mon Mar 29 03:00:00 1943 CEST 
isdst=1 gmtoff=7200
Europe/Minsk  Mon Oct  4 00:59:59 1943 UT = Mon Oct  4 02:59:59 1943 CEST 
isdst=1 gmtoff=7200
Europe/Minsk  Mon Oct  4 01:00:00 1943 UT = Mon Oct  4 02:00:00 1943 CET 
isdst=0 gmtoff=3600

This might get fixed automatically if we do the "plurality" heuristic in 
bpo-40930, though we might also consider a heuristic that puts greater weight 
on a transition if the names associated with them different only by 
transforming a single letter, or insertion of a letter.

I am somewhat puzzled as to why only 1943 is affected, since I would have 
thought that all the CEST offsets in that stretch would be considered the same 
ttinfo (and thus all would be assigned the same dstoff).

--
assignee: p-ganssle
messages: 371141
nosy: p-ganssle
priority: normal
severity: normal
status: open
title: zoneinfo may give incorrect dst() in Europe/Minsk in 1942
versions: Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40933>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40931] zoneinfo gives incorrect dst() in Europe/Madrid in 1938

2020-06-09 Thread Paul Ganssle

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:59:59 1938 WET 
isdst=0 gmtoff=0
Europe/Madrid  Sat Apr  2 23:00:00 1938 UT = Sun Apr  3 00:00:00 1938 WEST 
isdst=1 gmtoff=3600
Europe/Madrid  Sat Apr 30 21:59:59 1938 UT = Sat Apr 30 22:59:59 1938 WEST 
isdst=1 gmtoff=3600
Europe/Madrid  Sat Apr 30 22:00:00 1938 UT = Sun May  1 00:00:00 1938 WEMT 
isdst=1 gmtoff=7200
Europe/Madrid  Sun Oct  2 21:59:59 1938 UT = Sun Oct  2 23:59:59 1938 WEMT 
isdst=1 gmtoff=7200
Europe/Madrid  Sun Oct  2 22:00:00 1938 UT = Sun Oct  2 23:00:00 1938 WEST 
isdst=1 gmtoff=3600
Europe/Madrid  Sat Oct  7 23:59:59 1939 UT = Sun Oct  8 00:59:59 1939 WEST 
isdst=1 gmtoff=3600
Europe/Madrid  Sun Oct  8 00:00:00 1939 UT = Sun Oct  8 00:00:00 1939 WET 
isdst=0 gmtoff=0

However, zoneinfo reports `.dst()` during the "double daylight saving time" 
period as 1 hour:

>>> from datetime import datetime, timedelta   
>>> from backports.zoneinfo import ZoneInfo
>>> datetime(1938, 5, 5, tzinfo=ZoneInfo("Europe/Madrid")).dst() / 
timedelta(hours=1) 
1.0
>>> datetime(1938, 5, 5, tzinfo=ZoneInfo("Europe/Madrid")).tzname()
'WEMT'

I believe the issue is that the "WEMT" is bordered on both sides by DST 
offsets, and so the heuristic of "Look for the previous or next non-DST zone 
and calculate the difference" doesn't work. We can probably solve this with one 
of two heuristics:

1. Allow DST → DST transitions to be included in the calculation of the current 
DST, such that when going from x_dst → y_dst, y_dstoff = (y_utcoff - x_utcoff) 
+ x_dstoff
2. Look more than 1 transition away to find the nearest STD zone in either 
direction, and calculate the offsets from there.

Between this bug and bpo-40930, I suspect we may want to write a rudimentary 
parser for `tzdata.zi` to be used only for testing our heuristics, since the 
`tzdata.zi` file (shipped with the `tzdata` package), does actually have the 
information we want, without resorting to heuristics.

--
assignee: p-ganssle
components: Library (Lib)
messages: 371137
nosy: p-ganssle
priority: normal
severity: normal
status: open
title: zoneinfo gives incorrect dst() in Europe/Madrid in 1938
versions: Python 3.10, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40931>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40930] zoneinfo gives incorrect dst() in Pacific/Rarotonga between 1978 and 1991

2020-06-09 Thread Paul Ganssle

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
  >>> datetime(1991, 2, 1, tzinfo=ZoneInfo("Pacific/Rarotonga")).dst() / 
  timedelta(hours=1) 
  1.0

This reports that the DST offset is 1 hour, but in fact it should be 30 
minutes, because from 1978 to 1991, Pacific/Rarotonga alternated between -0930 
and -10:

$ zdump -V -c 1990,1993 'Pacific/Rarotonga'
Pacific/Rarotonga  Sun Mar  4 09:29:59 1990 UT = Sat Mar  3 23:59:59 1990 -0930 
isdst=1 gmtoff=-34200
Pacific/Rarotonga  Sun Mar  4 09:30:00 1990 UT = Sat Mar  3 23:30:00 1990 -10 
isdst=0 gmtoff=-36000
Pacific/Rarotonga  Sun Oct 28 09:59:59 1990 UT = Sat Oct 27 23:59:59 1990 -10 
isdst=0 gmtoff=-36000
Pacific/Rarotonga  Sun Oct 28 10:00:00 1990 UT = Sun Oct 28 00:30:00 1990 -0930 
isdst=1 gmtoff=-34200
Pacific/Rarotonga  Sun Mar  3 09:29:59 1991 UT = Sat Mar  2 23:59:59 1991 -0930 
isdst=1 gmtoff=-34200
Pacific/Rarotonga  Sun Mar  3 09:30:00 1991 UT = Sat Mar  2 23:30:00 1991 -10 
isdst=0 gmtoff=-36000

I believe that the error comes from the fact that before 1978, they were on 
-1030 time, then they transitioned to -0930, then started alternating between 
-0930 and -10:

$ zdump -V -c 1977,1980 'Pacific/Rarotonga'
Pacific/Rarotonga  Sun Nov 12 10:29:59 1978 UT = Sat Nov 11 23:59:59 1978 -1030 
isdst=0 gmtoff=-37800
Pacific/Rarotonga  Sun Nov 12 10:30:00 1978 UT = Sun Nov 12 01:00:00 1978 -0930 
isdst=1 gmtoff=-34200
Pacific/Rarotonga  Sun Mar  4 09:29:59 1979 UT = Sat Mar  3 23:59:59 1979 -0930 
isdst=1 gmtoff=-34200
Pacific/Rarotonga  Sun Mar  4 09:30:00 1979 UT = Sat Mar  3 23:30:00 1979 -10 
isdst=0 gmtoff=-36000
Pacific/Rarotonga  Sun Oct 28 09:59:59 1979 UT = Sat Oct 27 23:59:59 1979 -10 
isdst=0 gmtoff=-36000
Pacific/Rarotonga  Sun Oct 28 10:00:00 1979 UT = Sun Oct 28 00:30:00 1979 -0930 
isdst=1 gmtoff=-34200

This is not amazingly important, but it would be a good idea to make the result 
correct.

Right now I think the heuristic looks for the first example of an STD → DST 
transition and decides that's the best option. It might be a good idea to 
change the heuristic to look at *all* examples of such transitions and choose 
the plurality value, and if there's no plurality value and one of the values is 
1H, choose that one.

--
assignee: p-ganssle
components: Library (Lib)
messages: 371136
nosy: p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: zoneinfo gives incorrect dst() in Pacific/Rarotonga between 1978 and 1991
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40930>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40908] datetime strftime with %Y and 2 digit years

2020-06-08 Thread Paul Ganssle


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 resolution would be a cross-platform implementation of 
strftime and strptime that does not rely on the system symbols, but that is a 
pretty large and overwhelming project.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> datetime.strftime("%Y") not consistent for years < 1000

___
Python tracker 
<https://bugs.python.org/issue40908>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

2020-06-04 Thread Paul Ganssle


Change by Paul Ganssle :


--
pull_requests: +19849
pull_request: https://github.com/python/cpython/pull/20624

___
Python tracker 
<https://bugs.python.org/issue40686>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40777] _datetimemodule.c:3328:16: error: initializer element is not constant

2020-05-28 Thread Paul Ganssle


Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 
<https://bugs.python.org/issue40777>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40799] Create Lib/_pydatetime.py file to optimize "import datetime" when _datetime is available

2020-05-28 Thread Paul Ganssle

Paul Ganssle  added the comment:

I basically agree with this — this is one of the reasons I structured the 
zoneinfo module the way I did rather than mimicking the pattern in datetime.

I believe that there are other modules that have similar situations like heapq, 
but datetime is probably the worst offender.

I am inclined to say that we should restructure datetime into a folder, 
containing __init__.py, _datetime.py and possibly _strptime.py (which I think 
is also only used in datetime), but I think that sort of restructuring is way 
more sensitive to weird import bugs than this one.

As it is now, I would be shocked if this didn't break *someone*, because people 
are always relying on weird implementation details (knowingly or unknowingly), 
but I think it's worth doing; it's good to tackle it this early in the cycle.

@vstinner What do you think about restructuring into a folder-based submodule 
rather than _pydatetime.py? It's way more likely to break someone, but I think 
it might be the better way to organize the code, and I don't want to have to go 
through *two* refactors of this sort.

--

___
Python tracker 
<https://bugs.python.org/issue40799>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40705] use-after-free in _zoneinfo.c's module_free function

2020-05-22 Thread Paul Ganssle


Paul Ganssle  added the comment:


New changeset 06a1b8915d6674e40f0dccc422ca2c06212392d8 by Ammar Askar in branch 
'master':
bpo-40705: Fix use-after-free in _zoneinfo's module_free (GH-20280)
https://github.com/python/cpython/commit/06a1b8915d6674e40f0dccc422ca2c06212392d8


--

___
Python tracker 
<https://bugs.python.org/issue40705>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40713] _zoneinfo.c can use dst_offset without initialization in parse_tz_str()

2020-05-21 Thread Paul Ganssle


Paul Ganssle  added the comment:

This is a duplicate of bpo-40714. It's a bit of an overzealous compiler warning 
(as far as I can tell it's not true that the uninitialized value would ever be 
used), but we fixed it anyway in GH-20291.

Thanks for the report!

--
nosy: +p-ganssle
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40713>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40705] use-after-free in _zoneinfo.c's module_free function

2020-05-21 Thread Paul Ganssle


Change by Paul Ganssle :


--
versions: +Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40705>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40683] Beta release does not distribute zoneinfo or test_zoneinfo

2020-05-19 Thread Paul Ganssle

Paul Ganssle  added the comment:

No worries Łukasz, I figured it would be worth bringing up because normally the 
releases aren't so broken that they aren't usable in the common case. That 
said, this won't break any *existing* code, it'll just prevent people on Linux 
machines from using zoneinfo.

I don't think waiting 3 weeks is a big deal. I'm planning to release a backport 
soon anyway, and I expect people probably won't adopt new-in-3.9 modules 
without a backport during the beta period *anyway*, since they can't deploy any 
code using that feature to prod.

I'm going to resolve this issue. Thanks for the quick response Łukasz and for 
the quick review Victor!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40683] Beta release does not distribute zoneinfo or test_zoneinfo

2020-05-19 Thread Paul Ganssle

Paul Ganssle  added the comment:

Victor has confirmed that this is working on Windows, so I think the current 
state of the 3.9 and master branches is now fixed.

The last question remaining is whether this justifies a quick b2 release (or if 
there's another mechanism for a "fixup" release like b1.post0). Łukasz, what do 
you think?

--

___
Python tracker 
<https://bugs.python.org/issue40683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40683] Beta release does not distribute zoneinfo or test_zoneinfo

2020-05-19 Thread Paul Ganssle


Paul Ganssle  added the comment:


New changeset 2abededbc4165d2daa14ae9d74b1f33cce0593d7 by Paul Ganssle in 
branch 'master':
bpo-40683: Add zoneinfo to LIBSUBDIRS (#20229)
https://github.com/python/cpython/commit/2abededbc4165d2daa14ae9d74b1f33cce0593d7


--

___
Python tracker 
<https://bugs.python.org/issue40683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40683] Beta release does not distribute zoneinfo or test_zoneinfo

2020-05-19 Thread Paul Ganssle


Paul Ganssle  added the comment:

Victor: Might be worth updating your notes to indicate that any subdirectory 
(not just test subdirectories) need to go into LIBSUBDIRS. zoneinfo uses a 
subdirectory for both the tests and the zoneinfo module, and *neither* were 
included in the installation in this case.

--
title: Beta release does not distribute test_zoneinfo -> Beta release does not 
distribute zoneinfo or test_zoneinfo

___
Python tracker 
<https://bugs.python.org/issue40683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40683] Beta release does not distribute test_zoneinfo

2020-05-19 Thread Paul Ganssle


Change by Paul Ganssle :


--
keywords: +patch
pull_requests: +19520
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/20229

___
Python tracker 
<https://bugs.python.org/issue40683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40683] Beta release does not distribute zoneinfo

2020-05-19 Thread Paul Ganssle


Paul Ganssle  added the comment:

I think I found the problem: these directories are not included in the 
Makefile.pre.in LIBSUBDIRS variable: 
https://github.com/python/cpython/blob/a355a06fcc7ef2232736dceb012ae623335cd7ab/Makefile.pre.in#L1373

PR incoming.

--

___
Python tracker 
<https://bugs.python.org/issue40683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40683] Beta release does not distribute zoneinfo

2020-05-19 Thread Paul Ganssle


New submission from Paul Ganssle :

Apparently something is wrong with make install for beta 1 and the `zoneinfo` 
module is not installed with it (only _zoneinfo).

When I run a local build `./python -c "import zoneinfo"` works, but when I do 
`make install` I get ImportError:

  $ bin/python3 -c "import zoneinfo"
  Traceback (most recent call last):
File "", line 1, in 
  ModuleNotFoundError: No module named 'zoneinfo'

I assume this wasn't caught earlier because Lib/test/test_zoneinfo is *also* 
not being installed.

The C extension, _zoneinfo, is installed properly. I don't know if it is 
working on Windows.

--
assignee: p-ganssle
messages: 369357
nosy: lukasz.langa, p-ganssle
priority: critical
severity: normal
stage: needs patch
status: open
title: Beta release does not distribute zoneinfo
type: compile error
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5537] LWPCookieJar cannot handle cookies with expirations of 2038 or greater on 32-bit platforms

2020-05-18 Thread Paul Ganssle


Paul Ganssle  added the comment:

> Should we fix utcfromtimestamp() internally to avoid the OverflowError, 
> rather than only fixing the http.cookiejar module?

I'm not a big fan of utcfromtimestamp (as you can see here: 
https://blog.ganssle.io/articles/2019/11/utcnow.html ), but it seems we do have 
the same issue in `datetime.datetime.fromtimestamp`, so I think maybe we should 
spawn a new issue to at least look into the possibility?

--

___
Python tracker 
<https://bugs.python.org/issue5537>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-05-17 Thread Paul Ganssle

Paul Ganssle  added the comment:

I've merged the existing implementation, but I'm leaving this staged as 
"release blocker" so that Łukasz can have final say on whether this goes into 
3.9.

Thanks for the help everyone!

--

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-05-17 Thread Paul Ganssle


Paul Ganssle  added the comment:


New changeset e527ec8abe0849e784ce100f53c2736986b670ae by Paul Ganssle in 
branch 'master':
bpo-40536: Add zoneinfo.available_timezones (GH-20158)
https://github.com/python/cpython/commit/e527ec8abe0849e784ce100f53c2736986b670ae


--

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-05-17 Thread Paul Ganssle

Paul Ganssle  added the comment:

I've opened a PR adding this feature and tagged this as release blocker, since 
I'd like to make sure this is in the beta if Łukasz does not object.

The concerns about the stability of the function I expressed earlier have not 
changed much, though we did get some feedback from the tz database list that at 
least make me think that the new approach (excluding posix/, right/ and 
posixrules) is *probably* the right way to go.

--
priority: normal -> release blocker

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-05-17 Thread Paul Ganssle


Change by Paul Ganssle :


--
pull_requests: +19461
pull_request: https://github.com/python/cpython/pull/20158

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-16 Thread Paul Ganssle


Paul Ganssle  added the comment:


New changeset b17e49e0def23238b9e7f48c8a02e2d7bbf1f653 by Paul Ganssle in 
branch 'master':
bpo-40503: Add documentation and what's new entry for zoneinfo (GH-20006)
https://github.com/python/cpython/commit/b17e49e0def23238b9e7f48c8a02e2d7bbf1f653


--

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40643] Improve doc-strings for datetime.strftime & strptime

2020-05-16 Thread Paul Ganssle


Paul Ganssle  added the comment:

I agree, this can be improved (particularly the first one). I believe we'll 
need to change it in the C implementation as well as the pure python version.

That said, the most useful thing for users would be a full formatting 
reference, which is too much to put in the docstring (and to maintain in at 
least 3 different places). I'm not sure *how* much better it can get, but at 
least the first one reads like a terrible self-referential dictionary entry 
"recyclist (n). a proponent of recyclism". At the very least it should 
disambiguate between `datetime.strftime`, `time.strftime` and `stftime(3)`.

--
nosy: +p-ganssle
priority: normal -> low
stage:  -> needs patch
type:  -> enhancement

___
Python tracker 
<https://bugs.python.org/issue40643>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24416] Have date.isocalendar() return a structseq instance

2020-05-16 Thread Paul Ganssle


Paul Ganssle  added the comment:

This is now merged, thanks for the debate and opinions offered everyone, and 
thanks to Dong-hee for the implementation!

The way we did the implementation, a pickle/unpickle cycle on the result of 
.isocalendar() will return a plain tuple. Despite the fact that I suggested it, 
I recognize that this is a /weird thing to do/, and I'm sorta banking on the 
fact that in all likelihood no one is relying on pickling and unpickling the 
result of .isocalendar() returning anything but a tuple (since, currently, 
that's already what it does, regardless of what the input type was).

I suppose we'll have to see if it causes problems in the beta period, and I'll 
keep a close eye on it.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue24416>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24416] Have date.isocalendar() return a structseq instance

2020-05-16 Thread Paul Ganssle


Paul Ganssle  added the comment:


New changeset 1b97b9b0ad9a2ff8eb5c8f2e2e7c2aec1d13a330 by Paul Ganssle in 
branch 'master':
bpo-24416: Return named tuple from date.isocalendar() (GH-20113)
https://github.com/python/cpython/commit/1b97b9b0ad9a2ff8eb5c8f2e2e7c2aec1d13a330


--

___
Python tracker 
<https://bugs.python.org/issue24416>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24416] Have date.isocalendar() return a structseq instance

2020-05-15 Thread Paul Ganssle


Change by Paul Ganssle :


--
pull_requests: +19420
pull_request: https://github.com/python/cpython/pull/20113

___
Python tracker 
<https://bugs.python.org/issue24416>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-13 Thread Paul Ganssle

Paul Ganssle  added the comment:

Talked to Steve Dower in a sidebar about the issue with compile-time 
configuration, he is convinced that compile-time configuration is not something 
that would be useful or worth doing on Windows. I am indifferent on the matter, 
so I am fine with calling the compile-time configuration part of this done at 
this point. If anyone building Python for Windows shows up needing support for 
this, we can re-visit the issue — I don't believe it's technically infeasible, 
just that the usage patterns of Python on Windows mean that it's not worth 
doing.

So, once we've got a critical mass of reviews done for zoneinfo, I think this 
feature is done. 

--

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-05-13 Thread Paul Ganssle

Paul Ganssle  added the comment:

>From some discussion on the reference implementation PR, it seems that this 
>may be a more complicated feature than I had bargained for: 
>https://github.com/pganssle/zoneinfo/pull/60

The issue is that the current implementation picks up the posix/ and right/ 
directories as well as the posixrules file, none of which is *wrong* — they are 
available time zones, after all — but they're not really canonical zones. In 
`tzdata` we have a list of zones sourced from tzdata's `make zonenames`, which 
does not include the posix/ and right/ directories.

There is `zone1970.tab` and `zone.tab`, but that has *too* strict of a subset — 
it only includes canonical zones associated with a specific country, as far as 
I can tell, and not things like UTC. It also includes, for example, 
America/Nuuk but not America/Godthab (which was the canonical name up until 
2020a).

I'm considering postponing this feature to Python 3.10 so that we can have more 
time to figure out a decent API for this.

Łukasz: Question for you as release manager — would you prefer that we put this 
in for 3.9 with the understanding that before the final release we may end up 
needing to remove it as a nuisance or change what it returns (and possibly 
flags that would be passed to it), or would that be too disruptive in the beta 
period? I'm confident that we can make a final decision before October, just 
not confident that we can make a final decision before Monday.

--
assignee:  -> p-ganssle
nosy: +lukasz.langa

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-11 Thread Paul Ganssle

Paul Ganssle  added the comment:

Here are some benchmarks run using the latest implementation. The pure Python 
code is pretty optimized, but the C code is still ~4-5x faster.

Running from_utc in zone Europe/Paris
c_zoneinfo: mean: 494.82 ns ± 3.80 ns; min: 489.23 ns (k=5, N=50)
py_zoneinfo: mean: 2.48 µs ± 79.17 ns; min: 2.42 µs (k=5, N=10)
dateutil: mean: 10.41 µs ± 209.97 ns; min: 10.17 µs (k=5, N=5)
pytz: mean: 4.69 µs ± 252.70 ns; min: 4.39 µs (k=5, N=5)

Running to_utc in zone Europe/Paris
c_zoneinfo: mean: 539.61 ns ± 25.68 ns; min: 514.39 ns (k=5, N=50)
py_zoneinfo: mean: 2.01 µs ± 61.69 ns; min: 1.94 µs (k=5, N=10)
dateutil: mean: 7.88 µs ± 506.89 ns; min: 7.25 µs (k=5, N=5)
pytz: mean: 773.02 ns ± 14.11 ns; min: 759.56 ns (k=5, N=50)

Running utcoffset in zone Europe/Paris
c_zoneinfo: mean: 329.34 ns ± 36.31 ns; min: 302.88 ns (k=5, N=100)
py_zoneinfo: mean: 1.57 µs ± 9.58 ns; min: 1.55 µs (k=5, N=20)
dateutil: mean: 6.28 µs ± 86.61 ns; min: 6.16 µs (k=5, N=5)
pytz: mean: 461.47 ns ± 2.07 ns; min: 458.91 ns (k=5, N=50)


`utcoffset()` is very likely to be called possibly many times in certain hot 
loops (including implicitly as it's part of hash and equality checks).

--

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-11 Thread Paul Ganssle


Paul Ganssle  added the comment:

I mean, theoretically we don't "need" it, but it's much, much faster, and 
without it nearly every operation that needs time zone offsets will be slower 
than pytz (which has a mechanism for caching).

Also, I've already written it, so I see no reason why not use it.

--

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-05-11 Thread Paul Ganssle


Change by Paul Ganssle :


--
pull_requests:  -19344

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-05-11 Thread Paul Ganssle


Change by Paul Ganssle :


--
keywords: +patch
pull_requests: +19344
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19909

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-11 Thread Paul Ganssle


Paul Ganssle  added the comment:

Thanks Thomas, that was super helpful. I've created GH-20034 to add in the 
compile-time arguments on POSIX systems at least, do you mind having a look?

For the moment I have made it non-configurable on Windows, but I think the 
right thing to do is to add an argument to PCbuild\build.bat. Hopefully Steve 
can point me in the right direction for mapping that argument (or something 
else) to a new config variable in sysconfig.

--

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-11 Thread Paul Ganssle


Change by Paul Ganssle :


--
pull_requests: +19343
pull_request: https://github.com/python/cpython/pull/20034

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-05-09 Thread Paul Ganssle


Paul Ganssle  added the comment:

I have an initial implementation against the reference implementation here: 
https://github.com/pganssle/zoneinfo/pull/60

Once GH-19909 is merged, I will turn that into a PR against CPython.

For the first pass I went with:

1. free-standing function
2. returning set()
3. no cache
4. available_timezones()

--

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-08 Thread Paul Ganssle

Paul Ganssle  added the comment:

I've separated this into two separate PRs, one for docs and one for 
tests/implementation.

I have not yet implemented the logic for the ability to configure the TZPATH at 
compile time because I'm not quite sure how to start on that. How are other 
compile-time options implemented? Do I need to do something special to handle 
both Windows and POSIX systems? Is there already a configuration file somewhere 
that I should use for this? Adding Thomas to the nosy list because he's the 
only one listed for "autoconf/makefiles" – don't know if that extends to the 
Windows build as well.

--
nosy: +twouters

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-08 Thread Paul Ganssle


Change by Paul Ganssle :


--
pull_requests: +19318
pull_request: https://github.com/python/cpython/pull/20006

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40536] Addition of a "list of available time zones" function to zoneinfo

2020-05-06 Thread Paul Ganssle

New submission from Paul Ganssle :

One thing that I sort of overlooked in PEP 615 that I think will be a common 
feature request for zoneinfo is the ability to get a list of time zones 
available on the current TZPATH.

This is more complicated to implement than it sounds like, but luckily I 
already did it in order to implement the property tests for the zoneinfo module:

https://github.com/pganssle/zoneinfo/blob/ffd21a6d065e04725e04b37bb430c2559fefd5fa/tests/test_zoneinfo_property.py#L23-L70

The biggest complication is that there are files on TZPATH that are not 
necessarily time zones, and when I looked I couldn't easily find a list of all 
available time zones, so the only way to tell which ones are time zones and 
which ones aren't is to open each one and read the first 4 bytes. However, 
`tzdata` does ship with a list of available time zones, so the way I've got the 
function working right now is:

1. If `tzdata` is installed – despite the fact that it's technically the end of 
the search path, convert the list of available zones that ships with `tzdata` 
to your starting set (since you know these are all valid zones).
2. Walk the `tzpath`, and every time you find something not in the set of valid 
keys, open it and read the first 4 bytes, then add that to the set.

The common cases will be that `tzdata` is not available (in which case no harm 
done), or `tzdata` has the same set of keys as the TZPATH, in which case you 
never have to open any of the TZif files. The fact that the search order is 
inverted from what it normally is doesn't matter because the output is the 
union of all the sets anyway.

I don't know that the PEP needs to be amended – if this were a feature request 
for Python 3.10 I don't think it would need a PEP to go through, but I don't 
mind amending the PEP to document it.

Design decisions (with my initial answers, loosely held):

1. Should this be a classmethod or a free-standing function?

I'm inclined towards free-standing function because zoneinfo.TZPATH is at the 
module level and not the class level.

2. What should the return type be?

I think frozenset() or set(); a sorted list is also a reasonable option, but 
for people who just want to use "in" or show some subset of available zones, 
that would be wasteful.

We should go with frozenset() if we want there to be some possibility of 
caching the result in the future.

3. Should we try to cache the result?

I would say no, at least for now. It would not be super easy to get the cache 
invalidation right in the general case, and not many people are likely to be 
sensitive to the performance of this operation – the people who are can easily 
create their own cache.

4. What should it be called?

Naming things is hard. Options:

- zoneinfo.timezones()
- zoneinfo.all_timezones()
- zoneinfo.timezone_{list,set}()
- zoneinfo.valid_timezones()
- zoneinfo.valid_keys()
- zoneinfo.available_timezones()

`pytz` has a similar thing and calls it all_timezones. It also has something 
called common_timezones, but that is a bit harder to pull off and I'm not 
confident that we'll get something satisfactory before the feature freeze.

--
components: Library (Lib)
messages: 368285
nosy: belopolsky, lemburg, p-ganssle
priority: normal
severity: normal
status: open
title: Addition of a "list of available time zones" function to zoneinfo
type: enhancement
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-04 Thread Paul Ganssle


Change by Paul Ganssle :


--
keywords: +patch
pull_requests: +19224
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19909

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40503] PEP 615: Add zoneinfo module

2020-05-04 Thread Paul Ganssle


New submission from Paul Ganssle :

This is an issue to track the implementation of PEP 615: 
https://www.python.org/dev/peps/pep-0615/

It should mostly involve migrating from the reference implementation: 
https://github.com/pganssle/zoneinfo/

--
assignee: p-ganssle
components: Library (Lib)
messages: 368076
nosy: belopolsky, lemburg, p-ganssle
priority: high
severity: normal
stage: needs patch
status: open
title: PEP 615: Add zoneinfo module
type: enhancement
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40503>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40236] datetime.datetime.strptime get day error

2020-04-16 Thread Paul Ganssle


Change by Paul Ganssle :


--
stage:  -> needs patch

___
Python tracker 
<https://bugs.python.org/issue40236>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40236] datetime.datetime.strptime get day error

2020-04-09 Thread Paul Ganssle


Paul Ganssle  added the comment:

Likely relevant is bpo-23136, where they dealt with similar issues in the past.

I don't see any explicit test for this behavior, but it seems that the solution 
is to try to be consistent and to not raise a ValueError.

Looking at this issue, I think it's a manifestation of a similar bug that hits 
when a year starts with a Monday.

It seems like the behavior is that the following days (%W-%w) should be 
sequential in any year: 00-1, 00-2, 00-3, 00-4, 00-5, 00-6, 00-0, 01-1, 01-2, 
...

Since 2024 starts in a Monday, the first day of the year should be 2024-01-1, 
and the 2024-00-1 week should start 2023-12-25 rather than duplicating the 
following week.

I think there's an equivalent issue with dates of the form "%Y-%U-%w", but 
happening on years that start with a Sunday.

--

___
Python tracker 
<https://bugs.python.org/issue40236>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40236] datetime.datetime.strptime get day error

2020-04-09 Thread Paul Ganssle


Paul Ganssle  added the comment:

I can reproduce this on Linux with Python 3.8.2.

I think this may be a bug, but it may also just be platform-specific weirdness. 
Either way it's very curious behavior:


>>> datetime.strptime("2023-0-0", "%Y-%W-%w") 
datetime.datetime(2023, 1, 1, 0, 0)
>>> datetime.strptime("2023-0-1", "%Y-%W-%w") 
datetime.datetime(2022, 12, 26, 0, 0)

The definition for %W (and %U, which is related) goes like this:


> Week number of the year (Monday as the first day of the week) as a decimal 
> number. All days in a new year preceding the first Monday are considered to 
> be in week 0.

2024 starts on a Monday, so there should be no Week 0 in that year at all. 
Seems to me like it's undefined what happens when you put in a string that puts 
in an invalid value for "%Y-%W-%w".

Seems to me that we are just passing through the behavior of `time.strptime` in 
this case (which just calls out to what the platform does):

>>> time.strptime("2024-0-3", "%Y-%W-%w") 
time.struct_time(tm_year=2024, tm_mon=1, tm_mday=3, tm_hour=0, tm_min=0, 
tm_sec=0, tm_wday=2, tm_yday=3, tm_isdst=-1)


I am open to discussion about trying to rationalize this behavior - it would be 
a bit tricky but if we moved to our own implementation of the algorithm to 
calculate %W we could detect this situation and throw an exception. I'd rather 
see if this is intended behavior in the underlying C implementation first, 
though. If this is consistent across platforms and not just some random 
implementation detail, people may be relying on it.

I propose that we:

1. Determine what happens on different platforms (might be easy to just make a 
PR that asserts the current behavior and see if/how it breaks on any of the 
supported platforms).
2. Determine why it works the way it does.


After that, at the very least we should document the behavior with a warning or 
a footnote or something. If we make any changes to the behavior they would be 
3.9+, but the documentation changes can be backported.

Thanks for the bug report zhanying! Very interesting!

--
versions: +Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40236>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40173] test.support.import_fresh_module fails to correctly block submodules when fresh is specified

2020-04-03 Thread Paul Ganssle


New submission from Paul Ganssle :

It seems that test.support.import_fresh_module gets tripped up with its module 
blocking when you attempt to get a fresh copy of a submodule of a module where 
you are also importing the module that you are trying to block (bit of a doozy 
of a sentence there...). So, for example, with the following configuration in 
mymodule/__init__.py:

from .other import other

try:
from ._a import attr
except ImportError:
from ._b import attr

(Assuming _a.attr = "A" and _b.attr = "B"), if you attempt to do:

m = test.support.import_fresh_module("mymodule", 
fresh=("mymodule._other",), blocked=("mymodule._a"))

Then you'll find that m.attr is pulled from _a.attr. Here's a small script to 
demonstrate:

from test.support import import_fresh_module
import sys

def import_ab(fresh_other):
fresh = ("mymodule._other", ) if fresh_other else ()

mods_out = []
for to_block in "_b", "_a":
blocked = (f"mymodule.{to_block}",)

mods_out.append(import_fresh_module("mymodule",
fresh=fresh, blocked=blocked))
return mods_out


for fresh_other in [True, False]:
mymodule_a, mymodule_b = import_ab(fresh_other)

qualifier = "With" if fresh_other else "Without"
print(f"{qualifier} a fresh import of mymodule._other")

print(f"a: {mymodule_a.attr}")
print(f"b: {mymodule_b.attr}")
print()

When you run it with a suitably configured module on Python 3.8:

$ python importer.py 
With a fresh import of mymodule._other
a: A
b: A

Without a fresh import of mymodule._other
a: A
b: B

It also happens if you add `mymodule._a` or `mymodule._b` to the fresh list 
when you are trying to block the other one.

I *think* the problem is that in the step where _save_and_remove_module is 
called on fresh_name (see here: 
https://github.com/python/cpython/blob/76db37b1d37a9daadd9e5b320f2d5a53cd1352ec/Lib/test/support/__init__.py#L328-L329),
 it's necessarily populating `sys.modules` with a fresh import of the top-level 
module we're trying to import (mymodule) *before* the blocking goes into 
effect, then the final call to importlib.import_module just hits that cache.

I think either of the following options will fix this issue:

1. Switching the order of how "fresh" and "blocked" are resolved or
2. Deleting `sys.modules[name]` if it exists immediately before calling 
`importlib.import_module(name)

That said, I'm still having some weird statefulness problems if I block a C 
module's import and *then* block a Python module's import, so there may be some 
other underlying pathology to the current approach.

--
components: Tests
files: test_support_repro.zip
messages: 365702
nosy: brett.cannon, eric.snow, ncoghlan, p-ganssle
priority: normal
severity: normal
status: open
title: test.support.import_fresh_module fails to correctly block submodules 
when fresh is specified
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49031/test_support_repro.zip

___
Python tracker 
<https://bugs.python.org/issue40173>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40136] add warning to datetime.replace documentation to not use it for setting tzinfo unless UTC or None

2020-04-01 Thread Paul Ganssle


Paul Ganssle  added the comment:

That is a specific problem with the third-party library `pytz`, not a standard 
feature of the datetime module. Using `datetime.replace` is the intended way to 
set a time zone, see: 
https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html

As of Python 3.6, we've been recommending dateutil.tz instead of pytz, and 
assuming PEP 615 is accepted ( https://www.python.org/dev/peps/pep-0615/ ), we 
will have a built in time zone type that supports IANA time zones.

I am going to close this because this is not a bug in CPython, but if you think 
otherwise feel free to continue using this ticket to make the case.

--
nosy: +p-ganssle
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40136>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33262] Deprecate shlex.split(None) to read from stdin.

2020-04-01 Thread Paul Ganssle


Paul Ganssle  added the comment:


New changeset 975ac326ffe265e63a103014fd27e9d098fe7548 by Zackery Spytz in 
branch 'master':
bpo-33262: Deprecate passing None for `s` to shlex.split() (GH-6514)
https://github.com/python/cpython/commit/975ac326ffe265e63a103014fd27e9d098fe7548


--
nosy: +p-ganssle

___
Python tracker 
<https://bugs.python.org/issue33262>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   5   >