Alex Gaynor writes:
Here's my proposed list of such featuers:
And suppose that list grows over time? After all, it once was [].
If we go for a feature-by-feature list, that has two more-or-less
hidden costs. (1) Python-Dev has to specify which ones, and either
risks a new specification
On 27 March 2014 18:02, Stephen J. Turnbull step...@xemacs.org wrote:
Alex Gaynor writes:
Here's my proposed list of such featuers:
And suppose that list grows over time? After all, it once was [].
If we go for a feature-by-feature list, that has two more-or-less
hidden costs. (1)
BTW, my intention was also to set a precedent for future additions to the
list. We did this before is a great argument to help smooth the path,
without bypassing deliberations altogether.
On Mar 27, 2014 2:33 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 27 March 2014 18:02, Stephen J. Turnbull
On 25 March 2014 13:09, Nick Coghlan ncogh...@gmail.com wrote:
* MvL has indicated he is not prepared to tackle the task of trying to
integrate a newer OpenSSL into the also aging Python 2.7 build
infrastructure on Windows (unfortunately, we've looked into upgrading
that build
On 25 Mar 2014 23:29, Paul Moore p.f.mo...@gmail.com wrote:
On 25 March 2014 13:09, Nick Coghlan ncogh...@gmail.com wrote:
* MvL has indicated he is not prepared to tackle the task of trying to
integrate a newer OpenSSL into the also aging Python 2.7 build
infrastructure on Windows
On 25 March 2014 13:47, Nick Coghlan ncogh...@gmail.com wrote:
It's not like we're going to just be giving the PEP to vendors as a spec and
leaving them to it - it's largely an invitation to participate more directly
upstream to help resolve a particularly thorny problem, not a Statement of
On Tue, 25 Mar 2014 14:25:29 +
Paul Moore p.f.mo...@gmail.com wrote:
On 25 March 2014 13:47, Nick Coghlan ncogh...@gmail.com wrote:
It's not like we're going to just be giving the PEP to vendors as a spec and
leaving them to it - it's largely an invitation to participate more directly
On Tue, Mar 25, 2014 at 8:10 AM, Antoine Pitrou solip...@pitrou.net wrote:
The problem with backporting SSLContext is really that 1) you are adding
a non-minimal new API set to the 2.7 feature set; 2) you must make it so
that other stdlib modules take advantage of the new APIs (otherwise
why
A casual glance at
https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/
util.py#L610
which is probably the most widely used consumer of these APIs, outside the
stdlib itself, looks to me like if these names were to suddenly show up,
everything would continue to work just
On Tue, Mar 25, 2014 at 8:31 AM, Alex Gaynor alex.gay...@gmail.com wrote:
A casual glance at
https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/
util.py#L610
which is probably the most widely used consumer of these APIs, outside the
stdlib itself, looks to me
On Mar 25, 2014, at 12:35 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Mar 25, 2014 at 8:31 AM, Alex Gaynor alex.gay...@gmail.com wrote:
A casual glance at
https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/
util.py#L610
which is probably the most widely
On Tue, Mar 25, 2014 at 9:46 AM, Donald Stufft don...@stufft.io wrote:
On Mar 25, 2014, at 12:35 PM, Guido van Rossum gu...@python.org wrote:
[...]
I do note that the PEP seems to have some weasel-words about breaking
backward compatibility in the name of security. The phrase This PEP does
On Mar 25, 2014, at 1:16 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Mar 25, 2014 at 9:46 AM, Donald Stufft don...@stufft.io wrote:
On Mar 25, 2014, at 12:35 PM, Guido van Rossum gu...@python.org wrote:
[...]
I do note that the PEP seems to have some weasel-words about breaking
Am 25.03.14 14:47, schrieb Nick Coghlan:
The PEP says to sync with Python 3, and that has full cross platform
support. The Linux focus just comes from the fact that Linux is where
the problem is most evident.
However, it fails to address a critical detail: the upcoming maintenance
end for 2.7.
On Tue, 25 Mar 2014 23:09:45 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Alternative: selectively backport particular APIs
-
An instinctively minimalist reaction to this proposal is to only backport
particular APIs in the affected modules
On 26 Mar 2014 00:25, Paul Moore p.f.mo...@gmail.com wrote:
On 25 March 2014 13:47, Nick Coghlan ncogh...@gmail.com wrote:
It's not like we're going to just be giving the PEP to vendors as a
spec and
leaving them to it - it's largely an invitation to participate more
directly
upstream to
On 26 Mar 2014 08:35, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 25 Mar 2014 23:09:45 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Alternative: selectively backport particular APIs
-
An instinctively minimalist reaction to this
On Mar 25, 2014, at 7:03 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 26 Mar 2014 08:35, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 25 Mar 2014 23:09:45 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Alternative: selectively backport particular APIs
At this I think this PEP has become a little too vague and abstract, and I
think we'd probably be better served by getting more concrete:
Problem:
Some of Python 2's modules which are fundamentally necessary for interop with
the broader internet, and the security thereof, are missing really
19 matches
Mail list logo
