On 24 Jun 2014 07:29, "Donald Stufft" wrote:
>
>
> On Jun 23, 2014, at 5:22 PM, Barry Warsaw wrote:
>
> > On Jun 23, 2014, at 05:15 PM, Donald Stufft wrote:
> >
> >> Normally when I see someone suggest that switching compilers
> >> in 2.7.x is likely to be less work than releasing a 2.8 It normal
On 25 Jun 2014 07:05, "Ethan Furman" wrote:
>
> On 06/24/2014 12:54 PM, Ned Deily wrote:
>>
>>
>> Yes, we are committed to maintaining
>> Python 2.7 for multiple years but that doesn't mean we have to fix every
>> open issue or even most open issues. Any or all of the above costs may
>> apply to
On 26 Jun 2014 01:13, "Serhiy Storchaka" wrote:
>
> 25.06.14 16:29, Victor Stinner написав(ла):
>>
>> 2014-06-25 14:58 GMT+02:00 Serhiy Storchaka :
>>>
>>> Other benefit: patches exposed several bugs in code (mainly errors in
>>> backporting from 3.x).
>>
>>
>> Oh, interesting. Do you have example
On 27 Jun 2014 17:33, "Bohuslav Kabrda" wrote:
>
> It's not true that 2.7 wasn't released until few weeks ago. It was
released few weeks ago as part of RHEL 7, but Red Hat has been shipping Red
Hat Software Collections (RHSCL) 1.0, that contain Python 2.7 and Python
3.3, for almost a year now [1]
On 28 Jun 2014 01:27, "Jonas Wielicki" wrote:
>
> On 27.06.2014 00:59, Ben Hoyt wrote:
> > Specifics of proposal
> > =
> > [snip] Each ``DirEntry`` object has the following
> > attributes and methods:
> > [snip]
> > Notes on caching
> >
> >
> > The ``DirEntry``
On 28 June 2014 19:17, Nick Coghlan wrote:
> Agreed, but walking even a moderately large tree over the network can
> really hammer home the point that this offers a significant
> performance enhancement as the latency of access increases. I've found
> that kind of comparison c
On 28 June 2014 16:17, Gregory P. Smith wrote:
> On Fri, Jun 27, 2014 at 2:58 PM, Nick Coghlan wrote:
>> * it would be nice to see some relative performance numbers for NFS and
>> CIFS network shares - the additional network round trips can make excessive
>> stat calls abs
ary level stat caching is "it's not
clear if there's an available approach that would be sufficiently
general purpose to be appropriate for inclusion in the standard
library".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
benchmarks,
> including one over NFS, on the scandir GitHub page:
>
> https://github.com/benhoyt/scandir#benchmarks
No, I hadn't seen those - may be worth referencing explicitly from the
PEP (and if there's already a reference... oops!)
> os.walk() was 23 times faster wi
tat call. Caching behaviour is *really*
hard to make intuitive, especially when it *sometimes* returns data
that looks fresh (as it on first call on POSIX systems).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 29 June 2014 21:45, Paul Moore wrote:
> On 29 June 2014 12:08, Nick Coghlan wrote:
>> This is what makes me wary of including lstat, even though Windows
>> offers it without the extra stat call. Caching behaviour is *really*
>> hard to make intuitive, especially when i
On 30 Jun 2014 19:13, "Glenn Linderman" wrote:
>
>
> If it is, use ensure_lstat=False, and use the proposed (by me) .refresh()
API to update the data for those that need it.
I'm -1 on a refresh API for DirEntry - just use pathlib in that case.
Cheers,
Nick.
>
> _
On 1 Jul 2014 07:31, "Victor Stinner" wrote:
>
> 2014-07-01 15:00 GMT+02:00 Ben Hoyt :
> > 2) Nick Coghlan's proposal on the previous thread
> > (https://mail.python.org/pipermail/python-dev/2014-June/135261.html)
> > suggesting an ensure_lstat keyword param to scandir if you need the
> > lstat_r
her than getting ugly, hard to track down bugs later.
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
On 1 Jul 2014 11:28, "Alex Gaynor" wrote:
>
> I've come up with a new approach, which I believe is most likely to be
> successful, but I'll need help to implement it.
>
> The idea is to find the most recent commit which is a parent of both the
> ``2.7`` and ``default`` branches. Then take every si
ime
> # Ignore file_attributes, as we'll never get here on Windows
> yield entry
>
> Variations on how you handle errors in the lstat call, etc, can be
> added to taste.
>
> Please, let's stick to a low-level wrapper round the OS API for th
On 7 Jul 2014 10:47, "Guido van Rossum" wrote:
>
> It would still be nice to know who "the appropriate persons" are. Too
much of our infrastructure seems to be maintained by house elves or the ITA.
I volunteered to be the board's liaison to the infrastructure team, and
getting more visibility aro
On 7 Jul 2014 19:22, "Andreas Maier" wrote:
>
> Thanks to all who responded.
>
> In absence of class-specific equality test methods, the default
implementations revert to use the identity (=address) of the object as a
basis for the test, in both Python 2 and Python 3.
>
> In absence of specific or
On 9 Jul 2014 17:14, "Ethan Furman" wrote:
>
> On 07/09/2014 02:42 PM, Ben Hoyt wrote:
>>>
>>>
>>> Okay, so using that [no platform specific] logic we should head over to
the os module and remove:
>>>
>>>
>>> ctermid, getenv, getegid...
>>>
>>> Okay, I'm tired of typing, but that list is not even
On 10 Jul 2014 03:39, "Victor Stinner" wrote:
>
> 2014-07-10 9:04 GMT+02:00 Paul Moore :
> > As someone (Tim?) pointed out later in the thread,
> > FindFirstFile/FindNextFile doesn't follow symlinks by default (and nor
> > do the dirent entries on Unix). So whether or not it's "natural", the
> > "
On 11 Jul 2014 12:46, "Ben Hoyt" wrote:
>
> [replying to python-dev this time]
>
> >> The "onerror" approach can also deal with readdir failing, which the
> >> PEP currently glosses over.
> >
> >
> > Do we want this, though? I can see an error handler for individual
entries,
> > but if one of th
On 10 Jul 2014 19:59, "Alexander Belopolsky"
wrote:
>
>
> On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence
wrote:
>>
>> I'm just curious as to why there are 54 open issues after both of these
PEPs have been accepted and 384 is listed as finished. Did we hit some
unforeseen technical problem which
match between the
definition of floats and the definition of container invariants like
"assert x in [x]")
The current approach means that the lack of reflexivity of NaN's stays
confined to floats and similar types - it doesn't leak out and infect
the behaviour of the conta
On 13 July 2014 13:16, Chris Angelico wrote:
> On Mon, Jul 14, 2014 at 4:11 AM, Nick Coghlan wrote:
>> What we've never figured out is a good place to *document* it. I
>> thought there was an open bug for that, but I can't find it right now.
>
> Yeah. The Py3 docs
tionaries (think stuff deserialised from JSON) than namedtuple
does.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
On 13 Jul 2014 20:54, "Tim Delaney" wrote:
>
> On 14 July 2014 10:33, Ben Hoyt wrote:
>>
>>
>>
>> If we go with Victor's link-following .is_dir() and .is_file(), then
>> we probably need to add his suggestion of a follow_symlinks=False
>> parameter (defaults to True). Either that or you have to s
On 14 Jul 2014 11:41, "Brett Cannon" wrote:
>
>
> I agree for PEP 3121 which is the initialization/finalization work. The
stable ABi is not necessary. So maybe we should re-examine the patches and
accept the bits that clean up init/finalization and leave out any
ABi-related changes.
Martin's rig
On 14 Jul 2014 22:50, "Ben Hoyt" wrote:
>
> In light of that, I propose I update the PEP to basically follow
> Victor's model of is_X() and stat() following symlinks by default, and
> allowing you to specify follow_symlinks=False if you want something
> other than that.
>
> Victor had one other qu
On 16 Jul 2014 20:00, wrote:
> On Thu, Jul 17, 2014 at 03:44:23AM +0600, Mikhail Korobov wrote:
> > I believe this problem affects tornado (
https://github.com/tornadoweb/tornado/
> > Do you know if there a workaround? Maybe there is some stdlib part that
I'm
> > missing, or a module on PyPI? It i
On 22 Jul 2014 02:46, "Steve Dower" wrote:
>
> Personally I'd make it a string subclass and put one-shot properties on
it (i.e. call/cache stat() on first access where we don't already know the
answer), which I think is close enough to where it's landed that I'm happy.
(As far as bikeshedding goes
On 23 Jul 2014 02:18, "Victor Stinner" wrote:
>
> 2014-07-22 17:52 GMT+02:00 Ben Hoyt :
> > However, given that we have to support this for listdir() anyway, I
> > think it's worth reconsidering whether scandir()'s directory argument
> > can be an integer FD. Given that listdir() already supports
On 23 Jul 2014 07:28, "Antoine Pitrou" wrote:
>
> Le 22/07/2014 17:03, Alex Gaynor a écrit :
>
>>
>> The question is:
>>
>> a) Should we backport weak referencing _socket.sockets (changing the
structure
>> of the module seems overly invasive, albeit completely backwards
>> compatible)?
>>
On 24 Jul 2014 05:37, "Alex Gaynor" wrote:
>
> Possible solutions are:
>
> * Pass the SSLObject *in addition* to the _socket.socket object to the C
code.
> This generates some additional divergence from the Python3 code, but is
> probably basically straightforward.
> * Try to refactor the sock
On 25 Jul 2014 03:51, "Brett Cannon" wrote:
> The problem with all of this is you are essentially asking for a hook to
let you have code have access to the interpreter state before it is fully
initialized. Zipimport and the various bits of code that get loaded during
startup are special since the
On 25 July 2014 19:33, Phil Thompson wrote:
> On 24/07/2014 9:42 pm, Nick Coghlan wrote:
>> As you say, though it's a niche problem compared to something like
>> packaging, which is why it got bumped down my personal priority list. I
>> haven't even got back
pplication now powering
the site), the contribution process is not yet as clear, but the code
and issue tracker are at https://github.com/python/pythondotorg and
https://mail.python.org/mailman/listinfo/pydotorg-www is the relevant
mailing list.
Cheers,
Nick.
--
Nick Coghlan | ncogh.
On 4 Aug 2014 03:18, "Phil Thompson" wrote:
>
> On 03/08/2014 4:58 pm, Guido van Rossum wrote:
>>
>> But *are* we going to support Android officially? What's the point? Do
you
>> have a plan for getting Python apps to first-class status in the App
Store
>> (um, Google Play)?
>
>
> I do...
>
> http
On 4 Aug 2014 18:16, "Oleg Broytman" wrote:
>
> Hi!
>
> On Mon, Aug 04, 2014 at 05:12:47PM +1000, Larry Hastings <
la...@hastings.org> wrote:
> > "nullable=True", which means "also accept None
> > for this parameter". This was originally intended for use with
> > strings (compare the "s" and "z"
proach was just too slow to be useful in practice (at
least when working with trees on the scale of a full Fedora or RHEL
build hosted on an NFS share).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-
On 12 Aug 2014 03:03, "Chris Barker - NOAA Federal"
wrote:
>
> My confusion is still this:
>
> Repeated summation of strings has been optimized in cpython even
> though it's not the recommended way to solve that problem.
The quadratic behaviour of repeated str summation is a subtle, silent
error.
On 12 Aug 2014 09:09, "Allen Li" wrote:
>
> This is a problem I sometimes run into when working with a lot of files
> simultaneously, where I need three or more `with` statements:
>
> with open('foo') as foo:
> with open('bar') as bar:
> with open('baz') as baz:
>
On 12 Aug 2014 11:21, "Chris Barker - NOAA Federal"
wrote:
>
> Sorry for the bike shedding here, but:
>
>> The quadratic behaviour of repeated str summation is a subtle, silent
error.
>
> OK, fair enough. I suppose it would be hard and ugly to catch those
instances and raise an exception pointing
m, eggs & cheese
ExitStack is mostly useful as a tool for writing flexible custom
context managers, and for dealing with context managers in cases where
lexical scoping doesn't necessarily work, rather than being something
you'd regularly use for inline code.
"Why do I ha
e even harder
problem of an in-process sandbox".
"Deny all" sandboxes are relatively easy, but also relatively useless.
It's "allow these activities, but no others" that's difficult, since
any kind of access can often be leveraged into greater access than was
i
the use case for exposing and documenting the enum
types themselves (although I don't have any real objection either).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
ht
URL: http://www.python.org/dev/peps/pep-0467/
Full PEP text:
=
PEP: 467
Title: Minor API improvements for bytes and bytearray
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-03-30
Pyth
=
PEP: 467
Title: Minor API improvements for bytes and bytearray
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-03-30
Python-Version: 3.5
Post-History: 2014-03-30 2014-08-15
it may be time to reach for a better
tool. If the context manager line is getting unwieldy, it's often a
sign it's time to factor it out to a dedicated helper, or break it up
into multiple with statements :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australi
into design decisions we aren't
happy with.
If folks (most signficantly, Guido) are amenable to the idea, it
shouldn't take long to put such a PEP together, and I think it could
help reduce some of the confusions around the expectations for Python
4.0 and the evolution of 3.x in g
On 17 August 2014 12:43, Guido van Rossum wrote:
> On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan wrote:
>> I've also had people express the concern that "you broke compatibility
>> in a major way once, how do we know you won't do it again?".
>
>
> Wel
P 387 accepted yet?
Not sure - it mostly looks correct to me. I suspect it just fell off
the radar since it's a "describe what we're already doing anyway" kind
of document.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 17 August 2014 15:34, Nick Coghlan wrote:
> On 17 August 2014 15:08, Guido van Rossum wrote:
>> I think this would be a great topic for a blog post. Once you've written it
>> I can even bless it by Tweeting about it. :-)
>
> Sounds like a plan - I'll try to
On 17 August 2014 18:13, Raymond Hettinger wrote:
>
> On Aug 14, 2014, at 10:50 PM, Nick Coghlan wrote:
>
> Key points in the proposal:
>
> * deprecate passing integers to bytes() and bytearray()
>
>
> I'm opposed to removing this part of the API. It has pro
On 18 Aug 2014 08:04, "Markus Unterwaditzer"
wrote:
>
> On Sun, Aug 17, 2014 at 05:41:10PM -0400, Barry Warsaw wrote:
> > I think the biggest API "problem" is that default iteration returns
integers
> > instead of bytes. That's a real pain.
>
> I agree, this behavior required some helper function
On 18 Aug 2014 03:07, "Raymond Hettinger"
wrote:
>
>
> On Aug 17, 2014, at 1:41 AM, Nick Coghlan wrote:
>
>> If I see "bytearray(10)" there is nothing there that suggests "this
>> creates an array of length 10 and initialises it to zero&quo
On 18 Aug 2014 08:55, "Barry Warsaw" wrote:
>
> On Aug 18, 2014, at 08:48 AM, Nick Coghlan wrote:
>
> >Calling it bytes is too confusing:
> >
> >for x in bytes(data):
> > ...
> >
> >for x in bytes(data).bytes()
> >
> &
On 18 Aug 2014 09:41, "Raymond Hettinger"
wrote:
>
>
> I encourage restraint against adding an unneeded class method that has no
parallel
> elsewhere. Right now, the learning curve is mitigated because bytes is
very str-like
> and because bytearray is list-like (i.e. the method names have been us
On 18 Aug 2014 09:57, "Barry Warsaw" wrote:
>
> On Aug 18, 2014, at 09:12 AM, Nick Coghlan wrote:
>
> >I'm talking more generally - do you *really* want to be explaining that
> >"bytes" behaves like a tuple of integers, while "bytes.bytes"
ome means of programmatically enforcing that is
interesting - it opens the door to "opportunistic and incremental"
porting, where modules are progressively updated to run on both, until
an application reaches a point where it can switch to Python 3 and
leave Python 2 behind.
Cheers
On 18 August 2014 10:45, Guido van Rossum wrote:
> On Sun, Aug 17, 2014 at 5:22 PM, Barry Warsaw wrote:
>>
>> On Aug 18, 2014, at 10:08 AM, Nick Coghlan wrote:
>>
>> >There's actually another aspect to your idea, independent of the naming:
>> >expos
On 20 Aug 2014 04:18, "Marko Rauhamaa" wrote:
>
> Tres Seaver :
>
> > On 08/19/2014 01:43 PM, Ben Hoyt wrote:
> >> Fair enough. I don't quite understand, though -- why is the "official
> >> policy" to kill something that's "essential" on *nix?
> >
> > ISTM that the policy is based on a fantasy tha
On 21 Aug 2014 08:19, "Greg Ewing" wrote:
>
> Antoine Pitrou wrote:
>>
>> I think if you want low-level features (such as unconverted bytes paths
under POSIX), it is reasonable to point you to low-level APIs.
>
>
> The problem with scandir() in particular is that there is
> currently *no* low-leve
On 21 Aug 2014 09:06, "Chris Barker" wrote:
>
> As I understand it, the whole problem with some posix systems is that
there is NO filesystem encoding -- i.e. you can't know for sure what
encoding a filename is in. So you need to be able to pass the bytes through
as they are.
>
> (At least as I re
On 21 August 2014 09:33, Ethan Furman wrote:
> On 08/20/2014 03:31 PM, Nick Coghlan wrote:
>> On 21 Aug 2014 08:19, "Greg Ewing" > <mailto:greg.ew...@canterbury.ac.nz>> wrote:
>>>
>>>
>>> Antoine Pitrou wrote:
>>>>
>>>
On 21 August 2014 12:16, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > One idea I had along those lines is a surrogatereplace error handler (
> > http://bugs.python.org/issue22016) that emitted an ASCII question mark for
> > each smuggled byte, rather than
ay eventually need to
resolve the technical issues currently preventing us from deciding to
ignore the environmental locale during interpreter startup and try
something different (such as always assuming UTF-8, or trying to force
C.UTF-8 if we detect the C locale, or looking for the systemd config
files an
v@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing
On 22 August 2014 00:12, Nick Coghlan wrote:
> On 21 August 2014 23:58, Marko Rauhamaa wrote:
>>
>> My point is that the poor programmer cannot ignore the possibility of
>> "funny" character sets. If Python tried to protect the programmer from
>> that possi
ents for bugs.python.org were put in place when the
PSF didn't have any on-call system administrators of its own, but now
that we do, it may be time to migrate that service to a location where
we can switch to a more appropriate SSL certificate.
Anyone interested in following the discuss
On 22 Aug 2014 04:45, "Benjamin Peterson" wrote:
>
> Perhaps some board members could comment, but I hope the PSF could just
> pay a few hundred a year for a proper certificate.
That's exactly what we're doing - MAL reminded me we reached the same
conclusion last time this came up, we'll just tra
On 22 Aug 2014 09:24, "Isaac Morland" wrote:
> I think the real tension here is between the POSIX level where filenames
are byte strings (except for \x00, which is reserved for string
termination) where \x2F has special interpretation, and absolutely every
application ever written, in every langua
get back to working on PEP 432 (the rewrite of the interpreter startup
sequence) for Python 3.5. A lot of these things are just plain hard to
change because of the complexity of the current startup code.
Redesigning that to use a cleaner, multiphase startup sequence tha
tring back to bytes and
then decodes it again using the specified encoding (the old encoding
defaults to 'latin-1' to match the assumptions in WSGI)
"s != string.clean(s)" would then serve as a check for "does this
string contain any surrogate escaped bytes?"
[3] http
On 24 August 2014 14:44, Nick Coghlan wrote:
> 2. Should we add some additional helpers to the string module for
> dealing with surrogate escaped bytes and other techniques for
> smuggling arbitrary binary data as text?
>
> My proposal [3] is to add:
>
> * string.escaped_surr
On 25 August 2014 00:23, Antoine Pitrou wrote:
> Le 24/08/2014 09:04, Nick Coghlan a écrit :
>> Serhiy & Ezio convinced me to scale this one back to a proposal for
>> "codecs.clean_surrogate_escapes(s)", which replaces surrogates that
>> may be produ
g): encodes a string back to bytes and
>> then decodes it again using the specified encoding (the old encoding
>> defaults to 'latin-1' to match the assumptions in WSGI)
>>
>> "s != string.clean(s)" would then serve as a check for "does this
>>
ndependent versioning standard derived
from pkg_resources, PEP 386, and ideas from both Linux distributions
and other open source language communities.
Regards,
Nick.
-- Forwarded message ------
From: Nick Coghlan
Date: 22 August 2014 22:34
Subject: Accepting PEP 440: Version Identifi
On 27 Aug 2014 02:52, "Terry Reedy" wrote:
>
> On 8/26/2014 9:11 AM, R. David Murray wrote:
>>
>> On Sun, 24 Aug 2014 13:27:55 +1000, Nick Coghlan
wrote:
>>>
>>> As some examples of where bilingual computing breaks down:
>>>
>>&g
On 27 August 2014 01:23, Paul Moore wrote:
> On 24 August 2014 04:27, Nick Coghlan wrote:
>> One of those areas is the fact that we still use the old 8-bit APIs to
>> interact with the Windows console. Those are just as broken in a
>> multilingual world as the other Windows
On 27 August 2014 08:52, Nick Coghlan wrote:
> On 27 Aug 2014 02:52, "Terry Reedy" wrote:
>> Nick, I think the first half of your post is one of the clearest
>> expositions yet of 'why Python 3' (in particular, the str to unicode
>> change). It is wort
On 28 Aug 2014 04:20, "Glenn Linderman" wrote:
>
> On 8/27/2014 5:16 AM, Nick Coghlan wrote:
>>
>> On 27 August 2014 08:52, Nick Coghlan wrote:
>>>
>>> On 27 Aug 2014 02:52, "Terry Reedy" wrote:
>>>>
>>>> Nick, I
On 26 Aug 2014 21:34, "MRAB" wrote:
>
> On 2014-08-26 03:11, Stephen J. Turnbull wrote:
>>
>> Nick Coghlan writes:
>>
>> > "purge_surrogate_escapes" was the other term that occurred to me.
>>
>> &
On 29 August 2014 10:32, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > The current proposal on the issue tracker is to instead take advantage of
> > the existing error handlers:
> >
> > def convert_surrogateescape(data, errors='replace')
On 30 Aug 2014 06:08, "Ethan Furman" wrote:
>
> On 08/29/2014 01:00 PM, M.-A. Lemburg wrote:
>>
>> On 29.08.2014 21:47, Alex Gaynor wrote:
>>>
>>>
>>> I've just submitted PEP 476, on enabling certificate validation by
default for
>>> HTTPS clients in Python. Please have a look and let me know what
On 31 August 2014 12:21, R. David Murray wrote:
> On Sun, 31 Aug 2014 03:25:25 +0200, Antoine Pitrou
> wrote:
>> On Sun, 31 Aug 2014 09:26:30 +1000
>> Nick Coghlan wrote:
>> > In relation to changing the Python CLI API to offer some of the wget/curl
>> > st
nother barrier to migrating from
Python 2.7 to Python 3.5+ (a warning in Python 3.4 doesn't help with
that aspect, although a new -3 warning might).
A third party module that offers a user level certificate store, and a
gevent.monkey style way of opting in to this behaviour for existing
P
On 31 August 2014 16:16, Donald Stufft wrote:
>
> On Aug 31, 2014, at 2:09 AM, Nick Coghlan wrote:
>
> At the same time, we need to account for the fact that most existing
> organisations still trust in perimeter defence for their internal
> network security, and hence tolerate
On 1 Sep 2014 06:32, "Paul Moore" wrote:
>
> On 31 August 2014 21:15, Antoine Pitrou wrote:
> > What do you call your local cert store?
>
> I was referring to Christian's comment
> > It's very simple to trust a self-signed certificate: just download it
and stuff it into the trust store.
>
> From
.
==
PEP: 477
Title: Backport ensurepip (PEP 453) to Python 2.7
Version: $Revision$
Last-Modified: $Date$
Author: Donald Stufft
Nick Coghlan
Status: Active
Type: Process
Content-Type: text/x-rst
Created: 26-Aug-2014
Post-History: 1-Sep-2014
Abstract
This PEP proposes that the
On 1 Sep 2014 07:43, "Christian Heimes" wrote:
>
> On 31.08.2014 08:09, Nick Coghlan wrote:
> > As Antoine says here, I'm also opposed to adding more Python specific
> > configuration options. However, I think there may be something
> > worthwhile we can do
On 1 Sep 2014 09:23, "Benjamin Peterson" wrote:
>
> On Sun, Aug 31, 2014, at 16:17, Antoine Pitrou wrote:
> > On Mon, 1 Sep 2014 08:00:14 +1000
> > Nick Coghlan wrote:
> > >
> > > That part of the proposal proved to be controversial, so we dropped
it
On 1 Sep 2014 08:15, "Donald Stufft" wrote:
>
>
>> On Aug 31, 2014, at 5:43 PM, Christian Heimes
wrote:
>>
>> Companies could install them in a system global directory on their
>> servers. Users could put them in their own user site directory and even
>> each virtual env can have one sslcustomize
sl
ssl.named_contexts["http.client"] = ssl.create_legacy_context
However, someone that wanted to also enforce SSL properly for other
standard library modules could go the other way:
import ssl
for modname in ("nntplib", "poplib", "imaplib",
On 1 September 2014 16:07, Paul Moore wrote:
> On 31 August 2014 23:10, Nick Coghlan wrote:
>> Assuming sslcustomize was in site-packages rather than the standard library
>> directories, you would also be able to use virtual environments with an
>> appropriate sslcustomize m
On 1 September 2014 17:13, Christian Heimes wrote:
> On 01.09.2014 08:44, Nick Coghlan wrote:
>> Yes, it would have exactly the same security failure modes as
>> sitecustomize, except it would only fire if the application
>> imported the ssl module.
>>
>> The &qu
On 1 Sep 2014 17:31, "Donald Stufft" wrote:
>
>
>> On Sep 1, 2014, at 2:22 AM, Ned Deily wrote:
>>
>>
>> And that is a minor complication compared with the confusion and
>> difficulty of trying to explain to users (stuck with 2.7 for the time
>> being) of how to install third-party packages on ea
On 2 Sep 2014 00:08, "Antoine Pitrou" wrote:
>
> On Mon, 1 Sep 2014 23:42:10 +1000
> Chris Angelico wrote:
> > >>
> > >> That has to be done inside the same process. But imagine this
> > >> scenario: You have a program that gets invoked as root (or some other
> > >> user than yourself), and you'r
On 2 Sep 2014 00:59, "Antoine Pitrou" wrote:
>
> On Tue, 2 Sep 2014 00:53:11 +1000
> Nick Coghlan wrote:
> > >
> > > To be frank I don't understand what you're arguing about.
> >
> > When I said "shadowing ssl can be tricky to
On 2 Sep 2014 03:08, "Donald Stufft" wrote:
>
>
>> On Sep 1, 2014, at 1:01 PM, Christian Heimes
wrote:
>>
>> On 01.09.2014 17:35, Nick Coghlan wrote:
>>>
>>> Oh, now I get what you mean - yes, sitecustomize already poses the same
>>
ely_ on the existing behaviour; it would just become very slow to
> exit.)
Making an exception for sleep() (i.e. still letting it throw EINTR)
sounds like a reasonable idea to me.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
1 - 100 of 6587 matches
Mail list logo
