Python 3.7.1rc2 and 3.6.7rc2 are now available. 3.7.1rc2 is a release
preview of the first maintenance release of Python 3.7, the latest
feature release of Python. 3.6.7rc2 is a release preview of the next
maintenance release of Python 3.6, the previous feature release of
Python. Assuming no further critical problems are found prior to
2018-10-20, no code changes are planned between these release
candidates and the final releases. These release candidates are
intended to give you the opportunity to test the new security and bug
fixes in 3.7.1 and 3.6.7. 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 these are preview releases and,
thus, their use is not recommended for production environments.
You can find these releases and more information here:
nad(a)python.org -- 
On 10/12/2018 5:17 AM, Tal Einat wrote:
> The latest stable releases can always be found on the `Python download page
> -<https://www.python.org/downloads/>`_. There are two recommended production-ready
> -versions at this point in time, because at the moment there are two branches of
> -stable releases: 2.x and 3.x. Python 3.x may be less useful than 2.x, since
> -currently there is more third party software available for Python 2 than for
> -Python 3. Python 2 code will generally not run unchanged in Python 3.
> +<https://www.python.org/downloads/>`_. There are two production-ready version
> +of Python: 2.x and 3.x, but the recommended one at this times is Python 3.x.
This should be "time", not "times". I'd fix it, but I'm unsure if this
is being backported or not, and I don't want to mess up any merges
before they're done.
I do think this should backported to 3.7, 3.6, and 2.7.
> +Although Python 2.x is still widely used, `it will not be
> +maintained after January 1, 2020 <https://www.python.org/dev/peps/pep-0373/>`_.
> +Python 2.x was known for having more third-party libraries available, however,
> +by the time of this writing, most of the widely used libraries support Python 3.x,
Should probably be "at the time of this writing".
> +and some are even dropping the Python 2.x support.
And this would read better as "are even dropping support for Python 2.x".
We ran into an issue on the Anaconda Distribution recently where we
added libarchive-c to conda-build (so we can un-compress more source
archive formats than tarfile supports) and everything was good a few
hours, until it hit various CI systems where objdump is not installed.
I was a bit surprised by this dependency and wondered if there'd be
interest in a fallback path that inspects the elf with some fairly
simple python code to determine the soname instead? I have code that
works already - though it could do with and a tidy up - and has been
tested on a variety of architectures. Would CPython be interested in
an attempt to upstream this?
Is it documented anywhere that objdump is needed to load some
extension modules on Linux?
On Twitter, Raymond Hettinger wrote:
"The decision making process on Python-dev is an anti-pattern,
governed by anecdotal data and ambiguity over what problem is solved."
About "anecdotal data", I would like to discuss the Python startup time.
== Python 3.7 compared to 2.7 ==
First of all, on speed.python.org, we have:
* Python 2.7: 6.4 ms with site, 3.0 ms without site (-S)
* master (3.7): 14.5 ms with site, 8.4 ms without site (-S)
Python 3.7 startup time is 2.3x slower with site (default mode), or
2.8x slower without site (-S command line option).
(I will skip Python 3.4, 3.5 and 3.6 which are much worse than Python 3.7...)
So if an user complained about Python 2.7 startup time: be prepared
for a 2x - 3x more angry user when "forced" to upgrade to Python 3!
== Mercurial vs Git, Python vs C, startup time ==
Startup time matters a lot for Mercurial since Mercurial is compared
to Git. Git and Mercurial have similar features, but Git is written in
C whereas Mercurial is written in Python. Quick benchmark on the
* hg version: 44.6 ms +- 0.2 ms
* git --version: 974 us +- 7 us
Mercurial startup time is already 45.8x slower than Git whereas tested
Mercurial runs on Python 2.7.12. Now try to sell Python 3 to Mercurial
developers, with a startup time 2x - 3x slower...
I tested Mecurial 3.7.3 and Git 2.7.4 on Ubuntu 16.04.1 using "python3
-m perf command -- ...".
== CPython core developers don't care? no, they do care ==
Christian Heimes, Naoki INADA, Serhiy Storchaka, Yury Selivanov, me
(Victor Stinner) and other core developers made multiple changes last
years to reduce the number of imports at startup, optimize impotlib,
IHMO all these core developers are well aware of the competition of
programming languages, and honesty Python startup time isn't "good".
So let's compare it to other programming languages similar to Python.
== PHP, Ruby, Perl ==
I measured the startup time of other programming languages which are
similar to Python, still on the speed.python.org server using "python3
-m perf command -- ...":
* perl -e ' ': 1.18 ms +- 0.01 ms
* php -r ' ': 8.57 ms +- 0.05 ms
* ruby -e ' ': 32.8 ms +- 0.1 ms
Wow, Perl is quite good! PHP seems as good as Python 2 (but Python 3
is worse). Ruby startup time seems less optimized than other
* perl 5, version 22, subversion 1 (v5.22.1)
* PHP 7.0.18-0ubuntu0.16.04.1 (cli) ( NTS )
* ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]
== Quick Google search ==
I also searched for "python startup time" and "python slow startup
time" on Google and found many articles. Some examples:
"Reducing the Python startup time"
=> "The python startup time always nagged me (17-30ms) and I just
searched again for a way to reduce it, when I found this: The
Python-Launcher caches GTK imports and forks new processes to reduce
the startup time of python GUI programs."
=> "Wow, Python startup time is worse than I thought."
"How to speed up python starting up and/or reduce file search while
=> "The first time I log to the system and start one command it takes
6 seconds just to show a few line of help. If I immediately issue the
same command again it takes 0.1s. After a couple of minutes it gets
back to 6s. (proof of short-lived cache)"
"How does one optimise the startup of a Python script/program?"
=> "I wrote a Python program that would be used very often (imagine
'cd' or 'ls') for very short runtimes, how would I make it start up as
fast as possible?"
"Python Interpreter Startup time"
"Python is very slow to start on Windows 7"
=> "Python takes 17 times longer to load on my Windows 7 machine than
Ubuntu 14.04 running on a VM"
=> "returns in 0.614s on Windows and 0.036s on Linux"
"How to make a fast command line tool in Python" (old article Python 2.5.2)
=> "(...) some techniques Bazaar uses to start quickly, such as lazy imports."
So please continue efforts for make Python startup even faster to beat
all other programming languages, and finally convince Mercurial to
[duplicated from https://discuss.python.org/c/committers]
We issued the 3.7.1rc1 and 3.6.7rc1 release candidates a little over 11 days ago with the plan to have final releases for each available by today, assuming no new issues arose since the rc1 cutoffs. While the good news is that, to the best of my knowledge, no regressions have been reported for the release candidates (or remain unfixed), several critical and security-related issues have identified during the rc phase. Most of these have already been addressed (thanks for the quick responses!) but there remain a couple that still need to be finalized. Since there is a non-zero amount of fixes going in after rc1, I think we need to do another set of release candidates once everything is resolved. Because a number of core developers are right now attending various Python-related events, I am going to aim for tagging 3.7.1rc2 and 3.6.7rc2 after 2018-10-09 23:59 AoE, if at all possible, with final releases targeted for about 10 days later. I will send out an update as we approach that time.
Just a reminder to core developers: as always please try to get fixes merged in to all relevant branches as soon as you feel they are ready. There is no need to hold off during a release candidate phase. Release managers will cherry pick as necessary appropriate fixes from the release branches into subsequent release candidates or final releases. The sooner changes are merged, the sooner they will get buildbot exposure and potential exposure in the wider community.
nad(a)python.org -- 
On 2018-10-03 17:06, Łukasz Langa wrote:
> That's the only
> reason why PEP 544 is not yet accepted for example.
Did you actually try to get PEP 544 accepted or to appoint a
BDFL-Delegate? I don't find any discussions about PEP 544 after the
stepping down of the BDFL.
On the bug tracker, there's a discussion about the current behaviour of
the assert statement, where shadowing AssertionError will change the
behaviour of the assertion.
Currently, assert does a LOAD_GLOBAL on AssertionError, which means if
you shadow the name, you get a different exception. This behaviour goes
back to Python 1.5.
I'm looking for guidance here, is this the intended behaviour, or an
accident? Should it be changed to better match other builtins?
(For example, shadowing iter doesn't effect for loops.)
On 10/5/18, 10:33 AM, "Python-Dev on behalf of Michael Haubenwallner" <python-dev-bounces+robb=datalogics.com(a)python.org on behalf of michael.haubenwallner(a)ssi-schaefer.com> wrote:
>... I build everything myself, using xlc
>(gcc introduces the need for a GNU RTE, e.g., glibc).
Using gcc does *not* require to use glibc or even GNU binutils at all.
Except for gcc's own runtime libraries, there's no need for a GNU RTE.
In fact, in Gentoo Prefix I do use gcc as the compiler, configured to
use AIX provided binutils (as, ld, nm, ...), with AIX libc as RTE.
I think the author was referring to the dependency on libgcc_s when using gcc.
It's typical for native UNIX package builders to use gcc only when necessary because the correct runtime is always installed (if the os running it is newer) and therefore won't clash when something else in the process space is using a different version of libgcc_s (I'm not sure what the ABI guarantees are with libgcc_s specifically, and neither are UNIX packagers - not necessarily anyway)
It also eliminates the need to ship a version of libgcc_s as a shared library.
In the buildbots AIX is marked as "unstable"? What is needed to get it
marked as a "stable" platform - that being one of my short-term goals.
My assumption is that it needs to (at least) pass all tests - and that
is why I keep asking for attention. All the PRs to fix individual tests
mean less if they are not merged, for whatever reason.
However, maybe there is another way, or even something additional
needed. Maybe something I cannot provide and then I can adjust my
expectations and goals.