https://devguide.python.org gives the intro page with TOC on sidebar and
at end. Clicking anything, such as Getting Started, which tries to
display https://devguide.python.org/setup/, returns a Read the Docs page
"Sorry This page does not exist yet." 'Down for everyone' site also
Terry Jan Reedy
I have one last feature request that I'd like added to datetime for
Python 3.8, and this one I think could use some more discussion, the
addition of a "time zone index cache" to the /datetime/ object. The
rationale is laid out in detail in bpo-35723
<https://bugs.python.org/issue35723>. The general problem is that
currently, /every/ invocation of utcoffset, tzname and dst needs to do
full, independent calculations of the time zone offsets, even for time
zones where the mapping is guaranteed to be stable because datetimes are
immutable. I have a proof of concept implementation: PR #11529
I'm envisioning that the `datetime` class will add a private `_tzidx`
single-byte member (it seems that this does not increase the size of the
datetime object, because it's just using an unused alignment byte).
`datetime` will also add a `tzidx()` method, which will return `_tzidx`
if it's been set and otherwise it will call `self.tzinfo.tzidx()`. If
`self.tzinfo.tzidx()` returns a number between 0 and 254 (inclusive), it
sets `_tzidx` to this value. tzidx() then returns whatever
The value of this is that as far as I can tell, nearly all non-trivial
tzinfo implementations construct a list of possible offsets, and
implement utcoffset(), tzname() and dst() by calculating an index into
that list and returning it. There are almost always less than 255
distinct offsets. By adding this cache /on the datetime/, we're using a
small amount of currently-unused memory to prevent unnecessary
calculations about a given datetime. The feature is entirely opt-in, and
has no downsides if it goes unused, and it makes it possible to write
tzinfo implementations that are both lazy and as fast as the "eager
calculation" mode that pytz uses (and that causes many problems for
I have explored the idea of using an lru cache of some sort on the
tzinfo object itself, but there are two problems with this:
1. Calculating the hash of a datetime calls .utcoffset(), which means
that it is necessary to, at minimum, do a `replace` on the datetime (and
constructing a new datetime is a pretty considerable speed hit)
2. It will be a much bigger memory cost, since my current proposal uses
approximately zero additional memory (not sure if the alignment stuff is
platform-dependent or something, but it doesn't use additional memory on
my linux computer).
I realize this proposal is somewhat difficult to wrap your head around,
so if anyone would like to chat with me about it in person, I'll be at
PyCon sprints until Thursday morning.
Eek! I was just doing a bit of branch cleanup in the cpython repo and managed to trigger a bunch (30-ish) of duplicate checkin messages to bugs.python.org for old commits. I will remove them from b.p.o. Please ignore any 3.4 spam email. Sorry!
nad(a)python.org -- 
How do I redo a failed PR check?
The appveyor failure for https://github.com/python/cpython/pull/13181
appears to be spurious, but there is no obvious way to redo it.
BTW, this is not the first time I've seen a PR blocked by a spurious
Hello Python Dev team!
I submitted a Bug+PR back in February and unfortunately, nobody has given
it a review yet. :/
I'm was hoping that someone could take a look and suggest changes (if
needed). I realize that there are a ton of PRs and things to review across
the board, but here's to hoping someone has a little time to take a look at
Thanks so much!
It's with a note of sadness that I announce the final retirement of
Python 3.4. The final release was back in March, but I didn't get
around to actually closing and deleting the 3.4 branch until this morning.
Python 3.4 introduced many features we all enjoy in modern Python--the
asyncio, ensurepip, and enum packages, just to name three. It's a
release I hope we all remember fondly.
My eternal thanks to all the members of the release team that worked on
Martin von Löwis
and all the engineers of the Python infrastructure team.
Special thanks to Benjamin Peterson and Ned Deily, who frequently
scurried around behind the scenes cleaning up the messes I cluelessly
left in my wake.
Having closed 3.4, I am now retired as Python 3.4 Release Manager. I
regret to inform all of you that you're still stuck with me as Python
3.5 Release Manager until sometime next year.
My very best wishes,