Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches
2016-01-21 19:42 GMT+01:00 Paul Moore : > Minor nit, the status column says "end of life", but the text below > the table uses the term "end of line" Ooops, it's a funny typo. Fixed. Thanks for the report! Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches
2016-01-21 18:18 GMT+01:00 Brett Cannon : > It's live: https://docs.python.org/devguide/#status-of-python-branches There is a very strange bug in this website. This URL shows the table: https://docs.python.org/devguide/ This URL doesn't show the table: https://docs.python.org/devguide/index.html Outdated version of the guide? This bug can be seen without a browser, using wget: $ wget -O- https://docs.python.org/devguide/ 2>&1|grep 'Python branches' Status of Python branches<(...) Status of Python branches $ wget -O- https://docs.python.org/devguide/index.html 2>&1|grep 'Python branches' Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Devguide: Add a table summarizing status of Python branches
On Fri, Jan 22, 2016 at 6:03 PM, Victor Stinner wrote: > 2016-01-21 18:18 GMT+01:00 Brett Cannon : >> It's live: https://docs.python.org/devguide/#status-of-python-branches > > There is a very strange bug in this website. > > This URL shows the table: > https://docs.python.org/devguide/ > > This URL doesn't show the table: > https://docs.python.org/devguide/index.html > > Outdated version of the guide? It looks like a cache issue. I purged the cache for /devguide/index.html: $ wget -O- https://docs.python.org/devguide/index.html 2>&1 | grep "Python branches" Status of Python branches¶ Status of Python branches --Berker ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2016-01-15 - 2016-01-22) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5354 (-33) closed 32585 (+89) total 37939 (+56) Open issues with patches: 2348 Issues opened (31) == #25791: Raise an ImportWarning when __spec__.parent/__package__ isn't http://bugs.python.org/issue25791 reopened by brett.cannon #26128: Let the subprocess.STARTUPINFO constructor take arguments http://bugs.python.org/issue26128 opened by cool-RR #26130: redundant local copy of a char pointer in classify in Parser\p http://bugs.python.org/issue26130 opened by Oren Milman #26131: Raise ImportWarning when loader.load_module() is used http://bugs.python.org/issue26131 opened by brett.cannon #26132: 2.7.11 Windows Installer issues on Win2008R2 http://bugs.python.org/issue26132 opened by David Rader #26133: asyncio: ugly error related to signal handlers at exit if the http://bugs.python.org/issue26133 opened by Alex Brandt #26134: HTTPPasswordMgrWithPriorAuth does not work with DigestAuthenti http://bugs.python.org/issue26134 opened by guesommer #26136: DeprecationWarning for PEP 479 (generator_stop) http://bugs.python.org/issue26136 opened by martin.panter #26137: [idea] use the Microsoft Antimalware Scan Interface http://bugs.python.org/issue26137 opened by Alexander Riccio #26140: inspect.iscoroutinefunction raises TypeError when checks Mock http://bugs.python.org/issue26140 opened by miyakogi #26141: typing module documentation incomplete http://bugs.python.org/issue26141 opened by Ben.Darnell #26143: Ensure that IDLE's stdlib imports are from the stdlib http://bugs.python.org/issue26143 opened by terry.reedy #26144: test_pkg test_4 and/or test_7 sometimes fail http://bugs.python.org/issue26144 opened by martin.panter #26145: PEP 511: Add sys.set_code_transformers() http://bugs.python.org/issue26145 opened by haypo #26146: PEP 511: Add ast.Constant to allow AST optimizer to emit const http://bugs.python.org/issue26146 opened by haypo #26148: String literals are not interned if in a tuple http://bugs.python.org/issue26148 opened by serhiy.storchaka #26149: Suggest PyCharm Community as an editor for Unix platforms http://bugs.python.org/issue26149 opened by John Hagen #26152: A non-breaking space in a source http://bugs.python.org/issue26152 opened by Drekin #26153: PyImport_GetModuleDict: no module dictionary! when `__del__` t http://bugs.python.org/issue26153 opened by minrk #26155: 3.5.1 installer issue on Win 7 32 bit http://bugs.python.org/issue26155 opened by TarotRedhand #26158: File truncate() not defaulting to current position as document http://bugs.python.org/issue26158 opened by fornax #26159: Unsafe to BaseEventLoop.set_debug(False) when PYTHONASYNCIODEB http://bugs.python.org/issue26159 opened by Bradley McLean #26160: Tutorial incorrectly claims that (explicit) relative imports d http://bugs.python.org/issue26160 opened by Kevin.Norris #26167: Improve copy.copy speed for built-in types (list/set/dict) http://bugs.python.org/issue26167 opened by josh.r #26168: Py_BuildValue may leak 'N' arguments on PyTuple_New failure http://bugs.python.org/issue26168 opened by squidevil #26173: test_ssl.bad_cert_test() exception handling http://bugs.python.org/issue26173 opened by martin.panter #26175: Fully implement IOBase abstract on SpooledTemporaryFile http://bugs.python.org/issue26175 opened by Gary Fernie #26176: EmailMessage example doesn't work http://bugs.python.org/issue26176 opened by Srujan Chaitanya #26177: tkinter: Canvas().keys returns empty strings. http://bugs.python.org/issue26177 opened by terry.reedy #26180: multiprocessing.util._afterfork_registry leak in threaded envi http://bugs.python.org/issue26180 opened by mzamazal #26181: argparse can't handle positional argument after list (help mes http://bugs.python.org/issue26181 opened by atpage Most recent 15 issues with no replies (15) == #26181: argparse can't handle positional argument after list (help mes http://bugs.python.org/issue26181 #26180: multiprocessing.util._afterfork_registry leak in threaded envi http://bugs.python.org/issue26180 #26176: EmailMessage example doesn't work http://bugs.python.org/issue26176 #26173: test_ssl.bad_cert_test() exception handling http://bugs.python.org/issue26173 #26168: Py_BuildValue may leak 'N' arguments on PyTuple_New failure http://bugs.python.org/issue26168 #26159: Unsafe to BaseEventLoop.set_debug(False) when PYTHONASYNCIODEB http://bugs.python.org/issue26159 #26153: PyImport_GetModuleDict: no module dictionary! when `__del__` t http://bugs.python.org/issue26153 #26141: typing module documentation incomplete http://bugs.python.org/issue26141 #26136: DeprecationWarning for PEP 479 (generator_stop) http://bugs.python.org/issue26136
[Python-Dev] python3 k1om dissociation permanence
Hello, Enabling the build system for Intel MIC k1om is non-trivial using Python-3.4.4 Using Python2 for the k1om is very popular, but I require Python3 support on k1om. The first requirement to complete this build involved the download and extraction of pre-built MPSS RPM's. Then built required host python bins using GCC. Lastly, build MIC bins using ICC. The exacts are appended to the end of this message. I would like to discuss a few change requirements that trial and error has revealed. 1.) libffi requires the University OF Cantabria patch because the k1om is not binary compatible with x86_64. [attached] These libffi changes could be implemented using the __MIC__ or __KNC__ macros. *see https://software.intel.com/en-us/node/514528 2.) ./configure script halts during failure to locate readelf for the host. I simply commented out these lines in the ./configure file: #if test "$cross_compiling" = yes; then #case "$READELF" in #readelf|:) #as_fn_error $? "readelf for the host is required for cross builds" "$LINENO" 5 #;; #esac #fi Ideally, ./configure would support ICC and k1om. Am I missing something in the configure/make commands below? Is it possible to bypass the readelf requirement when cross-compiling for k1om? Additionally, are any of the command line parameters below unnecessary? PKG_CONFIG_LIBDIR PKG_CONFIG_PATH PYTHON_FOR_BUILD _PYTHON_HOST_PLATFORM HOSTPGEN HOSTARCH BUILDARCH Thanks, Rob #copy/unpack the k1om bins tarball cd /home/ wget mpss-3.4.6-k1om.tar tar xvf mpss-3.4.6-k1om.tar cd /home/mpss-3.4.6/k1om/ for rpm in *.rpm; do rpm2cpio $rpm | cpio -idm; done #vars PythonVersion=Python-3.4.4 k1om_rpm=/home/mpss-3.4.6/k1om/ INSTALLPREFIX=/home/Python/release/$PythonVersion-mic SRC=/home/Python/$PythonVersion echo "Compiling host Python" cd $SRC && make distclean cd $SRC && ./configure cd $SRC && make python Parser/pgen rm -f $SRC/hostpython mv $SRC/python $SRC/hostpython rm -f $SRC/Parser/hostpgen mv $SRC/Parser/pgen $SRC/Parser/hostpgen cd $SRC && make distclean echo "Configuring Python for MIC..." cd $SRC && CONFIG_SITE=config.site \ ./configure \ CC="icc -mmic" \ CFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \ CXX="icpc -mmic" \ CPPFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \ PKG_CONFIG_LIBDIR="$k1om_rpm/usr/lib64/pkgconfig" \ PKG_CONFIG_PATH="$k1om_rpm/usr/lib64/pkgconfig" \ --host=x86_64-k1om-linux \ --build=x86_64-linux-gnu \ --with-cxx-main="icpc -mmic" \ --disable-ipv6 echo "done" echo "Compiling Python for MIC..." cd $SRC && make \ PYTHON_FOR_BUILD=./hostpython \ _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \ HOSTPGEN=./Parser/hostpgen \ HOSTARCH=x86_64-k1om-linux \ BUILDARCH=x86_64-linux-gnu \ EXTRA_CFLAGS="-fp-model precise -shared -fPIC" \ LDFLAGS="-L$k1om_rpm/lib64 -L$k1om_rpm/usr/lib64" echo "done" echo "Installing Python for MIC" mkdir -p $INSTALLPREFIX cd $SRC && make install \ PYTHON_FOR_BUILD=./hostpython \ _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \ prefix=$INSTALLPREFIX echo "done" 0001-k1om-libffi.patch Description: Binary data 0002-READELF.patch Description: Binary data ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python3 k1om dissociation permanence
If you could, ƦOB, can you open issues on bugs.python.org for each of these problems/changes? Otherwise we will lose track of this. On Fri, 22 Jan 2016 at 11:57 ƦOB COASTN wrote: > Hello, > > Enabling the build system for Intel MIC k1om is non-trivial using > Python-3.4.4 > Using Python2 for the k1om is very popular, but I require Python3 > support on k1om. > > The first requirement to complete this build involved the download and > extraction of pre-built MPSS RPM's. > Then built required host python bins using GCC. > Lastly, build MIC bins using ICC. > The exacts are appended to the end of this message. > > I would like to discuss a few change requirements that trial and error > has revealed. > > 1.) libffi requires the University OF Cantabria patch because the k1om > is not binary compatible with x86_64. [attached] > > These libffi changes could be implemented using the __MIC__ or __KNC__ > macros. > *see https://software.intel.com/en-us/node/514528 > > 2.) ./configure script halts during failure to locate readelf for the host. > > I simply commented out these lines in the ./configure file: > #if test "$cross_compiling" = yes; then > #case "$READELF" in > #readelf|:) > #as_fn_error $? "readelf for the host is required for cross > builds" "$LINENO" 5 > #;; > #esac > #fi > > Ideally, ./configure would support ICC and k1om. > Am I missing something in the configure/make commands below? > Is it possible to bypass the readelf requirement when cross-compiling for > k1om? > > Additionally, are any of the command line parameters below unnecessary? > PKG_CONFIG_LIBDIR > PKG_CONFIG_PATH > PYTHON_FOR_BUILD > _PYTHON_HOST_PLATFORM > HOSTPGEN > HOSTARCH > BUILDARCH > > > Thanks, > Rob > > > > > #copy/unpack the k1om bins tarball > cd /home/ > wget mpss-3.4.6-k1om.tar > tar xvf mpss-3.4.6-k1om.tar > cd /home/mpss-3.4.6/k1om/ > for rpm in *.rpm; do rpm2cpio $rpm | cpio -idm; done > > #vars > PythonVersion=Python-3.4.4 > k1om_rpm=/home/mpss-3.4.6/k1om/ > INSTALLPREFIX=/home/Python/release/$PythonVersion-mic > SRC=/home/Python/$PythonVersion > > echo "Compiling host Python" > cd $SRC && make distclean > cd $SRC && ./configure > cd $SRC && make python Parser/pgen > rm -f $SRC/hostpython > mv $SRC/python $SRC/hostpython > rm -f $SRC/Parser/hostpgen > mv $SRC/Parser/pgen $SRC/Parser/hostpgen > cd $SRC && make distclean > > echo "Configuring Python for MIC..." > cd $SRC && CONFIG_SITE=config.site \ > ./configure \ > CC="icc -mmic" \ > CFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \ > CXX="icpc -mmic" \ > CPPFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \ > PKG_CONFIG_LIBDIR="$k1om_rpm/usr/lib64/pkgconfig" \ > PKG_CONFIG_PATH="$k1om_rpm/usr/lib64/pkgconfig" \ > --host=x86_64-k1om-linux \ > --build=x86_64-linux-gnu \ > --with-cxx-main="icpc -mmic" \ > --disable-ipv6 > echo "done" > > echo "Compiling Python for MIC..." > cd $SRC && make \ > PYTHON_FOR_BUILD=./hostpython \ > _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \ > HOSTPGEN=./Parser/hostpgen \ > HOSTARCH=x86_64-k1om-linux \ > BUILDARCH=x86_64-linux-gnu \ > EXTRA_CFLAGS="-fp-model precise -shared -fPIC" \ > LDFLAGS="-L$k1om_rpm/lib64 -L$k1om_rpm/usr/lib64" > echo "done" > > echo "Installing Python for MIC" > mkdir -p $INSTALLPREFIX > cd $SRC && make install \ > PYTHON_FOR_BUILD=./hostpython \ > _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \ > prefix=$INSTALLPREFIX > echo "done" > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] do people use sys._mercurial?
Since we are going to be switching over to Git, sys._mercurial is going to
be made to return a dummy value of `('CPython', '', '')` once we switch to
Git. But my question is do we bother to replace it with sys._git? I wanted
to make sure that the effort is worth it to keep changing these
VCS-specific attributes every time we change our VCS (and no, we are not
going to adopt a generic one; already had that debate). So do please speak
up if you actually have found value from sys._mercurial.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] do people use sys._mercurial?
On 23 January 2016 at 09:44, Brett Cannon wrote:
> Since we are going to be switching over to Git, sys._mercurial is going to
> be made to return a dummy value of `('CPython', '', '')` once we switch to
> Git. But my question is do we bother to replace it with sys._git? I wanted
> to make sure that the effort is worth it to keep changing these VCS-specific
> attributes every time we change our VCS (and no, we are not going to adopt a
> generic one; already had that debate). So do please speak up if you actually
> have found value from sys._mercurial.
It's incorporated into the output of
"platform.python_(branch|revision|build)()", so I assume most people
would use those if they needed to report exact build information,
rather than accessing the attribute directly.
We also use it ourselves in printing the appropriate banner when
running an interactive prompt (note the first line of the banner):
Python 3.6.0a0 (default:32a4e7b337c9, Jan 23 2016, 12:30:00)
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys._mercurial
('CPython', 'default', '32a4e7b337c9')
And the regression test suite:
$ ./python -m test
== CPython 3.6.0a0 (default:32a4e7b337c9, Jan 23 2016, 12:30:00) [GCC
5.3.1 20151207 (Red Hat 5.3.1-2)]
== Linux-4.3.3-301.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
little-endian
== hash algorithm: siphash24 64bit
== /home/ncoghlan/devel/cpython/build/test_python_13167
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0,
optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0,
ignore_environment=0, verbose=0, bytes_warning=0, quiet=0,
hash_randomization=1, isolated=0)
[ 1/401] test_grammar
...
I guess that means "Update platform.py, and test the interactive
prompt and regression test banners still work as expected when built
from git" needs to be added to the CPython migration part of the PEP.
(In looking into this, I found several of the docstrings in
platform.py still referred to Subversion, even though the
platform._sys_version() helping had been updated to handle Mercurial)
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] do people use sys._mercurial?
On Jan 22, 2016, at 18:44, Brett Cannon wrote:
> Since we are going to be switching over to Git, sys._mercurial is going to be
> made to return a dummy value of `('CPython', '', '')` once we switch to Git.
> But my question is do we bother to replace it with sys._git? I wanted to make
> sure that the effort is worth it to keep changing these VCS-specific
> attributes every time we change our VCS (and no, we are not going to adopt a
> generic one; already had that debate). So do please speak up if you actually
> have found value from sys._mercurial.
As long as the git revision tag (if any) and hash show up in sys.version and
the interpreter interactive (REPL) mode header as they do today with hg and
previously with svn (that is, when the interpreter is built from a vcs
checkout), I'm happy:
$ python3
Python 3.5.1 (v3.5.1:37a07cee5969, Dec 5 2015, 21:12:44)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
--
Ned Deily
[email protected] -- []
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Typehinting repo moved to python/typing
This is just a note that with Benjamin's help we've moved the ambv/typehinting repo on GitHub into the python org, so its URL is now https://github.com/python/typing . This repo was used most intensely for discussions during PEP 484's drafting period. It also contains the code for typing.py, repackaged for earlier releases on PyPI. The issue tracker is still open for proposals to change PEP 484, which is not unheard of given its provisional status. If you find a pointer to the original location of this repo in a file you can update, please go ahead (though GitHub is pretty good at forwarding URLs from renamed repos). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Buildbot timing out - test suite failure - test_socket issue with UDP6?
I just had a major crash on the system that hosts the angelico-debian-amd64 buildbot, and as usual, checked it carefully after bringing everything up. It seems now to be timing out after an hour of operation: http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3132/steps/test/logs/stdio This is happening across all the 3.* branches on my buildbot, but NOT on 2.7, and not on any other buildbots. That makes it look like some kind of config problem at my end. In seeking to diagnose it, I duplicated the 3.x build directory and manually ran the commands to run a test, and it stalled out (I didn't let it go to the whole hour but it sat there for some minutes) at the same place: in test_socket. Running just that test file: $ ./python Lib/test/test_socket.py ... chomp lots of lines ... testRecvmsgPeek (__main__.RecvmsgUDP6Test) ... seems to indicate that the stall is due to IPv6 and UDP. The VM should have full IPv6 support, although my ISPs don't carry IPv6 traffic, so it won't be able to reach the internet proper; but it should be able to do all manner of local tests. The test runs just fine on my main system, so it's only failing in the buildbot VM. Any ideas as to what's going on or how to diagnose? By the way, this looks odd: make buildbottest TESTOPTS= TESTPYTHONOPTS= TESTTIMEOUT=3600 in dir /root/buildarea/3.x.angelico-debian-amd64/build (timeout 3900 secs) The parameter says 3600 (which corresponds to the error message at the end), but it echoes back that the timeout is 3900 seconds. ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot timing out - test suite failure - test_socket issue with UDP6?
On Sat, Jan 23, 2016 at 12:03 AM, Chris Angelico wrote: > By the way, this looks odd: > > make buildbottest TESTOPTS= TESTPYTHONOPTS= TESTTIMEOUT=3600 > in dir /root/buildarea/3.x.angelico-debian-amd64/build (timeout 3900 secs) > > The parameter says 3600 (which corresponds to the error message at the > end), but it echoes back that the timeout is 3900 seconds. I'm no help on the main issue, but to explain the timeout difference: TESTTIMEOUT is a makefile variable that sets the faulthandler timeout that tries to make Python bail out with a stack trace instead of letting buildbot kill Python silently. The 3900 second timeout is buildbot's "there's been no output in this long, assume it's hung and kill it" timeout. The difference between the two is to give faulthandler a chance to do its thing. -- Zach ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot timing out - test suite failure - test_socket issue with UDP6?
On Sat, Jan 23, 2016 at 5:39 PM, Zachary Ware wrote: > On Sat, Jan 23, 2016 at 12:03 AM, Chris Angelico wrote: >> By the way, this looks odd: >> >> make buildbottest TESTOPTS= TESTPYTHONOPTS= TESTTIMEOUT=3600 >> in dir /root/buildarea/3.x.angelico-debian-amd64/build (timeout 3900 secs) >> >> The parameter says 3600 (which corresponds to the error message at the >> end), but it echoes back that the timeout is 3900 seconds. > > I'm no help on the main issue, but to explain the timeout difference: > TESTTIMEOUT is a makefile variable that sets the faulthandler timeout > that tries to make Python bail out with a stack trace instead of > letting buildbot kill Python silently. The 3900 second timeout is > buildbot's "there's been no output in this long, assume it's hung and > kill it" timeout. The difference between the two is to give > faulthandler a chance to do its thing. Ah, cool. That's one mystery cleared up, at least. ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
