The documentation at
contains the sentence
For example, if your_integer_time_func() returns times measured in
thousands of seconds, you would construct the Profile instance as follows:
"thousands of seconds" should ISTM be "thousandths of a second".
There is essentially the same thing in the Python 2 docs at
For example, if the timer returns times measured in _thousands_ of
seconds, the time unit would be |.001|.
Just trying for perfection!
I dislike having to do that, but I had to make a last minute change in
my PEP 587 "Python Initialization Configuration" to allow to modify
the structure in the future without breaking the backward
compatibility. I added a "struct_size" field to PyPreConfig and
PyStatus status = PyConfig_InitPythonConfig(&config);
must now be written:
config.struct_size = sizeof(PyConfig);
PyStatus status = PyConfig_InitPythonConfig(&config);
At the beginning, I used a private "_config_version" field which was
initialized statically by a macro. But it was decided to replace
macros with functions. I only noticed today that the conversion to
function broke the API/ABI future compatibility.
PyConfig_InitPythonConfig() got uninitialized memory and didn't know
the size of the config variable.
With my change, the function now requires the "struct_size" field to
be set, and so it can support internally different versions of the
Storing the structure size directly in the structure is a common
practice in the Windows API which is a good example of long term ABI
By the way, last week, Pablo Galindo Salgado reported to me a
regression in PyInstaller caused by the implementation of my PEP.
I fixed different issues related to the "Path Configuration" (sys.path
in short), but I also added a lot of tests for this code. Previously,
there was simply no test on the path configuration!
I added a lot of comments to the C code, and I completed the public
Please test the incoming Python 3.8.0rc1 release with your project if
you embed Python into your application. Please test also projects like
PyInstaller, PyOxidizer, etc.
Note: PyInstaller requires my fix for 3.8 (not merged yet):
Night gathers, and now my watch begins. It shall not end until my death.
amazing job on getting us back on track over the weekend.
All release blockers and deferred release blockers solved. And there was relatively little additional activity on the branch -- as expected at this point! Thank you for this, it will help get the release candidate out on time.
I'm working on cutting RC1 today
Hopefully all sanity checks, as well as building the source tarball and the binary installers for macOS and Windows will all work out fine and we'll be seeing RC1 out tonight.
RC2 and the date of 3.8.0 gold
If we manage to avoid the need for RC2, we will be able to release 3.8.0 on October 14th. If we need an RC2, that will slip by a week. I hope we won't. Ideally RC1 should be identical codewise to 3.8.0.
To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who introduced a last minute regression in a major release.)
Note I didn't say I forbid any activity. I have no power over you, actually. More importantly though, I trust your judgement if you assess some bug is bad enough the fix absolutely has to get into 3.8.0. Moreover, I specifically said source-related activity because...
3.8.0 is important. To some users it will be the first and the last release in the 3.8 series they will see.
We need you to focus on the docs now
Are all your changes properly documented?
Did you notice other changes you know of to have insufficient documentation?
Can you help with the "What's New" document?
anxiously configure-&&-makingly y'rs
[this is being emailed out to python-committer and python-dev separately,
so apologies for those who get a duplicate email]
The steering council wanted to let everyone know that the PSF released a
new Code of Conduct which was announced at
and that it applies to Python's development.
Specifically, this new Code of Conduct lists Python's development spaces
and those participating in those spaces as being under the CoC (we were
implicitly under the old CoC on PSF-sponsored and run infrastructure, but
now it's explicitly called out). So that means python-committers,
python-dev, python-ideas, everything on GitHub, discuss.python.org, core
dev sprints, PSF-sponsored conferences, etc. all fall under this CoC. The
steering council wanted to make sure people were aware of this new Code of
Conduct so no one was caught off-guard and to make sure people were aware
that it did apply to all of us. The steering council also supports this
Code of Conduct.
One other thing the steering council wanted to point out is that we believe
CoC violations should be reported directly to the Conduct WG as outlined at
https://www.python.org/psf/conduct/reporting/. The thinking is that since
we all know each other on the development team there's a good chance of a
conflict of interest if reports were to go to the steering council, and so
it's simpler to just advise people go straight to the Conduct WG (Carol and
I will recuse ourselves as appropriate since we are both on the Conduct WG).
I will also say that people have come to me personally in the past and
asked if something was a CoC violation, and going forward my answer will be
"report it to the Conduct WG and let them make that decision". Same goes
for incidents where people believe something is a CoC violation and they
want to report it to someone: let the Conduct WG know (which I have already
started telling people who come to me with CoC concerns).
Python 3.7.5rc1 is now available for testing. 3.7.5rc1 is the release preview of the next maintenance release of Python 3.7, the latest feature release of Python. Assuming no critical problems are found prior to 2019-10-14, no code changes are planned between now and the final release. This release candidate is intended to give you the opportunity to test the new security and bug fixes in 3.7.5. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that this is a preview release and, thus, its use is not recommended for production environments.
You can find the release files, a link to the changelog, and more information here:
nad(a)python.org -- 
Steve Dower and I have put together a proposal to try to reduce
feature delivery latency by changing our pre-release management
process such that beta releases are considered production ready.
The preferred discussion thread for that PEP is on Discourse here:
(Note: there are already some updates pending based on the initial
feedback in the thread, so folks may want to skim the thread before
reading the full PEP)
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia