On 24 May 2017 at 14:27, Nathaniel Smith wrote:
> On Tue, May 23, 2017 at 8:34 PM, David Wilson wrote:
>> On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote:
>>
>>> There are discussions around Requests unvendoring its dependencies
>>> thanks to the improved nature of pip. This might b
On Tue, May 23, 2017 at 8:34 PM, David Wilson wrote:
> On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote:
>
>> There are discussions around Requests unvendoring its dependencies
>> thanks to the improved nature of pip. This might be a year of pretty
>> big changes for Requests.
>
> In
Sure, make your change and then update libffi!
Victor
Le 23 mai 2017 18:19, "Steve Dower" a écrit :
> On 23May2017 1212, Victor Stinner wrote:
>
>> 2017-05-22 13:17 GMT-05:00 Steve Dower :
>>
>>> Once the special protection is removed, most of these cases will become
>>> OSError due to the gene
Le 23 mai 2017 20:43, "David Wilson" a écrit :
In which case, what is to prevent Requests from just depending on
pyOpenSSL as usual?
>From what I heard, pyOpenSSL development is slowing down, so I'm not sure
that it's really safe and future-proof (TLS 1.3 anyone?).
I'm still writing 2.7 code e
> On 23 May 2017, at 20:34, David Wilson wrote:
>
> On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote:
>
>> There are discussions around Requests unvendoring its dependencies
>> thanks to the improved nature of pip. This might be a year of pretty
>> big changes for Requests.
>
> In
Le 23 mai 2017 17:49, "Alex Gaynor" a écrit :
I'm +1 on this, I even wrote the patch: https://bugs.python.org/issue22559
:-) If you're interested in making sure that still applies and tests still
pass, I'd be a big fan.
Oh sorry, I wasn't aware of that one. Sure, will do.
Victor
__
Le 23 mai 2017 19:46, "Nick Coghlan" a écrit :
(...) to the RHEL system Python by switching the default
behaviour for new installs to be to verify SSL/TLS certificates
against the system trust store
Awesome! Security, I see security everywhere!
Stay safe,
Victor
___
On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote:
> There are discussions around Requests unvendoring its dependencies
> thanks to the improved nature of pip. This might be a year of pretty
> big changes for Requests.
In which case, what is to prevent Requests from just depending on
On 24 May 2017 at 10:46, Victor Stinner wrote:
> Hi,
>
> Would you be ok to backport ssl.MemoryBIO and ssl.SSLObject on Python
> 2.7? I can do the backport.
>
> https://docs.python.org/dev/library/ssl.html#ssl.MemoryBIO
+1 from me - the last SSL module resync to 2.7 was from 3.4, and
bringing t
On 23May2017 1212, Victor Stinner wrote:
2017-05-22 13:17 GMT-05:00 Steve Dower :
Once the special protection is removed, most of these cases will become
OSError due to the general protection against segmentation faults.
It didn't know that ctypes on Windows had a special protection against
pr
> On 23 May 2017, at 17:58, Victor Stinner wrote:
>
> 2017-05-23 19:54 GMT-05:00 Cory Benfield :
>> 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 PyOpenSSL.
>
> Last time I
2017-05-23 19:54 GMT-05:00 Cory Benfield :
> 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 PyOpenSSL.
Last time I looked at requests, it embedded all its dependencies. I
don't li
Well, things evolved recently. asyncio is getting more popular, TLS
became even more important, and pyOpenSSL is not more evolving (from
what I heard from his maintainer, Hynek). Does Twister still use
pyOpenSSL?
I like the idea of putting more security stuff into Python to ease
maintainance of ap
> On 23 May 2017, at 17:46, Victor Stinner wrote:
>
>
> He described me his PEP and I strongly support it (sorry, I missed it
> when he posted it on python-dev), but we decided (Guido van Rossum,
> Christian Heimes, Cory Benfield and me, see the tweet below) to not
> put this in the stdlib righ
I'm +1 on this, I even wrote the patch: https://bugs.python.org/issue22559
:-) If you're interested in making sure that still applies and tests still
pass, I'd be a big fan.
In addition to all the benefits you mentioned, it also substantially
reduces the diff between 2.7 and 3.x (or at least it di
Hi,
Would you be ok to backport ssl.MemoryBIO and ssl.SSLObject on Python
2.7? I can do the backport.
https://docs.python.org/dev/library/ssl.html#ssl.MemoryBIO
Cory Benfield told me that it's a blocking issue for him to implement
his PEP 543 -- A Unified TLS API for Python 2.7:
https://www
Well, it sounds like you have an answer to the question of whether the
cpython developers are interested in making official snap releases, but of
course this doesn't stop you making unofficial snap releases, and simple
standalone python distributions can be pretty handy. I just wanted to point
out
2017-05-22 13:17 GMT-05:00 Steve Dower :
> Once the special protection is removed, most of these cases will become
> OSError due to the general protection against segmentation faults.
It didn't know that ctypes on Windows had a special protection against
programming errors. I'm not aware of such p
Hi Victor,
Since this request (or at least the bit about branded goods) isn't really
appropriate for python-dev I am taking the liberty of forwarding this email
to the PSF's administrator, who may be better placed to help. I have Bcc'd
python-dev on this reply so they aren't troubled by correspond
I think the I inevitable conclusion is"thanks, but no thanks."
On May 23, 2017 8:05 AM, "Martin Wimpress"
wrote:
> Hi,
>
> On 23/05/17 00:56, Matt Billenstein wrote:
>
>> On Tue, May 16, 2017 at 11:31:42AM +0100, Martin Wimpress wrote:
>>
>>> Is there someone here who'd be interested in doing th
On 23 May 2017 at 18:38, INADA Naoki wrote:
> Hi, Nick.
>
> I read again and I think PEP 538 is mostly ready for accepted,
> without waiting PEP 540.
Great to hear!
> One remaining my concern is setting LANG.
>
>> Setting LANG to C.UTF-8 ensures that even components that only check the
>> LANG
On 23May2017 0844, Mariatta Wijaya wrote:
+1
My understanding is this is a documentation change, marking it as
deprecated in 3.6.2 and a Misc News entry.
No actual code change.
Correct?
That's correct. I'm thinking just a :note: box in that section, and then
you can keep working on the 3.7 ch
+1
My understanding is this is a documentation change, marking it as
deprecated in 3.6.2 and a Misc News entry.
No actual code change.
Correct?
Mariatta Wijaya
On Tue, May 23, 2017 at 8:28 AM, Antoine Pitrou wrote:
> On Mon, 22 May 2017 11:17:18 -0700
> Steve Dower wrote:
> >
> > I'd like t
On Mon, 22 May 2017 11:17:18 -0700
Steve Dower wrote:
>
> I'd like to propose a highly-accelerated deprecation period for this
> specific feature, starting in CPython 3.6.2 and being "completed" in
> 3.7.0, when we will hopefully move onto a newer libffi.
>
> In general, the "feature" is a mis
On Mon, 22 May 2017 23:56:43 +
Matt Billenstein wrote:
> On Tue, May 16, 2017 at 11:31:42AM +0100, Martin Wimpress wrote:
> > Is there someone here who'd be interested in doing the same for Python?
>
> Do snaps support Windows and/or MacOS?
If you want a package manager that supports insta
Hi,
On 23/05/17 00:56, Matt Billenstein wrote:
On Tue, May 16, 2017 at 11:31:42AM +0100, Martin Wimpress wrote:
Is there someone here who'd be interested in doing the same for Python?
Do snaps support Windows and/or MacOS?
You can't install snaps on Windows or macOS. Snaps are currently
ta
On 23/05/17 09:27, Petr Viktorin wrote:
On 05/23/2017 01:34 AM, Brett Cannon wrote:
On Tue, 16 May 2017 at 08:08 Martin Wimpress
mailto:martin.wimpr...@canonical.com>>
wrote:
Hi all,
I work at Canonical as part of the engineering team developing Ubuntu
and Snapcraft [1] and I'm
In my opinion the trend of creating these standalone packages is pretty
bad. Developers that choose to support these kind of packages become
responsible not only for the code they distribute, but also for whether the
dependencies that are bundled in such a standalone package are up to date
and secu
Hi, Nick.
I read again and I think PEP 538 is mostly ready for accepted,
without waiting PEP 540.
One remaining my concern is setting LANG.
> Setting LANG to C.UTF-8 ensures that even components that only check the LANG
> fallback for their locale settings will still use C.UTF-8 .
https://www.p
On 05/23/2017 01:34 AM, Brett Cannon wrote:
On Tue, 16 May 2017 at 08:08 Martin Wimpress
mailto:martin.wimpr...@canonical.com>>
wrote:
Hi all,
I work at Canonical as part of the engineering team developing Ubuntu
and Snapcraft [1] and I'm a long time Python fan :-)
We've cr
30 matches
Mail list logo
