Hello, I would like to propose an idea for the language but I don't know where I can talk about it.
In a nutshell, I would like to be able to write:
y = (b+2 for b = a + 1)
Or in list comprehension:
Y = [b+2 for a in L for b = a+1]
Which can already be done like this:
Y = [b+2 for a in L for b in [a+1]]
Which is less obvious, has a small overhead (iterating over a list) and get messy with multiple assignment:
Y = [b+c+2 for a in L for b,c in [(a+1,a+2)]]
New syntax would allow to write:
Y = [b+c+2 for a in L for b,c = (a+1,a+2)]
The parenthesis are needed for syntax reason I think.
One could have successive assignements
My first example (b+2 for b = a+1) can already be done using ugly syntax using lambda
y = (lambda b: b+2)(b=a+1)
y = (lambda b: b+2)(a+1)
y = (lambda b=a+1: b+2)()
Choice of syntax: for is good because it uses current keyword, and the analogy for x = 5 vs for x in  is natural.
But the "for" loses the meaning of iteration.
The use of "with" would maybe sound more logical.
Python already have the "functional if", lambdas, list comprehension, but not simple assignment functional style.
I would like to change struct.Struct.format type from bytes to str. I
don't expect that anyone uses this attribute, and struct.Struct()
constructor accepts both bytes and str.
It's just to be convenient: more functions accept str than bytes in
Python 3. Example: print() (python3 -bb raises an exceptions if you
pass bytes to print).
Is anything opposed to breaking the backward compatibility?
We are approaching the end of the second calendar quarter of 2017 and, according to PEP 494, it's time to start producing the second maintenance release for the 3.6 series. The schedule calls for the release candidate to be produced on Monday 2017-06-12 UTC. As was the case with previous 3.6.x releases, the plan is for the release candidate to be the same as the final release, that is, no additional changes go in after the release candidate except for any showstopper critical problems that might be discovered with rc1. So please plan to get any security fixes, bug fixes, and documentation changes you think should be in 3.6.2 merged in ASAP. The 3.6.2 final is planned for two weeks following rc1, that is, on 2017-06-26. The next 3.6 maintenance release (3.6.3) is planned to follow about 3 months later, so most likely in 2017-09.
A reminder that the 3.6 branch will remain open for checkins throughout the 3.6.2rc and final cycle. Once 3.6.2rc1 is tagged, new commits to the 3.6 branch will release with 3.6.3. As always, if you find any problem in 3.6.2rc1 that you may believe should be corrected in 3.6.2, please ensure the problem is documented in a new or existing open issue on bugs.python.org, ensure that the Priority field of the issue is set to "release blocker", and that "Python 3.6" is included in the selected Versions. Comments or tags on github Pull Requests are NOT sufficient!
Thanks again for all of your efforts in bringing 3.6 into the world and for helping now to make it even better!
nad(a)python.org -- 
(Due to idle-dev mailing list low traffic, this mail was sent to
python-dev and idle-dev)
I'm now trying to figure out IDLE internal relation.
I got some module dependency graph and count.
The work is at HackMD:
Is there any previous material on this topic?
There is an idiomatic Python code:
If an error is raised when execute do_something_other(), then we should
first restore the state that was before calling do_something(), and then
reraise the exception. It is important that the bare "except" (or
"except BaseException") is used, because undo_something() should be
executed on any exception. And this is one of few cases where using the
bare "except" is correct.
But if an error is raised when execute undo_something(), it replaces the
original exception which become chaining as the __context__ attribute.
The problem is that this can change the type of the exception. If
do_something_other() raises SystemExit and undo_something() raises
KeyError, the final exception has type KeyError.
Yury in the comment for PR 2108  suggested more complicated code:
except BaseException as ex:
Does it mean that we should rewrite every chunk of code similar to the
above? And if such cumbersome code is necessary and become common, maybe
it needs syntax support in the language? Or changing the semantic of
exceptions raised in error handlers and finally blocks?
The reason we're having this conversation at all is probably a matter of
timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it
surely would have come along for the ride to 2.7. I believe PEP 466 is
generally considered to have produced positive results. PEP 546,
carrying no breaking changes, is less risky than PEP 466.
The reluctance to bend 2.7 rules is healthy. This PEP is part of the
price we pay, though, for making a backwards-incompatible release. The
security landscape has and will change over the 10+ python-dev-supported
life span of 2.7. During that time, we have an obligation to keep Python
2 secure. Part of that is supporting modern security interfaces, which
are features. This change is needed to make another stdlib feature,
ensurepip (which is itself yet another 2.7.x backport) work well.
Therefore, as 2.7 release manager, I'm accepting the PEP.
I wrote a PEP based on the previous thread "Backport ssl.MemoryBIO on
Python 2.7?". Thanks for Cory Benfield, Alex Gaynor and Nick Coghlan
who helped me to write it!
Inline verison below.
Title: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
Author: Victor Stinner <victor.stinner(a)gmail.com>,
Type: Standards Track
Backport the ssl.MemoryBIO and ssl.SSLObject classes from Python 3 to Python
2.7 to enhance the overall security of Python 2.7.
While Python 2.7 is getting closer to its end-of-support date (scheduled for
2020), it is still used on production systems and the Python community is still
responsible for its security. This PEP will help facilitate the future adoption
of :pep:`543` across all supported Python versions, which will improve security
for both Python 2 and Python 3 users.
This PEP does NOT propose a general exception for backporting new
features to Python 2.7 - every new feature proposed for backporting will
still need to be justified independently. In particular, it will need to
be explained why relying on an independently updated backport on the
Python Package Index instead is not an acceptable solution.
:pep:`543` defines a new TLS API for Python which would enhance Python
security by giving Python applications access to the native TLS implementations
on Windows and macOS, instead of using OpenSSL. A side effect is that it gives
access to the system trust store and certificates installed
locally by system administrators, enabling Python applications to use "company
certificates" without having to modify each application and so to correctly
validate TLS certificates (instead of having to ignore or bypass TLS
For practical reasons, Cory Benfield would like to first implement an
I/O-less class similar to ssl.MemoryBIO and ssl.SSLObject for
:pep:`543`, and to provide a second class based on the first one to use
sockets or file descriptors. This design would help to structure the code
to support more backends and simplify testing and auditing, as well as
implementation. Later, optimized classes using directly sockets or file
descriptors may be added for performance.
While :pep:`543` defines an API, the PEP would only make sense if it
comes with at least one complete and good implementation. The first
implementation would ideally be based on the ``ssl`` module of the Python
standard library, as this is shipped to all users by default and can be used as
a fallback implementation in the absence of anything more targetted.
If this backport is not performed, the only baseline implementation that could
be used would be pyOpenSSL. This is problematic, however, because of the
interaction with pip, which is shipped with CPython on all supported versions.
requests, pip and ensurepip
There are plans afoot to look at moving Requests to a more event-loop-y
model, and doing so basically mandates a MemoryBIO. In the absence of a
Python 2.7 backport, Requests is required to basically use the same
solution that Twisted currently does: namely, a mandatory dependency on
The `pip <https://pip.pypa.io/>`_ program has to embed all its
dependencies for practical reasons: namely, that it cannot rely on any other
installation method being present. Since pip depends on requests, it means
that it would have to embed a copy of pyOpenSSL. That would imply substantial
usability pain to install pip. Currently, pip doesn't support embedding
C extensions which must be compiled on each platform and so require a C
Since Python 2.7.9, Python embeds a copy of pip both for default
installation and for use in virtual environments via the new ``ensurepip``
module. If pip ends up bundling PyOpenSSL, then CPython will end up
bundling PyOpenSSL. Only backporting ``ssl.MemoryBIO`` and
``ssl.SSLObject`` would avoid the need to embed pyOpenSSL, and would fix the
bootstrap issue (python -> ensurepip -> pip -> requests -> MemoryBIO).
Add ``MemoryBIO`` and ``SSLObject`` classes to the ``ssl`` module of
The code will be backported and adapted from the master branch
The backport also significantly reduced the size of the Python 2/Python
3 difference of the ``_ssl`` module, which make maintenance easier.
* `[backport] ssl.MemoryBIO
<https://bugs.python.org/issue22559>`_: Implementation of this PEP
written by Alex Gaynor (first version written at October 2014)
* `[Python-Dev] Backport ssl.MemoryBIO on Python 2.7?
This document has been placed in the public domain.