On 25 March 2014 12:25, MRAB pyt...@mrabarnett.plus.com wrote:
On 2014-03-25 01:29, Ben Darnell wrote:
On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
On 24 Mar 2014 15:25, Chris Angelico ros...@gmail.com
mailto:ros...@gmail.com
On 25 March 2014 09:04, Donald Stufft don...@stufft.io wrote:
On Mar 24, 2014, at 5:38 PM, Nick Coghlan ncogh...@gmail.com wrote:
While I totally agree that it would be incredibly awesome if more companies
put
dedicated time into developing and maintaining CPython I don't think pushing
all
Am 25.03.2014 08:51, schrieb Nick Coghlan:
I think that calling it Python 2.8 would be a bad idea for the reasons
that have already been stated.
Perhaps it should just be called Python 2.7 Enhanced Security (Python
2.7 ES).
The PEP currently calls the proposed unmodified fork of 2.7
On Tue, Mar 25, 2014 at 7:12 PM, Cory Benfield c...@lukasa.co.uk wrote:
On 24 March 2014 19:37, Chris Angelico ros...@gmail.com wrote:
The opting in could be done at the distro level. Red Hat could ship a
thing called /usr/bin/python that runs SEPython, and that package
could be identified and
On 24.03.2014 23:51, 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
On Tue, Mar 25, 2014 at 7:37 PM, Cory Benfield c...@lukasa.co.uk wrote:
On 25 March 2014 08:26, Chris Angelico ros...@gmail.com wrote:
Exactly the same. If someone wants to distribute SEPython (that
someone might be python.org itself, or ActiveState, or anyone else who
has an interest in it),
Am 22.03.14 22:03, schrieb Benjamin Peterson:
On Sat, Mar 22, 2014, at 11:10, Antoine Pitrou wrote:
Hello,
I've created the 3.4 category in the buildbots setup:
http://buildbot.python.org/all/waterfall?category=3.4.stable
I've also retired 3.2 and 3.3 buildbots. Someone will have to
On Mar 25, 2014, at 06:11 PM, Nick Coghlan wrote:
I actually agree with this (hence why I wrote the PEP in the first
place), I just became really, really, really, annoyed with certain
organisations over the course of writing the PEP drafts and that is
reflected in the tone of the latest draft.
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 25 March 2014 08:26, Chris Angelico ros...@gmail.com wrote:
Exactly the same. If someone wants to distribute SEPython (that
someone might be python.org itself, or ActiveState, or anyone else who
has an interest in it), they're welcome to do so; and it could be done
either as an all-in-one
On 24 March 2014 19:37, Chris Angelico ros...@gmail.com wrote:
The opting in could be done at the distro level. Red Hat could ship a
thing called /usr/bin/python that runs SEPython, and that package
could be identified and numbered in such a way that it's clearly a
drop-in replacement for
On 25 March 2014 09:01, Chris Angelico ros...@gmail.com wrote:
So by that model, current 2.7 is fully compliant, and anything that
doesn't actively conflict with that is also compliant. Any script that
is written for the current 2.7 is guaranteed also to run on any
compliant SEPython; and
On Tue Mar 25 2014 at 4:21:51 AM, Georg Brandl g.bra...@gmx.net wrote:
Am 25.03.2014 08:51, schrieb Nick Coghlan:
I think that calling it Python 2.8 would be a bad idea for the reasons
that have already been stated.
Perhaps it should just be called Python 2.7 Enhanced Security (Python
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
Sent from my iPhone
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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.
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) where
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
On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com wrote:
As long as we make it clear we have chosen to change our
backwards-compatibility guarantees in the name of security and have a link
to the last backwards-compatible release then I agree as well.
I am not sure how this meme got started,
Hi,
On core-mentorship someone asked about PEP 3145 - Asynchronous I/O for
subprocess.popen. I answered that asyncio now has subprocess support
(including non-blocking I/O on the three standard stream pipes), so
it's not obvious anything else is needed.
Should we change the PEP's status to
Am 25.03.2014 23:15, schrieb Nick Coghlan:
On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com
mailto:bcan...@gmail.com wrote:
As long as we make it clear we have chosen to change our
backwards-compatibility guarantees in the name of security and have a link to
the last
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 26 Mar 2014 08:32, Georg Brandl g.bra...@gmx.net wrote:
Am 25.03.2014 23:15, schrieb Nick Coghlan:
On 26 Mar 2014 01:19, Brett Cannon bcan...@gmail.com
mailto:bcan...@gmail.com wrote:
As long as we make it clear we have chosen to change our
backwards-compatibility guarantees in the
On 26 Mar 2014 08:22, Antoine Pitrou solip...@pitrou.net wrote:
Hi,
On core-mentorship someone asked about PEP 3145 - Asynchronous I/O for
subprocess.popen. I answered that asyncio now has subprocess support
(including non-blocking I/O on the three standard stream pipes), so
it's not
That would be a rather strong unilateral decision. Why don't you ask the
authors? In theory the PEP's proposals could serve in situations where
asyncio isn't appropriate, and asyncio's subprocess I/O isn't the smoothest
API imaginable. (In practice I'm not sure if the PEP would have been
written
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
On Tue, 25 Mar 2014 16:14:04 -0700
Guido van Rossum gu...@python.org wrote:
That would be a rather strong unilateral decision. Why don't you ask the
authors? In theory the PEP's proposals could serve in situations where
asyncio isn't appropriate, and asyncio's subprocess I/O isn't the smoothest
Okay, I included that last round of comments (from late February).
Barring typos, this should be the final version.
Final comments?
-
PEP: 461
Title: Adding % formatting to bytes and bytearray
Version: $Revision$
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
On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath nikol...@rath.org wrote:
2. Change the behavior immediately, potentially breaking some
applications that worked around it, but unbreaking others that relied
on the documented behavior.
If it's a functionality change that's likely to break
%s is a string.
%U is unicode?
If so, then %s should only be used when it is certain the string in question
has no unicode in it?
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
I love it.
On Tue, Mar 25, 2014 at 6:37 PM, Ethan Furman et...@stoneleaf.us wrote:
Okay, I included that last round of comments (from late February).
Barring typos, this should be the final version.
Final comments?
On 3/25/2014 6:15 PM, Nick Coghlan wrote:
I am not sure how this meme got started, but let me be clear: the
proposed policy DOES NOT provide blanket permission to break backwards
compatibility in the affected modules. It only allows ADDING new
features to bring these modules into line with
Chris Angelico ros...@gmail.com writes:
On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath nikol...@rath.org wrote:
2. Change the behavior immediately, potentially breaking some
applications that worked around it, but unbreaking others that relied
on the documented behavior.
If it's a
44 matches
Mail list logo
