On Mon, Mar 24, 2014 at 1:34 PM, Donald Stufft wrote:
> Right now users have a singular method for determining what the runtime
> environment looks like for Python, the version. There are processes around
> selecting different Python versions for things, upgrading etc. This isn’t
> a new thing for
On Mar 23, 2014, at 9:31 PM, 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'd be
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'd be nice if SEPython defined a modified sys.version for clarity,
>but
On 3/23/2014 7:47 PM, Antoine Pitrou wrote:
On Sun, 23 Mar 2014 19:44:42 -0400
"R. David Murray" wrote:
On Sun, 23 Mar 2014 21:43:14 +0100, Antoine Pitrou wrote:
On Sun, 23 Mar 2014 20:47:28 +0100 (CET)
r.david.murray wrote:
...
Previously a non-string, non-regex second argument could cau
On Mar 23, 2014, at 8:31 PM, Jesse Noller wrote:
>
>
>> On Mar 23, 2014, at 7:03 PM, Barry Warsaw wrote:
>>
>>> On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
>>>
>>> I'm unclear how this would be better than just biting the bullet and
>>> making a 2.8 release. On the one hand, the 2.7
On 3/23/2014 7:48 PM, Nick Coghlan wrote:
Agreed. That's a key part of why the proposal is mainly about syncing
certain key modules with their Python 3 counterparts, rather than
piecemeal backports. That way, all you need to know is "the SSL, hashlib
and hmac modules are kept in sync with Python
On 3/23/2014 8:03 PM, Barry Warsaw wrote:
On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
I'm unclear how this would be better than just biting the bullet and
making a 2.8 release. On the one hand, the 2.7.x number suggests
(based on the existing release protocol) that it should be a drop-i
On Mon, Mar 24, 2014 at 11:03 AM, Barry Warsaw wrote:
> Python 2.7.x will always be the "standard stdlib". We would never release a
> specific Python 2.7 + "security stdlib" release, but downstream developers
> would be able to overlay this forked stdlib on top of the standard one.
> Volunteers o
> On Mar 23, 2014, at 7:03 PM, Barry Warsaw wrote:
>
>> On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
>>
>> I'm unclear how this would be better than just biting the bullet and
>> making a 2.8 release. On the one hand, the 2.7.x number suggests
>> (based on the existing release protocol)
On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
>I'm unclear how this would be better than just biting the bullet and
>making a 2.8 release. On the one hand, the 2.7.x number suggests
>(based on the existing release protocol) that it should be a drop-in
>replacement for earlier 2.7 micro relea
On 3/23/2014 9:00 AM, Skip Montanaro wrote:
On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy wrote:
The download page for the final 2.7.z maintenance release could say
something like "We recommend that you move to the most recent Python 3
version if at all possible. If you cannot do that and you w
On 24 Mar 2014 09:27, "Barry Warsaw" wrote:
>
> On Mar 23, 2014, at 01:01 AM, Antoine Pitrou wrote:
>
> >But enforcing "secure by default" can by construction break backwards
> >compatibility, which is the very reason we are so conservative with
> >such changes.
>
> Also, many developers who are s
On Sun, 23 Mar 2014 19:44:42 -0400
"R. David Murray" wrote:
> On Sun, 23 Mar 2014 21:43:14 +0100, Antoine Pitrou
> wrote:
> > On Sun, 23 Mar 2014 20:47:28 +0100 (CET)
> > r.david.murray wrote:
> > > http://hg.python.org/cpython/rev/ec556e45641a
> > > changeset: 89936:ec556e45641a
> > > user:
On Sun, 23 Mar 2014 21:43:14 +0100, Antoine Pitrou wrote:
> On Sun, 23 Mar 2014 20:47:28 +0100 (CET)
> r.david.murray wrote:
> > http://hg.python.org/cpython/rev/ec556e45641a
> > changeset: 89936:ec556e45641a
> > user:R David Murray
> > date:Sun Mar 23 15:08:43 2014 -0400
> > s
On 3/23/2014 3:29 AM, Cory Benfield wrote:
On 23 March 2014 at 04:32:17, Terry Reedy
(tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote:
Instead, I think the PEP should propose a special series of server
enhancement releases that are based on the final 2.7 maintenance release
(2.7.8 or 2.7.9) bu
On Mar 23, 2014, at 01:01 AM, Antoine Pitrou wrote:
>But enforcing "secure by default" can by construction break backwards
>compatibility, which is the very reason we are so conservative with
>such changes.
Also, many developers who are stuck on Python 2 have already evaluated,
designed, and impl
On 24 Mar 2014 03:48, "Guido van Rossum" wrote:
>
> On Sun, Mar 23, 2014 at 9:33 AM, "Martin v. Löwis"
wrote:
>>
>> Am 23.03.14 17:22, schrieb Guido van Rossum:
>> > At Dropbox I work with a large group of very capable developers on
>> > several large code bases that are currently in 2.7. We are
On Sun, 23 Mar 2014 20:47:28 +0100 (CET)
r.david.murray wrote:
> http://hg.python.org/cpython/rev/ec556e45641a
> changeset: 89936:ec556e45641a
> user:R David Murray
> date:Sun Mar 23 15:08:43 2014 -0400
> summary:
> #20145: assert[Raises|Warns]Regex now raise TypeError on bad
On Sun, Mar 23, 2014 at 9:33 AM, "Martin v. Löwis" wrote:
> Am 23.03.14 17:22, schrieb Guido van Rossum:
> > At Dropbox I work with a large group of very capable developers on
> > several large code bases that are currently in 2.7. We are constantly
> > changing our code to make it more secure (th
On Mar 23, 2014, at 12:33 PM, Martin v. Löwis wrote:
> Am 23.03.14 17:22, schrieb Guido van Rossum:
>> At Dropbox I work with a large group of very capable developers on
>> several large code bases that are currently in 2.7. We are constantly
>> changing our code to make it more secure (there ar
Am 23.03.14 17:22, schrieb Guido van Rossum:
> At Dropbox I work with a large group of very capable developers on
> several large code bases that are currently in 2.7. We are constantly
> changing our code to make it more secure (there are several teams
> specifically in charge of that). And yet po
This really upset me:
On Sun, Mar 23, 2014 at 3:17 AM, wrote:
> I think asking developers to make significant modifications to their
> code is besides the point of the PEP. However, if they are willing
> to make changes, I'd still recommend that they port their code to
> Python 3, as that is the
On Mar 23, 2014, at 11:55 AM, Mark Lawrence wrote:
> On 23/03/2014 15:46, Antoine Pitrou wrote:
>> On Sun, 23 Mar 2014 11:37:25 -0400
>> Donald Stufft wrote:
>>>
>>> I already did open an issue and write a patch :)
>>>
>>> There’s someone on that issue saying that flipping that without a way
On Mar 23, 2014, at 9:13 AM, Antoine Pitrou wrote:
> On Sun, 23 Mar 2014 17:07:24 +1000
> Nick Coghlan wrote:
>> Another more critical example is the lack of SSL hostname matching in the
>> Python 2 standard library - it is currently necessary to rely on a third
>> party library, such as ``requ
On 23/03/2014 15:46, Antoine Pitrou wrote:
On Sun, 23 Mar 2014 11:37:25 -0400
Donald Stufft wrote:
I already did open an issue and write a patch :)
There’s someone on that issue saying that flipping that without a way to flip
it back
would break their application.
You're right, I had forgo
On Mar 23, 2014, at 11:46 AM, Antoine Pitrou wrote:
> On Sun, 23 Mar 2014 11:37:25 -0400
> Donald Stufft wrote:
>>
>> I already did open an issue and write a patch :)
>>
>> There’s someone on that issue saying that flipping that without a way to
>> flip it back
>> would break their applicati
On Sun, 23 Mar 2014 11:37:25 -0400
Donald Stufft wrote:
>
> I already did open an issue and write a patch :)
>
> There’s someone on that issue saying that flipping that without a way to flip
> it back
> would break their application.
You're right, I had forgotten about that :-)
I'd be surpris
On 3/23/2014 11:37 AM, Donald Stufft wrote:
>
> On Mar 23, 2014, at 11:34 AM, Antoine Pitrou wrote:
>
>> On Sun, 23 Mar 2014 07:29:07 +
>> Cory Benfield wrote:
>>> This is an interesting idea. My biggest problem with it is that, at least
>>> with the ssl library, these aren’t server-only pr
On Mar 23, 2014, at 11:34 AM, Antoine Pitrou wrote:
> On Sun, 23 Mar 2014 07:29:07 +
> Cory Benfield wrote:
>> On 23 March 2014 at 04:32:17, Terry Reedy
>> (tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote:
>>> Instead, I think the PEP should propose a special series of server
>>> enhancem
On Sun, 23 Mar 2014 07:29:07 +
Cory Benfield wrote:
> On 23 March 2014 at 04:32:17, Terry Reedy
> (tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote:
> > Instead, I think the PEP should propose a special series of server
> > enhancement releases that are based on the final 2.7 maintenance rele
On 23 March 2014 at 04:32:17, Terry Reedy
(tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote:
> Instead, I think the PEP should propose a special series of server
> enhancement releases that are based on the final 2.7 maintenance release
> (2.7.8 or 2.7.9) but which have have a different applicatio
On 23 March 2014 07:07, Nick Coghlan wrote:
> Advance warning: while I was able to get this revision turned around
> pretty quickly, future revisions are likely to take a fair bit longer.
> It was already a rather busy month before I decided to start this
> discussion on top of everything else :)
On 22 March 2014 21:11, Nick Coghlan wrote:
> Full PEP included inline below, and available in more readable form at
> http://www.python.org/dev/peps/pep-0466/
Disclaimer: I pretty much don't use 2.x, or write server-type
software, so my practical requirement for the changes proposed here is
negl
On Sun, 23 Mar 2014 17:07:24 +1000
Nick Coghlan wrote:
> Another more critical example is the lack of SSL hostname matching in the
> Python 2 standard library - it is currently necessary to rely on a third
> party library, such as ``requests`` or ``backports.ssl_match_hostname`` to
> obtain that f
On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy wrote:
> The download page for the final 2.7.z maintenance release could say
> something like "We recommend that you move to the most recent Python 3
> version if at all possible. If you cannot do that and you want to use Python
> to run a server on th
On 23 Mar 2014 18:42, Martin v. Löwis wrote:
>
> Am 23.03.14 08:07, schrieb Nick Coghlan:
> > Several significant changes in this revision:
> >
> > - scope narrowed to just Python 2.7 plus permission for commercial
> > redistributors to use the same strategy in their long term support
> > releases
On 23 Mar 2014 20:33, "Victor Stinner" wrote:
>
> Sorry, it's maybe not fair to take the worst example (OpenStack) :-)
I suspect the Fedora/RHEL/CentOS ecosystem is going to make OpenStack look
like a relatively simple port, and backwards compatibility constraints mean
that already defined RHEL/C
Hi,
2014-03-23 11:17 GMT+01:00 :
> Quoting Victor Stinner :
>> The drawback is that applications would be benefit immediatly from
>> this work, they should be modified to use the new module. But usually,
>> developers who care of security are able to do these modifications.
>
> I think asking dev
Quoting Victor Stinner :
The drawback is that applications would be benefit immediatly from
this work, they should be modified to use the new module. But usually,
developers who care of security are able to do these modifications.
I think asking developers to make significant modifications to
Hi,
2014-03-22 22:11 GMT+01:00 Nick Coghlan :
> In particular, the exception will apply to:
>
> * the ``ssl`` module
> * the ``hashlib`` module
> * the ``hmac`` module
> * the ``sha`` module (Python 2 only)
> * the components of other networking modules that make use of these modules
> * the compo
On 23.03.2014 02:33, Brett Cannon wrote:
> Now I have been reading this thread on my phone and I only have cursory
> understanding of what failure ssl has had as of late, so this might be
> stupid, but what if in Python 3.5 we made it so people passed in an
> explicit SSL object into the relevant A
Am 23.03.14 08:07, schrieb Nick Coghlan:
> Several significant changes in this revision:
>
> - scope narrowed to just Python 2.7 plus permission for commercial
> redistributors to use the same strategy in their long term support
> releases
Thanks; the rationale is now much clearer, and also indic
Hi.
Not really sure where to report this - missing closing parentheses in
the PEP text at the end of the second paragraph in section
'Implementation strategy'
http://legacy.python.org/dev/peps/pep-0453/#id35
> and would not try to contact PyPI (instead installing directly
> from the pr
On Sun, Mar 23, 2014 at 6:07 PM, Nick Coghlan wrote:
> And that's just three of the highest profile open source projects that
> make heavy use of Python. Given the likely existence of large amounts of
> legacy code that lacks the kind of automated regression test suite needed
> to help support a m
On Mar 23, 2014, at 3:07 AM, Nick Coghlan wrote:
> Several significant changes in this revision:
>
> - scope narrowed to just Python 2.7 plus permission for commercial
> redistributors to use the same strategy in their long term support
> releases
> - far more explicit that this is about inviti
Several significant changes in this revision:
- scope narrowed to just Python 2.7 plus permission for commercial
redistributors to use the same strategy in their long term support
releases
- far more explicit that this is about inviting potential corporate
contributors to address the situation for
46 matches
Mail list logo
