[Python-Dev] IMPORTANT: Python 3.6.2 Maintenance Release Release Candidate in 3+ days (Monday 2017-06-12 12:00 UTC)

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

Re: [Python-Dev] Extracting python bytecode from a linux core dump?

I can’t help with the gdb commands, but I’d suggest you want to start from one of the global variables for the sys module, probably the modules dict. You’ll have to reverse engineer the memory structures to find its values and each of their dicts, eventually finding function objects pointing to

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On 8 Jun 2017, at 21:17, Donald Stufft wrote: > >> >> On Jun 8, 2017, at 3:57 PM, Steve Dower > > wrote: >> >> Awesome, this is exactly what I needed to see. >> >> What if Python 2.7 just exposed the OpenSSL

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 8, 2017, at 3:57 PM, Steve Dower wrote: > > On 08Jun2017 1237, Donald Stufft wrote: >> The basic yak stak here is: >> * PEP 543 should be the future, it is a much much better way of handling TLS >> than our current ssl module is. >> * Cory can’t spend his work

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On 08Jun2017 1237, Donald Stufft wrote: The basic yak stak here is: * PEP 543 should be the future, it is a much much better way of handling TLS than our current ssl module is. * Cory can’t spend his work time on PEP 543 unless he can say it is useful for requests. * In order for PEP 543 to

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 8, 2017, at 3:37 PM, Donald Stufft wrote: > > So basically back porting MemoryBio unlocks two important things for the > health of the Python ecosystem: > > * Allows forward progress on PEP 543, which provides a wealth of great > benefits like using the platform

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 8, 2017, at 12:40 PM, Steve Dower wrote: > > I'm just going to straight up admit that I've lost track of the point of this > thread. > > It sounds like we don't *need* to backport any of ssl into the Python 2.7 > standard library, as long as we can bundle a

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On 8 June 2017 at 17:40, Steve Dower wrote: > I'm just going to straight up admit that I've lost track of the point of > this thread. You have my sympathies - I'm not really following it either :-( > It sounds like we don't *need* to backport any of ssl into the Python

Re: [Python-Dev] Support for RFC 6920: Naming Things with Hashes?

On 8 June 2017 at 12:37, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Sylvain Bellemare writes: > > Hi, > > > > I hope this is the right place to post this kind of question. If not I > > apologize. > > > > I was simply wondering if anyone had been looking into

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

I'm just going to straight up admit that I've lost track of the point of this thread. It sounds like we don't *need* to backport any of ssl into the Python 2.7 standard library, as long as we can bundle a 3rd-party backport for pip? I assume that, at a high level, the operation needed is to

[Python-Dev] 2017 Python Language Summit coverage finale

Hola python-dev, I (finally!) finished up the coverage from the language summit ... The starting point is the overview article, here: https://lwn.net/Articles/723251/ which should now be free for anyone to see (and the first seven articles too). LWN subscribers can see the articles right away,

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On 8 June 2017 at 21:30, Victor Stinner wrote: > Maybe the intent of my PEP is unclear: the goal is not to allow > Requests to require MemoryBIO, but to get a wide adoption of a future > implementation of the new TLS API (PEP). IMHO having an implementation > working on

[Python-Dev] Buildbot report, june 2017

Hi, With the help of Zachary Ware, we succeed to set up a mailing list getting email notifications when a buildbot fails whereas it previously succeeded (green/success or orange/warnings): https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/ Please subscribe if you want to stay

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Thu, 8 Jun 2017 09:30:37 +0100 Cory Benfield wrote: > > Ah, yes, we do. In our defense, this is the semantic of the listen > syscall,[...] According to POSIX, the backlog is only a hint, i.e. Jython is probably ok in not observing its value: """The backlog argument

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

Maybe the intent of my PEP is unclear: the goal is not to allow Requests to require MemoryBIO, but to get a wide adoption of a future implementation of the new TLS API (PEP). IMHO having an implementation working on the latest Python 2.7 version should make it possible to use it on some kinds of

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 8, 2017, at 6:36 AM, Victor Stinner wrote: > > 2017-06-08 10:30 GMT+02:00 Cory Benfield : >> This is what I was worried about. Moving to require PyOpenSSL *also* locks >> us out of Jython support, at least for the time being. That’s another

[Python-Dev] Support for RFC 6920: Naming Things with Hashes?

Sylvain Bellemare writes: > Hi, > > I hope this is the right place to post this kind of question. If not I > apologize. > > I was simply wondering if anyone had been looking into supporting RFC 6920 ( > https://tools.ietf.org/html/rfc6920). > > For a simple example of what this is

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On 7 Jun 2017, at 20:06, Jim Baker wrote: > > Sorry, I wish this were true, but PyOpenSSL is not available on Jython, > because we do not yet support CFFI for Jython. CFFI support is something we > have looked at, but we have not implemented. (There is a related and