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" wrote:
> On 27 March 2014 18:02, Stephen J. Turnbull wrote:
> > Al
On 27 March 2014 18:02, Stephen J. Turnbull 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) Python-Dev has
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 deba
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 impor
On Mar 25, 2014, at 7:03 PM, Nick Coghlan wrote:
>
> On 26 Mar 2014 08:35, "Antoine Pitrou" wrote:
> >
> > On Tue, 25 Mar 2014 23:09:45 +1000
> > Nick Coghlan wrote:
> > >
> > > Alternative: selectively backport particular APIs
> > > -
> > >
> >
On 26 Mar 2014 08:35, "Antoine Pitrou" wrote:
>
> On Tue, 25 Mar 2014 23:09:45 +1000
> Nick Coghlan wrote:
> >
> > Alternative: selectively backport particular APIs
> > -
> >
> > An instinctively minimalist reaction to this proposal is to only
backp
On 26 Mar 2014 00:25, "Paul Moore" wrote:
>
> On 25 March 2014 13:47, Nick Coghlan 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 t
On Tue, 25 Mar 2014 23:09:45 +1000
Nick Coghlan wrote:
>
> Alternative: selectively backport particular APIs
> -
>
> An instinctively minimalist reaction to this proposal is to only backport
> particular APIs in the affected modules that are judged
Urk. Premature send. As it turns out, I had no specific comments to
make after the one comment on
> Alternative: create and release Python 2.8
> --
My apologies to anybody who read to the bottom for wasting their time.
I do have one generic comment on
Nick Coghlan writes:
> Changes to these modules will still need to undergo normal backwards
> compatibility assessments to ensure their default behaviour remains
> consistent with earlier Python 2.7 releases,
I find this wording confusing. Does this mean that (possibly
imaginary example) wher
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.
On Mar 25, 2014, at 1:16 PM, Guido van Rossum wrote:
> On Tue, Mar 25, 2014 at 9:46 AM, Donald Stufft wrote:
>
> On Mar 25, 2014, at 12:35 PM, Guido van Rossum wrote:
> [...]
>>
>> I do note that the PEP seems to have some weasel-words about breaking
>> backward compatibility in the name of
On Tue, Mar 25, 2014 at 9:46 AM, Donald Stufft wrote:
>
> On Mar 25, 2014, at 12:35 PM, Guido van Rossum 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
> *not* grant Python 2.7 a
On Mar 25, 2014, at 12:35 PM, Guido van Rossum wrote:
> On Tue, Mar 25, 2014 at 8:31 AM, Alex Gaynor 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, outs
On Tue, Mar 25, 2014 at 8:31 AM, Alex Gaynor 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 like if these names
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:10 AM, Antoine Pitrou 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 bother?).
>
I a
On Tue, 25 Mar 2014 14:25:29 +
Paul Moore wrote:
> On 25 March 2014 13:47, Nick Coghlan 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 parti
On 25 March 2014 13:47, Nick Coghlan 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
> Work :)
:-)
I d
On 25 Mar 2014 23:29, "Paul Moore" wrote:
>
> On 25 March 2014 13:09, Nick Coghlan 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 in
On 25 March 2014 13:09, Nick Coghlan 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 infrastructure, and the b
Hmm, should probably have more entries in the post history... Anyway:
* As Ben Darnell noted, the legacy SSL branch thing was a
fundamentally bad idea. We can't stop downstream redistributors doing
that if they really want to, but we don't have to encourage them
* I also explained why I think sele
22 matches
Mail list logo
