Re: [Python-Dev] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2018-05-31 Thread Nathaniel Smith 
On Wed, May 30, 2018, 14:21 Victor Stinner  wrote:

> 2018-05-30 18:02 GMT+02:00 Nathaniel Smith :
> > On Wed, May 30, 2018, 07:30 Victor Stinner  wrote:
> >>
> >> Does anyone would benefit of MemoryBIO in Python 2.7? Twisted,
> >> asyncio, trio, urllib3, anyone else?
> >
> > Asyncio and trio are strongly py3-only. Twisted's TLS functionality is
> built
> > around pyopenssl, so the stdlib ssl module doesn't affect them. Urllib3
> uses
> > the socket-wrapping APIs, not MemoryBIO. So fwiw I don't think any of
> those
> > projects would benefit.
>
> MemoryBIO was the key feature which allowed to implement TLS for the
> ProactorEventLoop (IOCP) of asyncio.
>

MemoryBIO is definitely super useful for async libraries – trio uses it,
asyncio uses it, twisted uses it (via pyopenssl). But I don't know of
anyone who currently needs it but hasn't already found a way to get it.

I'm not sure that the Python 2.7 ssl module is a drop-in replacement
> for pyopenssl.
>

No, their APIs are totally different, for better or worse.

-n

>
___
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] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2018-05-31 Thread Nick Coghlan 
On 31 May 2018 at 19:34, Nathaniel Smith  wrote:

> On Wed, May 30, 2018, 14:21 Victor Stinner  wrote:
>
>> MemoryBIO was the key feature which allowed to implement TLS for the
>> ProactorEventLoop (IOCP) of asyncio.
>>
>
> MemoryBIO is definitely super useful for async libraries – trio uses it,
> asyncio uses it, twisted uses it (via pyopenssl). But I don't know of
> anyone who currently needs it but hasn't already found a way to get it.
>

I think one of the other key things that changed is pip gaining its own
native support for using the SecureTransport API on Mac OS X.

So yeah, unless someone from PyCA chimes in to say that the PEP still
offers benefits that we can't get another way, withdrawing PEP 546 as
"Overtaken by events" probably makes sense.

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] The history of PyXML

2018-05-31 Thread Jeremy Kloth 
On Mon, May 28, 2018 at 9:53 PM, Serhiy Storchaka  wrote:
> 28.05.18 23:11, Jeremy Kloth пише:
>>
>> On Thu, May 17, 2018 at 6:18 AM, Serhiy Storchaka 
>> wrote:
>>>
>>> Does anyone has the full copy of the PyXML repository, with the complete
>>> history?
>>>
>>
>> Here you go!
>>
>> https://github.com/jkloth/pyxml
>
>
> Great! Thank you, this is what I needed!

I had also contacted SourceForge prior to me uploading a Github repo.
They have just restored the project files for PyXML as well (CVS,
downloads, ...).

-- 
Jeremy Kloth
___
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] What is the command to upgrade python 3.6.5 to 3.7.5?

2018-05-31 Thread Jonathan Tsang via Python-Dev 
Hi Dev. Support,
 Is there a command that can help me to upgrade python 3.6.5 to 3.7.5 without 
uninstall and reinstall please?
Thanks,Jonathan___
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] What is the command to upgrade python 3.6.5 to 3.7.5?

2018-05-31 Thread Ivan Pozdeev via Python-Dev 

https://stackoverflow.com/questions/15102943/how-to-update-python/50616351#50616351

On 01.06.2018 5:22, Jonathan Tsang via Python-Dev wrote:

Hi Dev. Support,

 Is there a command that can help me to upgrade python 3.6.5 to 3.7.5 
without uninstall and reinstall please?


Thanks,
Jonathan


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
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] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2018-05-31 Thread Donald Stufft 


> On May 31, 2018, at 10:22 AM, Nick Coghlan  wrote:
> 
> On 31 May 2018 at 19:34, Nathaniel Smith  > wrote:
> On Wed, May 30, 2018, 14:21 Victor Stinner  > wrote:
> MemoryBIO was the key feature which allowed to implement TLS for the
> ProactorEventLoop (IOCP) of asyncio.
> 
> MemoryBIO is definitely super useful for async libraries – trio uses it, 
> asyncio uses it, twisted uses it (via pyopenssl). But I don't know of anyone 
> who currently needs it but hasn't already found a way to get it.
> 
> I think one of the other key things that changed is pip gaining its own 
> native support for using the SecureTransport API on Mac OS X.
> 
> So yeah, unless someone from PyCA chimes in to say that the PEP still offers 
> benefits that we can't get another way, withdrawing PEP 546 as "Overtaken by 
> events" probably makes sense.
> 


I think it still provides benefits FWIW, pip’s SecureTransport shim is a slow 
as hell ctypes hack that is slow enough we *only* use it when the ``ssl`` 
library wouldn’t be able to connect anyways and that doesn’t help Windows. OTOH 
I don’t think it’s super useful without PEP 543 also.

___
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] How to watch buildbots?

2018-05-31 Thread Ivan Pozdeev via Python-Dev 

On 30.05.2018 16:36, Nick Coghlan wrote:
On 30 May 2018 at 22:30, Ivan Pozdeev via Python-Dev 
mailto:[email protected]>> wrote:


What's the big idea of separate buildbots anyway? I thought the
purpose of CI is to test everything _before_
it breaks the main codebase. Then it's the job of the contributor
rather than maintainer to fix any breakages.


So, maybe making them be driven by Github checks would be a better
time investment.
Especially since we've got VSTS checks just recently, so whoever
was doing that still knows how to interface with this Github
machinery.

If the bots cancel a previous build if a new one for the same PR
arrives, this will not lead to a significant load difference 'cuz
the number of
actively developed PRs is stable and roughly equal to the number
of merges according to the open/closed tickets dynamics.


There are a few key details here:

1. We currently need to run post-merge CI anyway, as we're not doing 
linearised commits (where core devs just approve a change without 
merging it, and then a gating system like Zuul ensures that the tests 
are run against the latest combination of the target branch and the PR 
before merging the change)


This is the only point here that looks valid (others can be refuted). 
This technique limits the achievable commit rate by 1/testing_time . Our 
average rate probably fits into this, though it still means delays.


2. Since the buildbots are running on donated dedicated machines 
(rather than throwaway instances from a dynamic CI provider), we need 
to review the code before we let it run on the contributed systems
3. The buildbot instances run *1* build at a time, which would lead to 
major PR merging bottlenecks during sprints if we made them a gating 
requirement
4. For the vast majority of PRs, the post-merge cross-platform testing 
is a formality, since the code being modified is using lower level 
cross-platform APIs elsewhere in the standard library, so if it works 
on Windows, Linux, and Mac OS X, it will work everywhere Python runs
5. We generally don't *want* to burden new contributors with the task 
of dealing with the less common (or harder to target) platforms 
outside the big 3 - when they do break, it often takes a non-trivial 
amount of platform knowledge to understand what's different about the 
platform in question


Cheers,
Nick.

P.S. That said, if VSTS or Travis were to offer FreeBSD as an option 
for pre-merge CI, I'd suggest we enable it, at least in an advisory 
capacity - it's a better check against Linux-specific assumptions 
creeping into the code base than Mac OS X, since the latter is 
regularly different enough from other *nix systems that we need to 
give it dedicated code paths.


--
Nick Coghlan   | [email protected]  |   
Brisbane, Australia


--
Regards,
Ivan

___
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