Due to awkward CDN caching, some users who downloaded the source code
tarballs of Python 3.5.8 got a preliminary version instead of the final
version. As best as we can tell, this only affects the .xz release;
there are no known instances of users downloading an incorrect version
of the .tgz file.
If you downloaded "Python-3.5.8.tar.xz" during the first twelve hours of
its release, you might be affected. It's easy to determine this for
yourself. The file size (15,382,140 bytes) and MD5 checksum
(4464517ed6044bca4fc78ea9ed086c36) published on the release page have
always matched the correct version. Also, the GPG signature file will
only report a "Good signature" for the correct .xz file (using "gpg
What's the difference between the two? The only difference is that the
final version also merges a fix for Python issue tracker #38243:
The fix adds a call to "html.escape" at a judicious spot, line 896 in
Lib/xmlrpc/server.py. The only other changes are one new test, to
ensure this new code is working, and an entry in the NEWS file. You can
see the complete list of changes here:
What should you do? It's up to you.
* If you and your users aren't using the XMLRPC library built in to
Python, you don't need to worry about which version of 3.5.8 you
* If you downloaded the .tgz tarball or the Git repo, you already have
the correct version.
* If you downloaded the xz file and want to make sure you have the
fix, check the MD5 sum, and if it's wrong download a fresh copy (and
make sure that one matches the known good MD5 sum!).
To smooth over this whole sordid mess, I plan to make a 3.5.9 release in
the next day or so. It'll be identical to the 3.5.8 release; its only
purpose is to ensure that all users have the same updated source code,
including the fix for #38243.
Sorry for the mess, everybody,
The csv module is probably heavily utilized by newcomers to Python, being a
very popular data exchange format.
Although, there are better tools for processing tabular data like SQLite,
or Pandas, I suspect this is still a very popular
There are many examples floating around how one can read and process CSV
with the csv module.
Quite a few tutorials show how to use namedtuple to gain memory saving and
speed, over the DictReader.
Python's own documentation has got a recipe in the collections modules
Hence, I was wondering why not go the extra step and add a new class to the
CSV module NamedTupleReader?
This class would do a good service for Python's users, especially newcomers
who are still not aware of
modules like the collections module.
Would someone be willing to sponsor and review such a PR from me?
As a smaller change, we could simply add a link from the CSV module's
documentation to the recipe in the collections module.
What do you think?
Imagine there's no countries
it isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace
On behalf of the Python development community, I'm relieved to announce
the availability of Python 3.5.8.
Python 3.5 is in "security fixes only" mode. This new version only
contains security fixes, not conventional bug fixes, and it is a
You can find Python 3.5.8 here:
Oh what fun,
Recently, Brett updated the developer log in the devguide
(https://devguide.python.org/developers/) to fetch the names of each core
developer and the date they were given commit privileges from the private
I think it would also be quite useful to include GitHub usernames on that list.
Currently, the only list that contributors can find the GitHub usernames for
each core developer is through the committers list on bpo. Since we will be
moving away from bpo (PEP 581), we should have a comprehensive list that is
separate from that platform.
The motivation behind creating a a new topic for this issue was Brett's
response to my comment in the PR that updated the devguide
Essentially, if no core developers have an issue with having their GitHub
username posted on the devguide, we can move forward with adding it.
Another related but more long term project is adding the GitHub usernames
to the experts index (https://devguide.python.org/experts/). This is more
involved because the bpo nosy list currently pulls from the experts index,
meaning the nosy list is dependent on the specific formatting used.
To address this, I opened a PR a couple of months ago which would add a .json
file containing the data from the experts index
(https://github.com/python/devguide/pull/517), based on the discussion in the
related issue (https://github.com/python/devguide/issues/507). If any available
core developers are experienced with structuring .json files, I would greatly
appreciate any feedback.
The next step would be converting the nosy list script to use the new .json
file instead of the experts index page, so that we could adjust the page
to also include GitHub usernames. Optimally, the contents in the experts
index would be pulled from the .json file automatically so any changes only
have to be made to a single location.
Hi CPython maintainers,
I need to test my CORS setup and looking for a possibility to set a
*header in http.server. As of now, there is no such feature. Are you
interested in me writing a patch to contribute a feature of setting custom
headers directly to `http.server`?
I just posted a new PEP for comments, please reply there, rather than by email:
PEP 608: Coordinated Python release
Block a Python release until a compatible version of selected projects
The Python release manager can decide to release Python even if a
project is not compatible, if they decide that the project is going to
be fixed soon enough, or if the issue severity is low enough.
Night gathers, and now my watch begins. It shall not end until my death.
I've found myself recently writing Python code that dynamically generates
bytecode.¹ I now have yet another case where I'm having to do this, in
which my nice situation of being able to easily precompute all the jump
addresses no longer holds. So I'm starting to write a helper to make it
easy to write bytecode from Python, with its basic API calls being
write(opcode, arg) and nextLine(optional label). The argument can be an
int, name, local name, constant, label, etc., depending on the opcode, and
it maintains all the appropriate tables and finally dumps a code object at
All of which is well and good and makes life much easier, but... I am
forward to writing the logic that basically duplicates that of assemble()
in compile.c, of splitting all of this into basic blocks and computing the
correct jump positions and so on before finally dumping out the bytecode.
Has anyone already done this that people know of? (Searching the
Internetz didn't turn anything up) Failing that, to what extent is it
reasonable to either consider assemble() as some kind of sane API point
into compile.c, and/or add some new API in compile.h which implements all
of the stuff described above in C?
(I'm fully expecting the answer to these latter questions to be "you have
got to be kidding me," but figured it was wiser to check than to reinvent
this particular wheel if it isn't necessary)
¹ Not out of masochism, in case you're wondering; there was a real use
case. A storage system would receive a read request that specified a bunch
of (key, condition) pairs, where conditions where either return any value,
return an exact value, or return values in a range. It would then receive
between 1 and 1M (depending on the request parameters) candidate cells from
the underlying storage layers, each of which had a tuple of bytes as its
actual key values; it had to compare each of those tuples against the
request parameters, and yield the values which matched. Because it's an
inner loop and can easily be called 1M times, doing this in pure Python
slows things down by a lot. Because it's also only called once, doing some
really expensive overhead like synthesizing Python code and calling
compile() on it would also slow things down a lot. But converting a bunch
of (key, condition) pairs to a really efficient function from tuples of
bytes to bools was pretty easy.
Dear Sir / Madam ,
I'm Lasan Nishshanka, CEO and the Founder of Clenontec. We are creating
an IDE. It's name is Bacend Studio. We're creating this for the Windows
Operating System. This IDE is designed to perform special functions such
as App Development, Software Development, Games Development, Machine
Learning, Artificial Intelligence etc.
We will send you this letter to get permission to add the PYTHON
Programming Language to our IDE. If you can give it permission, please
tell us. We await a speedy reply from you.
Company Web Site : https://www.clenontec.com/
E Mail : Clenontec(a)gmail.com
This email has been checked for viruses by AVG.