Well reasoned!
On Fri, Jun 9, 2017 at 4:56 PM, Benjamin Peterson
wrote:
> 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 general
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 ch
On 6/9/2017 12:40 PM, Zachary Ware wrote:
PR 1783 (https://github.com/python/cpython/pull/1783); needs another
review from Steve to make sure I haven't made a complete mess of
things, then it should be ready to go. Anyone else on Windows (Terry
Reedy?) who can test it and provide feedback, plea
> On Jun 9, 2017, at 3:41 PM, Steve Dower wrote:
>
> On 09Jun2017 1118, Donald Stufft wrote:
>> A ensuressl style module that tries to install an OpenSSL module is actually
>> fairly hard to do securely. The fundamental issue being that fetching a file
>> securely from the network before you h
> On 9 Jun 2017, at 20:41, Steve Dower wrote:
>
> These are totally fine for implementing a requests-like API that relies on
> system configuration for HTTPS connections. They are not sufficient for
> building a server, but they should be sufficient for downloading the packages
> you need to
On 09Jun2017 1118, Donald Stufft wrote:
A ensuressl style module that tries to install an OpenSSL module is
actually fairly hard to do securely. The fundamental issue being that
fetching a file securely from the network before you have the primary
tool for fetching things securely from a networ
> I have a core file (produced via the gcore command) of a linux python2.6
> process. I need to extract the byte code and de-compile it.
Following on Steve's comment, you might want to take a look at
Misc/gdbinit for some GDB command inspiration. You are correct, you
won't have a running process
On Jun 09, 2017, at 08:43 PM, Nick Coghlan wrote:
>So honestly, I'd be +1 for either approach:
>
>- stdlib backport to make dual-stack maintenance easier for the
>current volunteers, and we'll see how things work out on the
>ease-of-adoption front
As I've said, I'm okay with this approach as long
> On Jun 9, 2017, at 1:07 PM, Steve Dower wrote:
>
> On 09Jun2017 0343, Nick Coghlan wrote:
>> So honestly, I'd be +1 for either approach:
>> - stdlib backport to make dual-stack maintenance easier for the
>> current volunteers, and we'll see how things work out on the
>> ease-of-adoption front
On 09Jun2017 0343, Nick Coghlan wrote:
So honestly, I'd be +1 for either approach:
- stdlib backport to make dual-stack maintenance easier for the
current volunteers, and we'll see how things work out on the
ease-of-adoption front
- PyPI backport to make 2.7 adoption easier, and we'll continue
p
On Fri, Jun 9, 2017 at 11:03 AM, Ned Deily wrote:
> On Jun 9, 2017, at 08:43, Victor Stinner wrote:
>> I expect that all Linux distributions build Python using
>> --with-system-expat. It may become the default? What about macOS and
>> other operating systems?
>
> The current default is --with-sys
> On Jun 9, 2017, at 6:43 AM, Nick Coghlan wrote:
>
> OTOH, if the aim is to make the change now, so it gets into Ubuntu
> 18.04, with a view to projects only starting to fully rely on it in
> mid-to-late 2018 or so? That timeline might actually work, and this
> approach has the benefit of actua
ACTIVITY SUMMARY (2017-06-02 - 2017-06-09)
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:
open6035 (+10)
closed 36335 (+51)
total 42370 (+61)
Open issues wit
On Jun 9, 2017, at 08:43, Victor Stinner wrote:
> Python embeds a copy of the expat library which already got two major
> security vulnerabilities:
>
> "CVE-2016-0718: expat bug #537"
> http://python-security.readthedocs.io/vuln/cve-2016-0718_expat_bug_537.html
>
> "Issue #26556: Expat 2.1.1"
>
Also a good summary for those of us that *did* attend! Thanks Jake from all
participants.
(And Nick, I hope you won't make a habit of skipping the summit. :-)
On Fri, Jun 9, 2017 at 3:10 AM, Nick Coghlan wrote:
> On 9 June 2017 at 01:52, Jake Edge wrote:
> >
> > Hola python-dev,
> >
> > I (fin
Hi,
Python embeds a copy of the expat library which already got two major
security vulnerabilities:
"CVE-2016-0718: expat bug #537"
http://python-security.readthedocs.io/vuln/cve-2016-0718_expat_bug_537.html
"Issue #26556: Expat 2.1.1"
http://python-security.readthedocs.io/vuln/issue_26556_expat
Oh, about very annoying 3.6 bug, there was a regression caused by
FASTCALL optimizations. It's now fixed in the 3.6 branch:
https://github.com/python/cpython/commit/f0ff849adc6b4a01f9d1f08d9ad0f1511ff84541
Victor
2017-06-09 5:34 GMT+02:00 Ned Deily :
> We are approaching the end of the second c
On 9 June 2017 at 05:51, Donald Stufft wrote:
> And the downside here is pretty small honestly?
Unfortunately, one of the downsides is "Doesn't provide any clearly
compelling benefits to users of LTS distributions, so even those of us
in a position to advocate for such backports probably won't wi
On 9 June 2017 at 01:52, Jake Edge wrote:
>
> 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
19 matches
Mail list logo