On 3/24/2014 9:43 AM, Nick Coghlan wrote:
And time for round 3 :)
And round 3 of my response: contrary to what I said before, I now think
that the base proposal should be the simplest possible: selectively (and
minimally) waive the 'no-enhancement in maintenance release policy' for
future 2.
On 2014-03-25 01:29, Ben Darnell wrote:
On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
On 24 Mar 2014 15:25, "Chris Angelico" mailto:ros...@gmail.com>> wrote:
> As has already been pointed out, this can already happen, but in an
> ad-hoc way. Mak
On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan wrote:
>
> On 24 Mar 2014 15:25, "Chris Angelico" wrote:
>
> > As has already been pointed out, this can already happen, but in an
> > ad-hoc way. Making it official or semi-official would mean that a
> > script written for Debian's "Python 2.7.10" w
On 3/24/2014 7:04 PM, Donald Stufft wrote:
On Mar 24, 2014, at 5:38 PM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
Beyond that, PEP 462 covers another way for corporate users to give
back - if they want to build massive commercial enterprises on our
software, they can help maintain and u
On 3/24/2014 6:51 PM, Andrew M. Hettinger wrote:
I thought I'd wait until the 3.4 release before I bothered asking about
this: http://bugs.python.org/issue20469
I don't think I'm qualified to actually be writing code for the ssl
module, but is there anything else that I can do to help?
I could
I thought I'd wait until the 3.4 release before I bothered asking about
this: http://bugs.python.org/issue20469
I don't think I'm qualified to actually be writing code for the ssl module,
but is there anything else that I can do to help?
I could probably put together a demonstration-case if that
On Mar 24, 2014, at 5:38 PM, Nick Coghlan wrote:
>
> On 25 Mar 2014 04:00, "Nikolaus Rath" wrote:
> >
> > Nick Coghlan writes:
> > > Maintainability
> > > ---
> > >
> > > This policy does NOT represent a commitment by volunteer contributors to
> > > actually backport network secur
On 25 Mar 2014 04:00, "Nikolaus Rath" wrote:
>
> Nick Coghlan writes:
> > Maintainability
> > ---
> >
> > This policy does NOT represent a commitment by volunteer contributors to
> > actually backport network security related changes from the Python 3
series
> > to the Python 2 series
On Mon, Mar 24, 2014 at 8:28 PM, Cory Benfield wrote:
> On 24 March 2014 08:44, Nick Coghlan wrote:
>> The position I am coming to is that the "enhanced security" release should
>> be the default one that we publish binary installers for, but we should also
>> ensure that downstream redistributor
Hi there.
I didn’t see the original email in python-dev, sorry about that.
The “setstate” of the iterators is primarily used when unpickling them. This
is code that was added during the PyCon sprints 2012, IIRC.
Some iterators already did the silent clipping.
One did not (rangeiter), it raised a
Nick Coghlan writes:
> Maintainability
> ---
>
> This policy does NOT represent a commitment by volunteer contributors to
> actually backport network security related changes from the Python 3 series
> to the Python 2 series. Rather, it is intended to send a clear signal to
> potential
On 24.03.2014 18:23, Ned Deily wrote:
> In article
> ,
> Nick Coghlan wrote:
>> You also reminded me that I need to dig around for and reference Ned's
>> email about the status of OS X and reference that (OpenSSL upgrades
>> were a casualty of Apple's anti-GPL crusade, so the OS X installers
>>
In article
,
Nick Coghlan wrote:
> You also reminded me that I need to dig around for and reference Ned's
> email about the status of OS X and reference that (OpenSSL upgrades
> were a casualty of Apple's anti-GPL crusade, so the OS X installers
> were switched to static linking somewhere along
Le 24/03/2014 15:21, R. David Murray a écrit :
In the context of that last sentence, I think it is worth noting the
stance that 3.4 is taking[*] about security backward compatibility,
since many people may not be aware of it (we only just finished making
the documentation clear).
If you use cre
On 24 March 2014 08:44, Nick Coghlan wrote:
> The position I am coming to is that the "enhanced security" release should
> be the default one that we publish binary installers for, but we should also
> ensure that downstream redistributors can easily do "Python 2.7 with legacy
> SSL" releases if t
On 25 March 2014 00:36, Nick Coghlan wrote:
> On 25 March 2014 00:18, Skip Montanaro wrote:
> The PEP does not permit backwards compatibility breaks in maintenance
> releases
Well, ssl.create_default_context() will use the same "this is a
dynamic best practices API" policy as it does in 3.4. But
On 25 March 2014 00:18, Skip Montanaro wrote:
> On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan wrote:
>> For example, RHEL7 and derivatives are already locked in to 2.7 until
>> 2024, RHEL6 and derivatives are locked in to 2.6 until 2020. The only
>> way to keep those combination of RHEL and the P
On Sun, 23 Mar 2014 21:31:12 -0400, Barry Warsaw wrote:
> On Mar 24, 2014, at 11:38 AM, Chris Angelico wrote:
>
> >Easy. Just set PYTHONPATH to import the SEPython [1] lib ahead of the
> >standard lib. Then you can go back to the standard 2.7 (if you want
> >to) by unsetting PYTHONPATH.
> >
> >It
On Mon, Mar 24, 2014 at 9:11 AM, Nick Coghlan wrote:
> For example, RHEL7 and derivatives are already locked in to 2.7 until
> 2024, RHEL6 and derivatives are locked in to 2.6 until 2020. The only
> way to keep those combination of RHEL and the Python 2 standard
> library from holding back the evo
On 24 March 2014 23:49, Skip Montanaro wrote:
> So what's the big deal? Why can't we be pragmatic and call this thing
> (whatever it turns out to be) 2.8? Is this pledge and its rationale
> written down in a PEP somewhere, so I can study the reasons behind
> what appears at this point to be blind
On Sun, Mar 23, 2014 at 7:03 PM, Barry Warsaw wrote:
> I want to stick to our no-Python-2.8 pledge
I don't understand this dogmatic adherence to a "no 2.8 pledge." Back
when it was made, I don't think the issue of SSL vulnerabilities was
understood (at least not to the current level). Now we
And time for round 3 :)
Notable changes:
- removed the higher level networking modules from the scope of the
PEP. They made people nervous, and aren't actually needed to achieved
the desired result (at the higher levels, it's much easier for third
party pure Python modules like requests to step i
On 24 March 2014 22:39, M.-A. Lemburg wrote:
> On 24.03.2014 13:33, Antoine Pitrou wrote:
>> Under Linux (and probably OS X too), the _ssl module is linked
>> dynamically with OpenSSL:
>>
>> $ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so
>> linux-vdso.so.1 => (0x7fff3f1de000)
>> lib
On 24.03.2014 13:33, Antoine Pitrou wrote:
> Le 24/03/2014 10:10, M.-A. Lemburg a écrit :
>> On 23.03.2014 08:07, Nick Coghlan wrote:
>>> Open Questions
>>> ==
>>>
>>> * What are the risks associated with allowing OpenSSL to be updated to
>>>new feature versions in the Windows and M
Le 24/03/2014 10:10, M.-A. Lemburg a écrit :
On 23.03.2014 08:07, Nick Coghlan wrote:
Open Questions
==
* What are the risks associated with allowing OpenSSL to be updated to
new feature versions in the Windows and Mac OS X binary installers for
maintenance releases? Currently
On 23.03.2014 08:07, Nick Coghlan wrote:
> Open Questions
> ==
>
> * What are the risks associated with allowing OpenSSL to be updated to
> new feature versions in the Windows and Mac OS X binary installers for
> maintenance releases? Currently we just upgrade to the appropriate
>
On Mon, Mar 24, 2014 at 7:44 PM, Nick Coghlan wrote:
>
> On 24 Mar 2014 15:25, "Chris Angelico" wrote:
>
>> As has already been pointed out, this can already happen, but in an
>> ad-hoc way. Making it official or semi-official would mean that a
>> script written for Debian's "Python 2.7.10" would
On 24 Mar 2014 15:25, "Chris Angelico" wrote:
> As has already been pointed out, this can already happen, but in an
> ad-hoc way. Making it official or semi-official would mean that a
> script written for Debian's "Python 2.7.10" would run on Red Hat's
> "Python 2.7.10", which would surely be an
Am 22.03.2014 00:25, schrieb Nick Coghlan:
On 22 March 2014 05:46, Thomas Heller wrote:
With python 3.4 and pywin32 version 218 it is only possible
to import win32com or win32api when pywintypes has been imported before.
I have no idea if this is a bug in pywin32 or in Python 3.4.
Does anyone
29 matches
Mail list logo
