Re: [Python-Dev] Python 2.7 patch levels turning two digit
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
Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7
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
Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7
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
Re: [Python-Dev] Binary CPython distribution for Linux
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]
Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
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``
Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
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
Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
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
Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
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 | [email protected] | Brisbane, Australia ___
Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
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
Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
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 | [email protected] | Brisbane, Australia __
Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
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
Re: [Python-Dev] PEP 471 -- os.scandir() function -- a better and faster directory iterator
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.>> _
Re: [Python-Dev] My summary of the scandir (PEP 471)
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
Re: [Python-Dev] My summary of the scandir (PEP 471)
her than getting ugly, hard to track down bugs later. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe
Re: [Python-Dev] Network Security Backport Status
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
Re: [Python-Dev] My summary of the scandir (PEP 471)
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
Re: [Python-Dev] buildbot.python.org down again?
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
Re: [Python-Dev] == on object tests identity in 3.x - summary
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
Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
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
Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
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>> "
Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
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
Re: [Python-Dev] PEP 3121, 384 Refactoring Issues
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
Re: [Python-Dev] == on object tests identity in 3.x - list delegation to members?
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
Re: [Python-Dev] == on object tests identity in 3.x - list delegation to members?
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
Re: [Python-Dev] Another case for frozendict
tionaries (think stuff deserialised from JSON) than namedtuple does. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-d
Re: [Python-Dev] Remaining decisions on PEP 471 -- os.scandir()
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
Re: [Python-Dev] PEP 3121, 384 Refactoring Issues
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
Re: [Python-Dev] Remaining decisions on PEP 471 -- os.scandir()
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
Re: [Python-Dev] cStringIO vs io.BytesIO
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
Re: [Python-Dev] Remaining decisions on PEP 471 -- os.scandir()
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
Re: [Python-Dev] PEP 471 "scandir" accepted
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
Re: [Python-Dev] [PEP466] SSLSockets, and sockets, _socketobjects oh my!
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)?>>
Re: [Python-Dev] [PEP466] SSLSockets, and sockets, _socketobjects oh my!
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
Re: [Python-Dev] Does Zip Importer have to be Special?
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
Re: [Python-Dev] Does Zip Importer have to be Special?
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
Re: [Python-Dev] Contribute to Python.org
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.
Re: [Python-Dev] Exposing the Android platform existence to Python modules
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
Re: [Python-Dev] Surely "nullable" is a reasonable name?
On 4 Aug 2014 18:16, "Oleg Broytman" wrote:>> Hi!>> On Mon, Aug 04, 2014 at 05:12:47PM +1000, Larry Hastings < [email protected]> wrote:>> "nullable=True", which means "also accept None>> for this parameter". This was originally intended for use with>> strings (compare the "s" and "z"
Re: [Python-Dev] os.walk() is going to be *fast* with scandir
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 | [email protected] | Brisbane, Australia ___ Python-
Re: [Python-Dev] sum(...) limitation
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.
Re: [Python-Dev] Multiline with statement line continuation
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:>
Re: [Python-Dev] sum(...) limitation
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
Re: [Python-Dev] Multiline with statement line continuation
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
Re: [Python-Dev] Reviving restricted mode?
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
Re: [Python-Dev] Documenting enum types
the use case for exposing and documenting the enum types themselves (although I don't have any real objection either). Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] ht
[Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
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
Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
= 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日
Re: [Python-Dev] Multiline with statement line continuation
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 | [email protected] | Brisbane, Australi
[Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
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
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
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
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
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 | [email protected] | Brisbane, Australia __
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
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
Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
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
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
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
Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
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
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
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() > > > &
Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
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
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
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"
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
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
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
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
Re: [Python-Dev] Bytes path support
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
Re: [Python-Dev] Bytes path support
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
Re: [Python-Dev] Bytes path support
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
Re: [Python-Dev] Bytes path support
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:[email protected]>> wrote: >>> >>> >>> Antoine Pitrou wrote: >>>> >>>
Re: [Python-Dev] Bytes path support
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
Re: [Python-Dev] Bytes path support
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
Re: [Python-Dev] Bytes path support
[email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing
Re: [Python-Dev] Bytes path support
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
Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)
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
Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)
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
Re: [Python-Dev] Bytes path support
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
Re: [Python-Dev] Bytes path support
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
[Python-Dev] Bytes path related questions for Guido
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
Re: [Python-Dev] Bytes path related questions for Guido
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
Re: [Python-Dev] Bytes path related questions for Guido
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
Re: [Python-Dev] Bytes path related questions for Guido
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 >>
[Python-Dev] Fwd: Accepting PEP 440: Version Identification and Dependency Specification
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
Re: [Python-Dev] Bytes path support
On 27 Aug 2014 02:52, "Terry Reedy" wrote: > > On 8/26/2014 9:11 AM, R. David Murray wrote: >> >> On 2014年8月24日 13:27:55 +1000, Nick Coghlan wrote: >>> >>> As some examples of where bilingual computing breaks down: >>> >>&g
Re: [Python-Dev] Windows Unicode console support [Was: Bytes path support]
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
Re: [Python-Dev] Bytes path support
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
Re: [Python-Dev] Bytes path support
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
[Python-Dev] Cleaning up surrogate escaped strings (was Bytes path related questions for Guido)
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. >> >> &
Re: [Python-Dev] Cleaning up surrogate escaped strings (was Bytes path related questions for Guido)
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')
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
On 31 August 2014 12:21, R. David Murray wrote: > On 2014年8月31日 03:25:25 +0200, Antoine Pitrou > wrote: >> On 2014年8月31日 09:26:30 +1000 >> Nick Coghlan wrote: >> > In relation to changing the Python CLI API to offer some of the wget/curl >> > st
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
[Python-Dev] PEP 477: selected ensurepip backports for Python 2.7
. == 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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7
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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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",
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7
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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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
Re: [Python-Dev] PEP 476: Enabling certificate validation by default!
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 >>
Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
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 | [email protected] | Brisbane, Australia ___