ASCII
compatible segments, and it's directly analogous to the handling of
the numeric formatting codes with (b"%a" % obj) being a shorthand for
(b"%s" % ("%a" % obj).encode("ascii")). (Note that invoking repr() or
ascii() on a bytes instance is perfe
On 25 Feb 2014 05:44, "Antoine Pitrou" wrote:
>
> On Mon, 24 Feb 2014 10:40:46 -0800
> Ethan Furman wrote:
>
> > Okay, types corrected, most comments taken into account.
> >
> > %b is right out, %a is still suffering scrutiny.
> >
> > The arguments seem to boil down to:
> >
> > We don't need it.
> Python 2.7 to 3.2 will need a security release, though.
Agreed.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsub
did in Python 2), so some of us think %a *should* be
allowed for consistency with text interpolation, both because there's
no compelling reason to disallow it and because it's the obvious way
to interpolate representations of arbitrary objects into binary
formats that contain ASCII compat
On 25 Feb 2014 23:09, "Maciej Fijalkowski" wrote:
>
> On Tue, Feb 25, 2014 at 3:06 PM, Chris Angelico wrote:
> > On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski
wrote:
> >>> Last issues:
> >>> - hash DoS
> >>
> >> is this fixed?
> >
> > Yes, hash randomization was added as an option in 2.7.
On 25 Feb 2014 23:23, "Donald Stufft" wrote:
>
>
> On Feb 25, 2014, at 8:17 AM, Antoine Pitrou wrote:
>
> > On Tue, 25 Feb 2014 08:08:09 -0500
> > Donald Stufft wrote:
> >>
> >> Hash randomization is broken and doesn't fix anything.
> >
> > Not sure what you mean with "doesn't fix anything". Has
On 26 Feb 2014 04:51, "Antoine Pitrou" wrote:
>
> On Tue, 25 Feb 2014 20:38:46 +0200
> Maciej Fijalkowski wrote:
> >
> > My impression is that a lot of discussion went into hash
> > randomization, because it was a high profile issue. It got "fixed",
> > then later someone discovered that the fix
> --
>
> @@ -1512,6 +1523,12 @@
>object allocator have been silenced. (Contributed by Dhiru Kholia in
>:issue:`18596`.)
>
> +* New function :c:func:`Py_SetStandardStreamEncoding` allows an
application
> + that is embedding Python to do the equivalent of setting
On 26 February 2014 13:57, Stephen J. Turnbull wrote:
> Nick Coghlan writes that b'%a' is
>
> > the obvious way to interpolate representations of arbitrary objects
> > into binary formats that contain ASCII compatible segments.
>
> The only argument that I have
On 27 Feb 2014 04:28, "Antoine Pitrou" wrote:
>
> On Wed, 26 Feb 2014 11:40:01 +0200
> Serhiy Storchaka wrote:
>
> > There were several suggestions for naming new macros which replace old
> > value with new value and then (x)decref old value.
> >
> > #define Py_XXX(ptr, value)\
> > {
On 27 Feb 2014 08:07, "Tim Delaney" wrote:
>
> On 27 February 2014 05:53, Terry Reedy wrote:
>>
>>
>> PSF acts as an umbrella organization for multiple Python projects
>> https://wiki.python.org/moin/SummerOfCode/2014
>> Core Python is the first listed of about 15.
>
>
> I'm guessing Mercurial wi
ng out those examples, I actually like that version (where the
parentheses are still mandatory, but the left paren is after the
except keyword rather than before the first expression) better than
the one currently in the PEP. It also avoids the weirdly unbalanced
look of the variant that had the left par
On 28 Feb 2014 05:56, "Chris Angelico" wrote:
>
> On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman
wrote:
> > +1
> >
> > f() except ((TypeError, AttributeError): "No value")
> >
> > is a nice extension to the idea of
> >
> > value = expr except (
> > Exception1: default1,
> >
On 28 Feb 2014 19:05, "Larry Hastings" wrote:
>
> On 02/26/2014 11:13 PM, Georg Brandl wrote:
>>
>> Am 26.02.2014 17:09, schrieb Ryan Gonzalez:
>>>
>>> I like Py_DECREF_REPLACE. It gives the impression that it decrefs the
original
>>> and replaces it.
>>
>> Agreed, most other suggestions are not r
only to remind people that there's
definitely precedent for using a colon to separate two subexpressions
inside a larger expression element - it's not *just* used to introduce
suites, even though that is by far the most *common* use case.
Cheers,
Nick.
--
Nick Coghlan | ncog
On 28 February 2014 23:07, Chris Angelico wrote:
> On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan wrote:
>> So I think that on balance, I actually do prefer your current
>> proposal. That said, I do think this is a variant worth discussing
>> explicitly in the PEP, if only
On 1 Mar 2014 01:22, "Barry Warsaw" wrote:
>
> On Feb 28, 2014, at 10:27 PM, Nick Coghlan wrote:
>
> >With the new macro in place, the existing Py_CLEAR(x) macro would be
> >equivalent to Py_SETREF(x, NULL).
> >
> >Originally I was also concerned
r guide to provide a more permanent record of
dicussions like this. That would also be the place to document tricks
like defining a private API to fix a bug in a maintenance release, and
then potentially making that new API public for the next feature
release if it's potentially useful to end
On 4 Mar 2014 07:32, "Larry Hastings" wrote:
>
> On 03/03/2014 05:05 AM, Victor Stinner wrote:
>>
>> 2014-03-03 13:13 GMT+01:00 Larry Hastings :
>>>
>>> I would like to know if the cherry-picking rule still applies for
>>> Python 3.4 final? Can I open an issue if I want to see a changeset in
>>> t
On 4 Mar 2014 08:40, "Mark Lawrence" wrote:
>
> On 03/03/2014 21:38, Nick Coghlan wrote:
>>
>>
>> On 4 Mar 2014 07:32, "Larry Hastings" > <mailto:la...@hastings.org>> wrote:
>> >
>> > On 03/03/2014 05:05 AM, Vic
On 4 Mar 2014 09:49, "Ned Deily" wrote:
>
> In article
> ,
> Nick Coghlan wrote:
> > On 4 Mar 2014 08:40, "Mark Lawrence" wrote:
> > > Will this impact on the decision http://bugs.python.org/issue20846 ?
> > No. I never claimed pip was bug f
On 4 March 2014 13:35, Larry Hastings wrote:
> On 03/03/2014 01:38 PM, Nick Coghlan wrote:
>
> Related question - have you decided yet whether or not to do an rc3?
>
> I ask, as I believe it would be good to give the folks like Mike Bayer and
> Armin Ronacher (who picked up tes
On 4 March 2014 14:20, Larry Hastings wrote:
> On 03/03/2014 07:58 PM, Nick Coghlan wrote:
>
> All of our development guides for testing against trunk are designed
> around running from a Mercurial checkout - it would *really* be whole
> lot easier for everyone else that is try
On 4 March 2014 16:50, Larry Hastings wrote:
>
> On 03/03/2014 10:23 PM, Nick Coghlan wrote:
>
> But at the moment you're making it
> *hard* for people to test the release,
>
>
> How? How is testing against a tarball fundamentally different from testing
> against
On 4 March 2014 20:16, wrote:
>
> Quoting Nick Coghlan :
>
>> If you don't want to do an rc3 despite the cherry picked changes since
>> rc2, then you need to make it easy for people to test the changes
>> directly from the release branch. An opaque intermit
On 5 Mar 2014 08:15, "Matthias Klose" wrote:
>
> Am 04.03.2014 15:52, schrieb Brett Cannon:
> > I have also filed http://bugs.python.org/issue20851 to make sure the
> > devguide covers running tests from a tarball. If the way the release has
> > been handled has still bugged you enough it can be d
On 5 Mar 2014 12:48, "Larry Hastings" wrote:
>
> On 03/04/2014 03:59 PM, Barry Warsaw wrote:
>>
>> I too would like an rc3, especially to see if issue 19021 can be fixed,
which
>> I suspect will hit a lot of people.
>
>
> I talked to the other guys on the 3.4 team, and we're all willing to do
an r
On 6 Mar 2014 01:32, "Antoine Pitrou" wrote:
>
> Le 05/03/2014 03:46, Larry Hastings a écrit :
>
>> On 03/04/2014 03:59 PM, Barry Warsaw wrote:
>>>
>>> I too would like an rc3, especially to see if issue 19021 can be fixed,
which
>>> I suspect will hit a lot of people.
>>
>>
>> I talked to the oth
On 6 Mar 2014 02:43, "Antoine Pitrou" wrote:
>
> Le 05/03/2014 17:37, Victor Stinner a écrit :
>
>>
>> Python 3.4 introduced frame.clear(), but frame.clear() raises an
>> RuntimeError if the frame is still running. And it doesn't break all
>> reference cycles.
>>
>> An obvious workaround is to sto
On 6 Mar 2014 08:32, "Yury Selivanov" wrote:
>
>
> On 2014-03-05, 4:54 PM, Nick Coghlan wrote:
>>
>> On 6 Mar 2014 02:43, "Antoine Pitrou" wrote:
>>>
>>> Le 05/03/2014 17:37, Victor Stinner a écrit :
>>>
>>>> Pytho
On 6 Mar 2014 23:44, "Antoine Pitrou" wrote:
>
> Le 05/03/2014 23:53, Nick Coghlan a écrit :
>>
>>
>> __traceback__ wouldn't change [...]
>
>
> Uh, really? If you want to suppress all reference cycles, you *have* to
remove __traceback__.
>
&g
On 7 March 2014 21:00, Larry Hastings wrote:
>
>
> It's published here:
>
> http://hg.python.org/releasing/3.4/
Thanks for that Larry - commits and NEWS for the pip bundling, pkgutil
and inspect changes all look good to me :)
Cheers,
Nick.
--
Nick Coghlan |
re doubly indirect - help() uses pydoc
which uses inspect, and inspect saw a lot of changes.
I'll make a few updates to the What's New to help make the
consequences of this clearer.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
some discussion of the "private" variable question at
https://programmers.stackexchange.com/questions/143736/why-do-we-need-private-variables
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-De
that
doesn't end up in gc.garbage. Are you sure there are no external
references to one of the objects in the cycle, thus keeping the whole
thing alive?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Pyt
that
> +controls whether or not :class:`~venv.EnvBuilder` ensures that ``pip`` is
> +installed in the virtual environment. (Contributed by Nick Coghlan in
> +:issue:`19552` as part of the :pep:`453` implementation.)
> +
>
> wave
>
> @@ -1772,6 +1778,11 @@
>t
On 10 Mar 2014 11:36, "r.david.murray" wrote:
>
> http://hg.python.org/cpython/rev/2d5544afb510
> changeset: 89547:2d5544afb510
> user:R David Murray
> date:Sun Mar 09 20:33:35 2014 -0400
> summary:
> whatsnew: 'U' mode deprecation (#15204).
>
> files:
> Doc/whatsnew/3.4.rst
On 10 Mar 2014 19:50, "Victor Stinner" wrote:
>
> Hi,
>
> I tested Python 3.4rc3 installer on Windows:
>
> - all menu entries work (doc, doc server, help, IDLE, command line, etc.)
> - pip is installed, yeah!
> - my tracemalloc module works on Windows too ;-)
> - The uninstaller fully removes C:\P
On 10 Mar 2014 19:15, "Jurko Gospodnetić" wrote:
>
> Hi all.
>
> Python 3.4 introduced a change to Lib/importlib/__init__.py that added
the following code to it:
>
>> else:
>> # importlib._bootstrap is the built-in import, ensure we don't create
>> # a second copy of the module.
>>
On 10 Mar 2014 23:26, "Antoine Pitrou" wrote:
>
> On Mon, 10 Mar 2014 23:09:53 +1000
> Nick Coghlan wrote:
> > On 10 Mar 2014 11:36, "r.david.murray"
wrote:
> > >
> > > +* The ``U`` mode accepted by various ``open`` functions is
deprecate
On 11 Mar 2014 01:44, "Brett Cannon" wrote:
>
>
>
> On Mon Mar 10 2014 at 11:41:27 AM, Jurko Gospodnetić <
jurko.gospodne...@pke.hr> wrote:
>>
>>Hi Nick.
>>
>> On 10.3.2014. 14:25, Nick Coghlan wrote:> What is supposed to
compiled Windows docs.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/op
igration guide (i.e. people that read it a while ago should read
it again), as well as the restoration of the binary and text transform
codec aliases. Sound reasonable?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Py
On 12 Mar 2014 02:21, "Eric V. Smith" wrote:
>
> On 3/11/2014 9:05 AM, Victor Stinner wrote:
> > 2014-03-11 13:28 GMT+01:00 Nick Coghlan :
> >> I was thinking of adding a new "Migrating from Python 2" section at
> >> the end of the porting gui
ly does it become a useful resource if anyone else
comes forward with a similar proposal, it becomes something we can
point to and perhaps revisit next time someone asks for implicit
exception handling to be added to yet another API :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.c
nto the new site yet, so
they're hitting the redirect to the legacy site.
I opened https://github.com/python/pythondotorg/issues/297 to ask for
an ETA on when we can expect them to be fully integrated.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.
d the Python 3 version of the packages:
https://bugzilla.redhat.com/show_bug.cgi?id=1045780
(Some guidelines on handling that problem are at
https://fedoraproject.org/wiki/Packaging:Python if anyone familiar
with RPM and keen to see that fixed feels like taking a shot at the
problem)
Cheers,
N
with only changes that could be counted as bug fixes anyway) is still
the one we expect to be typical for provisional modules.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@py
At the moment, there's no real way for newcomers to pick up those
principles other than hanging around long enough to see them come up
again.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Pyt
On 16 March 2014 09:00, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> On 16 March 2014 01:40, Guido van Rossum wrote:
>>
>>> This downside of using subclassing as an API should be well known by now
>>> and
>>> widely warned against.
>>
contributed
to the many fine changes in this release :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsub
On 18 Mar 2014 07:37, "Victor Stinner" wrote:
>
> Hi,
>
> I modified the Misc/NEWS file:
>
> * I moved 3.3 sections to Misc/HISTORY: items were already present,
> but the format in Misc/NEWS was improved (changeset 6ba468d4fa96)
> * I removed 3.4.1 section: changes of 3.4 after 3.4.0 must already
On 18 Mar 2014 11:56, "Victor Stinner" wrote:
>
> Hi,
>
> I modified Python 3.5 to use the "surrogateescape" error handler (PEP
> 383) for stdin and stdout when the LC_CTYPE locale is POSIX ("C"
> locale):
> http://bugs.python.org/issue19977
Yay, thanks Victor. I'll let the Fedora folks know this
sonable.
For an optimisation that actually changes the language semantics like
that, though, I would expect it to be buying a significant payoff in
speed, especially given that most cases where the key lookup is known
to be a bottleneck can already be optimised by hand.
Cheers,
Nick.
--
On 18 March 2014 19:13, Victor Stinner wrote:
> 2014-03-18 9:08 GMT+01:00 Nick Coghlan :
>> On 18 Mar 2014 11:56, "Victor Stinner" wrote:
>>>
>>> Hi,
>>>
>>> I modified Python 3.5 to use the "surrogateescape" error handler (PEP
&g
On 19 Mar 2014 05:10, "Larry Hastings" wrote:
>
> On 03/18/2014 12:05 PM, Georg Brandl wrote:
>>
>> Am 18.03.2014 19:29, schrieb Serhiy Storchaka:
>>>
>>> 26.02.14 11:40, Serhiy Storchaka написав(ла):
Let's choose the least confusing names.
See discussions at:
http://
On 19 Mar 2014 07:34, "MRAB" wrote:
> FWIW, I haven't been following the discussion,
Note that this about correctness, not just clarity - using DECREF on member
attributes is not safe, as you may end up exposing a partially destroyed
object to other code.
> but, after a (very)
> quick look, to m
at irritates people about C/C++ optimisers), but
I also think it's a defensible optimisation if the gain is significant
enough.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@p
On 20 Mar 2014 02:37, "Stephen J. Turnbull" wrote:
>
> Kevin Modzelewski writes:
>
> > Sorry, I definitely didn't mean to imply that this kind of
> > optimization is valid on arbitrary subscript expressions; I thought
> > we had restricted ourselves to talking about builtin dicts.
>
> Ah, maybe
On 20 Mar 2014 07:38, "Nick Coghlan" wrote:
>
> Correct, but I think this discussion has established that "how many times
dict lookup calls __eq__ on the key" is one such thing. In CPython, it
already varies based on:
>
> - dict contents (due to the identity check
On 20 Mar 2014 06:24, "Antoine Pitrou" wrote:
>
> On Wed, 19 Mar 2014 19:32:50 +
> Brett Cannon wrote:
> > >
> > > In http://bugs.python.org/issue19359#msg213530 I proposed to
introduce a
> > > "proxy
> > > protocol" (__proxy__ / tp_proxy) that would be used as a fallback by
> > > _PyObject_L
On 20 Mar 2014 10:34, "Steven D'Aprano" wrote:
>
> On Wed, Mar 19, 2014 at 11:01:39PM +0100, Antoine Pitrou wrote:
> > On Thu, 20 Mar 2014 07:54:39 +1000
> > Nick Coghlan wrote:
> > >
> > > Graeme Dumpleton has also subsequently written a libra
On 20 March 2014 17:17, Larry Hastings wrote:
> On 03/19/2014 08:49 PM, Nick Coghlan wrote:
>
> I had vague plans to bug Graham (yay, spelling!) about proposing wrapt for
> inclusion in 3.5 (possibly split between functools and types rather than as
> a completely new module, t
On 22 March 2014 04:48, Maciej Fijalkowski wrote:
> at the end of the day we settled for dicts with str int or identity
> keys, so we're perfectly safe
Ah, Armin's original investment in PyPy's type tracking infrastructure
pays off yet again :)
Cheers,
Nick.
--
Nic
ave a traceback for the failed imports? There were certainly
non-trivial changes to the import system in 3.4, but without knowing
more details about the failures, it's hard to say what the culprits
might be.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
e one way or the other in terms of
the overall proposal.
Full PEP included inline below, and available in more readable form at
http://www.python.org/dev/peps/pep-0466/
Regards,
Nick.
PEP: 466
Title: Network Security Enhancement Exception for All Branches
Version: $Revision$
Last-Modified: $D
On 23 March 2014 08:14, "Martin v. Löwis" wrote:
> Am 22.03.14 22:11, schrieb Nick Coghlan:
>
> Finally, doing this in the 2.7 branch likely involves more effort
> than I'm personally willing to provide.
Believe me, I'll be escalating these concerns at work this
ug fix)
> - all bug fix branches
>
> Clarification of this is just a minor nit, though - although the
> maintainers of the old maintenance branches should (IMO) have a say
> whether they accept a certain change on a certain branch.
Both good points, I'll cl
chains of the
risks of failing to invest development time in any upstream
dependencies that they expect to keep pace with the dynamic nature of
the internet.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev ma
On 23 March 2014 08:40, "Martin v. Löwis" wrote:
> Am 22.03.14 23:33, schrieb Nick Coghlan:
>> Hard to maintain legacy software is a fact of life, and way too much
>> of it is exposed to the public internet. This PEP is about doing what
>> we can to mitigate
can simply declare a dependency on ssl2, instead of saying "we
> require Python 2.7.7+, 3.2.6+, etc".
There's a reason the developers of those libraries haven't already
done that: it's genuinely hard. It's not that I didn't think of this
approach, it's th
On 23 March 2014 07:32, Benjamin Peterson wrote:
> On Sat, Mar 22, 2014, at 14:11, Nick Coghlan wrote:
>> Folks,
>>
>> I have just posted a proposal to change the way we treat enhancements
>> that relate to Python's support for network security enhancements.
use new dependencies from pip". They're not
disjoint sets (plenty of folks use the CentOS system Python + pip),
but I expect there's a large enough population of conservative
corporate users on older versions that won't use a pip based solution
even if its available, thus not
On 23 Mar 2014 10:18, "Christian Heimes" wrote:
>
> On 23.03.2014 01:01, Antoine Pitrou wrote:
> > This is a bit limited. There are remotely-exploitable security issues
> > which are still open on the bug tracker; they are not
> > cryptography-related, but that shouldn't make a difference.
> >
> >
plicitly trying to make the case that a PyPI
backport would be simpler for the overall ecosystem than my suggested
approach.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@pyth
ilitating the migration to Python 3, helping
to improve the networking security situation in Python 2, or,
preferably, both.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@pyt
On 23 Mar 2014 11:47, "Donald Stufft" wrote:
>
>
> On Mar 22, 2014, at 9:33 PM, Brett Cannon wrote:
>
>>
>>
>> On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan
wrote:
>>>
>>> On 23 March 2014 10:08, Antoine Pitrou wrote:
>>&g
longer.
It was already a rather busy month before I decided to start this
discussion on top of everything else :)
Cheers,
Nick.
PEP: 466
Title: Network Security Enhancement Exception for Python 2.7
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ,
Status: Draft
Type: Informational
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
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 strat
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 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 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
ound 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 the line).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Bri
===
PEP: 466
Title: Network Security Enhancement Exception for Python 2.7
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ,
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Mar-2014
Post-History: 23-Mar-2014
Abstract
Most
icy in the PEP independently of upstream, and that's not a good
outcome for anyone.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailm
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 combin
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" polic
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 change
On 25 March 2014 12:25, MRAB wrote:
> 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" > <mail
On 25 March 2014 09:04, Donald Stufft wrote:
> On Mar 24, 2014, at 5:38 PM, Nick Coghlan 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 the
://www.python.org/dev/peps/pep-0466/
===
PEP: 466
Title: Network Security Enhancement Exception for Python 2.7
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ,
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Mar-2014
Post-History: 23-Mar-201
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 Wi
On 26 Mar 2014 01:19, "Brett Cannon" 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, but let me be c
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
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 instinctivel
On 26 Mar 2014 08:32, "Georg Brandl" wrote:
>
> Am 25.03.2014 23:15, schrieb Nick Coghlan:
> >
> > On 26 Mar 2014 01:19, "Brett Cannon" > <mailto:bcan...@gmail.com>> wrote:
> >> As long as we make it clear we have chosen to chang
On 26 Mar 2014 08:22, "Antoine Pitrou" 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 obvious anythi
ement Exception for Python 2.7
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ,
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Mar-2014
Post-History: 23-Mar-2014, 24-Mar-2014, 25-Mar-2014, 26-Mar-2014
Abstract
Most CPython tracker issues are classifi
he use of feature based checks, it is designed to make it
easier to write more secure cross-version compatible Python software,
while still limiting the risk of breaking currently working software
when upgrading to a new Python 2.7 maintenance release.
===
Cheers,
Nick.
1301 - 1400 of 6587 matches
Mail list logo
