Re: [Python-Dev] Python 2.7 patch levels turning two digit

Le 23/06/2014 15:27, M.-A. Lemburg a écrit : Not sure what you mean. We've had binary wininst distributions for Windows for more than a decade, and egg and msi distributions for 8 years :-) But without access to the VS 2008 compiler that is needed to compile those extensions, It does seem to

Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7

Le 24/06/2014 07:04, Skip Montanaro a écrit : I can't see any reason to make a backwards-incompatible change to Python 2 to only support Unicode. You're bound to break somebody's setup. Apparently, that setup would already have been broken for years. Regards Antoine. ___

Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7

Le 25/06/2014 19:28, Nick Coghlan a écrit : OK, *that* sounds like an excellent reason to keep the Unicode disabled builds functional, and make sure they stay that way with a buildbot: to help make sure we're not accidentally running afoul of the implicit interoperability between str and unicode

Re: [Python-Dev] Network Security Backport Status

Le 01/07/2014 14:26, Alex Gaynor a écrit : I can do all the work of reviewing each commit, but I need some help from a mercurial expert to automate the cherry-picking/rebasing of every single commit. What do folks think? Does this approach make sense? Anyone willing to help with the mercurial s

Re: [Python-Dev] Memory BIO for _ssl

Hi, Le 05/07/2014 14:04, Geert Jansen a écrit : Since I need this for my Gruvi async framework, I want to volunteer to write a patch. It should be useful as well to Py3K's asyncio and other async frameworks. It would be good to get some feedback before I start on this. Thanks for volunteerin

Re: [Python-Dev] buildbot.python.org down again?

Le 07/07/2014 13:22, Guido van Rossum a écrit : It's a reference to Neil Stephenson's Anathem. According to Google, it doesn't look like he played the trombone, though. Regards Antoine. On Jul 7, 2014 8:55 AM, "Benjamin Peterson" mailto:benja...@python.org>> wrote: On Mon, Jul 7, 201

Re: [Python-Dev] == on object tests identity in 3.x

Le 09/07/2014 00:21, Stephen J. Turnbull a écrit : Steven D'Aprano writes: > I don't think so. Floating point == represents *numeric* equality, There is no such thing as floating point == in Python. You can apply == to two floating point numbers, but == (at the language level) handles any tw

Re: [Python-Dev] cStringIO vs io.BytesIO

Hi, Le 16/07/2014 19:07, dw+python-...@hmmz.org a écrit : Attached is a (rough) patch implementing this, feel free to try it with hg tip. Thanks for your work. Please post any patch to http://bugs.python.org Regards Antoine. ___ Python-Dev mai

Re: [Python-Dev] Remaining decisions on PEP 471 -- os.scandir()

Hi, > Thanks Victor, Nick, Ethan, and others for continued discussion on the scandir PEP 471 (most recent thread starts at https://mail.python.org/pipermail/python-dev/2014-July/135377.html). Have you tried modifying importlib's _bootstrap.py to use scandir() instead of listdir() + stat()?

Re: [Python-Dev] Remaining decisions on PEP 471 -- os.scandir()

Le 20/07/2014 17:34, Ben Hoyt a écrit : Have you tried modifying importlib's _bootstrap.py to use scandir() instead of listdir() + stat()? No, I haven't -- I'm not familiar with that code. What does _bootstrap.py do -- does it do a lot of listdir calls and stat-ing of many files? Quite a bit,

Re: [Python-Dev] [PEP466] SSLSockets, and sockets, _socketobjects oh my!

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)? b) Does anyone know why weak references are used in the first place? T

Re: [Python-Dev] [PEP466] SSLSockets, and sockets, _socketobjects oh my!

Le 22/07/2014 17:44, Nick Coghlan a écrit : > > As for 2.x, I don't see why you couldn't just continue using a strong reference. As Antoine says, if the cycle already exists in Python 2 (and it sounds like it does), we can just skip backporting the weak reference change. No, IIRC there shou

Re: [Python-Dev] PEP 471 "scandir" accepted

Le 21/07/2014 18:26, Victor Stinner a écrit : I'm happy because the final API is very close to os.path functions and pathlib.Path methods. Python stays consistent, which is a great power of this language! By the way, http://bugs.python.org/issue19767 could benefit too. Regards Antoine. ___

Re: [Python-Dev] [PEP466] SSLSockets, and sockets, _socketobjects oh my!

Le 23/07/2014 15:36, Alex Gaynor a écrit : That said, I've hit another issue, with SNI callbacks. The first argument to an SNI callback is the socket. The callback is set up by some C code, which right now has access to only the _socket.socket object, not the ssl.SSLSocket object, which is what

Re: [Python-Dev] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now

Le 30/07/2014 02:11, Serhiy Storchaka a écrit : 30.07.14 06:59, Serhiy Storchaka написав(ла): 30.07.14 02:45, antoine.pitrou написав(ла): http://hg.python.org/cpython/rev/79a5fbe2c78f changeset: 91935:79a5fbe2c78f parent: 91933:fbd104359ef8 user:Antoine Pitrou date:Tue

Re: [Python-Dev] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now

Le 30/07/2014 15:48, Serhiy Storchaka a écrit : Ignoring tests and comments my patch adds/removes/modifies about 200 lines, and David's patch -- about 150 lines of code. But it's __sizeof__ looks not correct, correcting it requires changing about 50 lines. In sum the complexity of both patches i

Re: [Python-Dev] Surely "nullable" is a reasonable name?

Le 04/08/2014 03:35, Stephen Hansen a écrit : Before you say "the term 'nullable' will confuse end users", let me remind you: this is not user-facing. This is a parameter for an Argument Clinic converter, and will only ever be seen by CPython core developers. A group which I ho

Re: [Python-Dev] Surely "nullable" is a reasonable name?

Le 04/08/2014 13:36, Alexander Belopolsky a écrit : On Mon, Aug 4, 2014 at 12:57 PM, Ethan Furman mailto:et...@stoneleaf.us>> wrote: 'allow_none' is definitely clearer. I disagree. Unlike "nullable", "allow_none" does not tell me what happens on the C side when I pass in None. If the rec

Re: [Python-Dev] Surely "nullable" is a reasonable name?

Le 04/08/2014 14:18, Larry Hastings a écrit : On 08/05/2014 03:53 AM, Antoine Pitrou wrote: Le 04/08/2014 13:36, Alexander Belopolsky a écrit : If the receiving type is PyObject*, either NULL or Py_None is a valid choice. But here the receiving type can be an int. Just to be precise: in

Re: [Python-Dev] pathlib handling of trailing slash (Issue #21039)

Le 06/08/2014 18:36, Isaac Schwabacher a écrit : If a symbolic link is encountered during pathname resolution, the behavior shall depend on whether the pathname component is at the end of the pathname and on the function being performed. If all of the following are true, then pathname resolutio

Re: [Python-Dev] pathlib handling of trailing slash (Issue #21039)

Le 06/08/2014 20:50, Alexander Belopolsky a écrit : On Wed, Aug 6, 2014 at 8:11 PM, Antoine Pitrou mailto:anto...@python.org>> wrote: Am I overlooking other cases? There are many interfaces where trailing slash is significant. For example, rsync uses trailing slash on the target dir

Re: [Python-Dev] pathlib handling of trailing slash (Issue #21039)

Le 06/08/2014 22:12, Ben Finney a écrit : You seem to be saying that ‘pathlib’ is not intended to be helpful for constructing a shell command. pathlib lets you do operations on paths. It also gives you a string representation of the path that's expected to designate that path when talking to

Re: [Python-Dev] sum(...) limitation

Le 09/08/2014 01:08, Steven D'Aprano a écrit : On Fri, Aug 08, 2014 at 10:20:37PM -0400, Alexander Belopolsky wrote: On Fri, Aug 8, 2014 at 8:56 PM, Ethan Furman wrote: I don't use sum at all, or at least very rarely, and it still irritates me. You are not alone. When I see sum([a, b, c]),

Re: [Python-Dev] os.walk() is going to be *fast* with scandir

Le 09/08/2014 12:43, Ben Hoyt a écrit : Just thought I'd share some of my excitement about how fast the all-C version [1] of os.scandir() is turning out to be. Below are the results of my scandir / walk benchmark run with three different versions. I'm using an SSD, which seems to make it especia

Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray

Le 17/08/2014 13:07, Raymond Hettinger a écrit : FWIW, I've been teaching Python full time for three years. I cover the use of bytearray(n) in my classes and not a single person out of 3000+ engineers have had a problem with it. This is less about bytearray() than bytes(), IMO. bytearray() i

Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray

Le 16/08/2014 01:17, Nick Coghlan a écrit : * Deprecate passing single integer values to ``bytes`` and ``bytearray`` I'm neutral. Ideally we wouldn't have done that mistake at the beginning. * Add ``bytes.zeros`` and ``bytearray.zeros`` alternative constructors * Add ``bytes.byte`` and ``by

Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray

Le 17/08/2014 19:41, Raymond Hettinger a écrit : The APIs have been around since 2.6 and AFAICT there have been zero demonstrated need for a special case for a single byte. We already have a perfectly good spelling: NUL = bytes([0]) That is actually a very cumbersome spelling. Why should

Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray

Le 17/08/2014 20:08, Nick Coghlan a écrit : On 18 Aug 2014 09:57, "Barry Warsaw" mailto:ba...@python.org>> 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, w

Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?

Le 18/08/2014 13:22, Mark Dickinson a écrit : [Moderately off-topic] On Sun, Aug 17, 2014 at 3:39 AM, Steven D'Aprano mailto:st...@pearwood.info>> wrote: I used to refer to Python 4000 as the hypothetical compatibility break version. Now I refer to Python 5000. I personally think it s

Re: [Python-Dev] Bytes path support

Le 19/08/2014 13:43, Ben Hoyt a écrit : The official policy is that we want them [support for bytes paths in stdlib functions] to go away, but reality so far has not budged. We will continue to hold our breath though. :-) Does that mean that new APIs should explicitly not support bytes? I'm t

Re: [Python-Dev] Bytes path support

Le 20/08/2014 07:08, Nick Coghlan a écrit : It's not just the JVM that says text and binary APIs should be separate - it's every widely used operating system services layer except POSIX. The POSIX way works well *if* everyone reliably encodes things as UTF-8 or always uses encoding detection, bu

Re: [Python-Dev] Bytes path support

Le 21/08/2014 00:52, Cameron Simpson a écrit : The "bytes in some arbitrary encoding where at least the slash character (and maybe a couple others) is ascii compatible" notion is completely bogus. There's only one special byte, the slash (code 47). There's no OS-level need that it or anything e

Re: [Python-Dev] Bytes path support

Le 21/08/2014 18:27, Cameron Simpson a écrit : As remarked, codes 0 (NUL) and 47 (ASCII slash code) _are_ special to UNIX filename bytes strings. So you admit that POSIX mandates that file paths are expressed in an ASCII-compatible encoding after all? Good. I've nothing to add to your rant.

Re: [Python-Dev] Bytes path related questions for Guido

Le 24/08/2014 09:04, Nick Coghlan a écrit : 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

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Fri, 29 Aug 2014 17:11:35 -0400 Donald Stufft wrote: > > Another problem with this is that I don’t think it’s actually > possible to do. Python itself isn’t validating the TLS certificates, > OpenSSL is doing that. To my knowledge OpenSSL doesn’t > have a way to say “please validate these cert

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Fri, 29 Aug 2014 17:42:34 -0400 "R. David Murray" wrote: > > Especially if you want an accelerated change, there must be a way to > *easily* get back to the previous behavior, or we are going to catch a > lot of flack. There may be only 7% of public certs that are problematic, > but I'd be wi

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Fri, 29 Aug 2014 18:08:19 -0400 Donald Stufft wrote: > > > > Are you sure that's possible ? Python doesn't load the > > openssl.cnf file and the SSL_CERT_FILE, SSL_CERT_DIR env > > vars only work for the openssl command line binary, AFAIK. > > I’m not 100% sure on that. I know they are not li

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Sat, 30 Aug 2014 12:19:11 +0200 "M.-A. Lemburg" wrote: > > To add to the PEP: > > > > * Emit a warning in 3.4.next for cases that would raise a Exception in 3.5 > > * Clearly state that the existing OpenSSL environment variables will be > > respected for setting the trust root > > I'd also

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Sat, 30 Aug 2014 12:46:47 +0200 "M.-A. Lemburg" wrote: > The change is to the OpenSSL API, not the OpenSSL lib. By setting > the variable you enable a few special calls to the config loader > functions in OpenSSL when calling the initializer it: > > https://www.openssl.org/docs/crypto/OPENSSL_

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Sun, 31 Aug 2014 09:26:30 +1000 Nick Coghlan wrote: > >> > >> * configuration: > >> > >> It would be good to be able to switch this on or off > >> without having to change the code, e.g. via a command > >> line switch and environment variable; perhaps even > >> controlling whe

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

Le 31/08/2014 19:03, Paul Moore a écrit : On 31 August 2014 17:27, Christian Heimes wrote: It's very simple to trust a self-signed certificate: just download it and stuff it into the trust store. "Stuff it into the trust store" is the hard bit, though. I have honestly no idea how to do that.

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

Le 31/08/2014 20:28, Paul Moore a écrit : I can't see how that would be something the application would know. For example, pip allows me to specify an "alternate cert bundle" but not a single additional cert. So IIUC, I can't use my local index that serves https using a self-signed cert. I'd fin

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

Le 31/08/2014 21:12, Paul Moore a écrit : On 31 August 2014 19:37, Antoine Pitrou wrote: Well, it's certainly pip's responsibility more than Python's. What would Python do? Provide a setting that would blindly add a cert for all uses of httplib? That's more or less my poi

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

Le 31/08/2014 23:41, Nick Coghlan a écrit : Right, this is why I came to the conclusion we need to follow the browser vendors lead here and support a per-user Python specific supplementary certificate cache before we can start validating certs by default at the *Python* level. There are still too

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 01:15:12 +0300 Marko Rauhamaa wrote: > > If a signal is received when read() or write() has completed its task > partially (> 0 bytes), no EINTR is returned but the partial count. > Obviously, Python should take that possibility into account so that > raising an exception in t

Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

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 from > the original PEP in order to focus on meeting the Python 3.4 specific > release deadlines. This also had the benefit of working out the kinks in > the bootstrapp

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

Le 01/09/2014 10:09, Nick Coghlan a écrit : > 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

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 19:15:33 +1200 Greg Ewing wrote: > Victor Stinner wrote: > > > > Le 1 sept. 2014 00:17, "Marko Rauhamaa" > > a écrit : > > > If a signal is received when read() or write() has completed its task > > > partially (> 0 bytes), no EINTR is returned but

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Hi, I'm +1 on the whole PEP. > Writing a signal handler is difficult, only "async-signal safe" > functions can be called. You mean a C signal handler? Python signal handlers are not restricted. > Some signals are not interesting and should not interrupt the the > application. There are two op

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Mon, 1 Sep 2014 23:24:39 +1000 Chris Angelico wrote: > On Mon, Sep 1, 2014 at 10:41 PM, Antoine Pitrou wrote: > > Not sure why. Just put another module named "ssl" in sys.modules directly. > > You can also monkeypatch the genuine ssl module. > > That has to

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Mon, 1 Sep 2014 23:42:10 +1000 Chris Angelico wrote: > On Mon, Sep 1, 2014 at 11:34 PM, Antoine Pitrou wrote: > > On Mon, 1 Sep 2014 23:24:39 +1000 > > Chris Angelico wrote: > >> On Mon, Sep 1, 2014 at 10:41 PM, Antoine Pitrou wrote: > >> > Not sure why

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Tue, 2 Sep 2014 00:53:11 +1000 Nick Coghlan wrote: > 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

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 11:47:07 -0400 "R. David Murray" wrote: > > > > The two requirements are: > > > > * Allow the application to react to signals immediately in the main > >flow. > > You don't want to be writing your code in Python then. In Python > you *never* get to react immediately to

Re: [Python-Dev] Daily reference leaks (640c575ab3e1): sum=151940

Is anyone working on those? On Mon, 01 Sep 2014 10:41:45 +0200 solip...@pitrou.net wrote: > results for 640c575ab3e1 on branch "default" > > > test_codecs leaked [5825, 5825, 5825] references, sum=17475 > test_codecs leaked [1172, 1174, 1174] memory

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 1 Sep 2014 21:17:33 + (UTC) Matthew Woodcraft wrote: > > > If such applications exist, they are not portable and are subject to > > race conditions (deadlock if the signal comes before the system call). > > The program is certainly not portable (which is not any kind of a > problem),

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Tue, 2 Sep 2014 14:00:02 -0700 Glyph Lefkowitz wrote: > > I would strongly recommend against such a mechanism. > > For what it's worth, Twisted simply unconditionally started verifying > certificates in 14.0 with no "disable" switch, and (to my knowledge) > literally no users have complaine

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Tue, 2 Sep 2014 22:16:18 + (UTC) Alex Gaynor wrote: > > > Furthermore, "disable verification" is a nonsensical thing to do with TLS. > > > > It's not. For example, if you have an expired cert, all you can do > > AFAIK is to disable verification. > > It really is a nonsensical operation, a

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Tue, 2 Sep 2014 16:47:35 -0700 Glyph Lefkowitz wrote: > > On Sep 2, 2014, at 4:28 PM, Nick Coghlan wrote: > > > On 3 Sep 2014 09:08, "David Reid" wrote: > > > > > > Nick Coghlan gmail.com> writes: > > > > > > > Creating *new* incompatibilities between Python 2 & Python 3 is a major > > >

Re: [Python-Dev] Sad status of Python 3.x buildbots

On Wed, 3 Sep 2014 00:13:22 +0200 Victor Stinner wrote: > > AMD64 Snow Leop 3.x: many tests are not reliable (stable) on this > platform. For example, test_logging.test_race() sometimes fail with > PermissionError(1, "Operation not permitted: > '/tmp/test_logging-3-bjulw8iz.log'"). Another exampl

Re: [Python-Dev] Sad status of Python 3.x buildbots

On Wed, 3 Sep 2014 08:53:51 +1000 Nick Coghlan wrote: > On 3 Sep 2014 08:15, "Victor Stinner" wrote: > > > > x86 RHEL 6 3.x: TestReadline.test_init() fails, issue #19884. I don't > > have to this platform, I don't know how to fix it. > > Sorry, I haven't been a very good maintainer for that buil

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Wed, 3 Sep 2014 20:34:32 +1000 Nick Coghlan wrote: > > The backwards compatibility argument only applies to Python 2 maintenance > releases (where dreid indicated an intention to request backporting the > change), and there I'm quite happy to take the position of "use requests, > Twisted or Py

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Tue, 02 Sep 2014 21:29:16 -0400 "R. David Murray" wrote: > > The top proposal so far is an sslcustomize.py file that could be used to > either decrease or increase the default security. This is a much less > handy solution than application options (eg, curl, wget) that allow > disabling secur

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Wed, 3 Sep 2014 10:54:55 -0700 Guido van Rossum wrote: > > Let's take the plunge on this issue for the next 2.7 release (3.5 being a > done deal). I'm entirely against this. > Yes, some people will find that they have an old script > accessing an old service which breaks. Surely some of the

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Thu, 4 Sep 2014 09:19:56 +1000 Nick Coghlan wrote: > > > > Python is routinely updated to bugfix releases by Linux distributions > > and other distribution channels, you usually have no say over what's > > shipped in those updates. This is not like changing the major version > > used for execut

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Thu, 4 Sep 2014 13:11:38 +1000 Nick Coghlan wrote: > That leaves Python 2.7, and I have to say I'm now persuaded that a > backport (including any required httplib and urllib features) is the > right way to go. One of the tasks I'd been dreading as a follow-on > from PEP 466 was organising the c

Re: [Python-Dev] cpython and parallel make

On Thu, 4 Sep 2014 12:06:25 +0200 Jonas Wagner wrote: > > One additional issue appeared, though: it seems that extension modules are > always built sequentially no matter what the value of MAKEFLAGS is. I've > seen that these are being built by a custom setup.py script. Do you think > it would be

Re: [Python-Dev] cpython (3.4): Issue #22295: Adopt 'python -m pip' as the preferred invocation

On Sat, 6 Sep 2014 12:40:19 +0200 (CEST) nick.coghlan wrote: > > The following command will install the latest version of a module and its > dependencies from the Python Package Index:: > > -pip install SomePackage > +python -m pip install SomePackage > + > +.. note:: > + > + For

Re: [Python-Dev] Proposed schedule for 3.4.2

On Mon, 8 Sep 2014 10:44:51 -0700 Alex Gaynor wrote: > *Shifts uncomfortably* it looks like presently there's not a good way to > change anything about the SSL configuration for urllib.request.urlopen. It > does not take a `context` argument, as the http.client API does: > https://docs.python.org/

Re: [Python-Dev] Proposed schedule for 3.4.2

On Tue, 9 Sep 2014 08:20:52 +1000 Nick Coghlan wrote: > On 9 Sep 2014 04:00, "Barry Warsaw" wrote: > > > > > >This would need to be updated first, once it *did* take such an argument, > > >this would be accomplished by: > > > > > >context = ssl.create_default_context() > > >context.verify_mode =

Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog

On Fri, 12 Sep 2014 07:54:56 +0100 Jeff Allen wrote: > Simply having a block "for private use" seems to create an unmanaged > space for conflict, reminiscent of the "other 128 characters" in > bilingual programming. I wondered if the way to respect use by > applications might be to make it priv

Re: [Python-Dev] namedtuples bug between 3.3.2 and 3.4.1

On Mon, 15 Sep 2014 02:13:53 +1000 Chris Angelico wrote: > On Sun, Sep 14, 2014 at 8:13 PM, Brynjar Smári Bjarnason > wrote: > > I am using Python 3.4.1 installed with Anaconda. I tried the following > > (expecting an OrderedDict as result): > > > from collections import namedtuple > NT =

Re: [Python-Dev] List insert at index that is well out of range - behaves like append

On Mon, 15 Sep 2014 23:46:03 +0100 Mark Lawrence wrote: > > I assume it's based on the concepts of slicing. From the docs > "s.insert(i, x) - inserts x into s at the index given by i (same as > s[i:i] = [x])". Although shouldn't that read s[i:i+1] = [x] ? No, the latter would replace the con

Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog

Seriously, can this discussion move somewhere else? This has nothing to do on python-dev. Thank you Antoine. On Wed, 17 Sep 2014 18:56:02 +1000 Steven D'Aprano wrote: > On Wed, Sep 17, 2014 at 09:21:56AM +0900, Stephen J. Turnbull wrote: > > > Guido's mantra is something like "Python's str

Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke

On Fri, 19 Sep 2014 08:20:48 -0700 Guido van Rossum wrote: > "python" should always be the same as "python2". "Always" as in "eternally"? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscrib

Re: [Python-Dev] 3.5 release schedule PEP

On Wed, 24 Sep 2014 17:12:35 +1000 Nick Coghlan wrote: > On 24 Sep 2014 15:15, "Tim Golden" wrote: > > > > On 23/09/2014 18:05, Steve Dower wrote: > >> > >> I'm also considering/experimenting with installing into "Program > >> Files" by default, but I suspect that isn't going to work out yet. > >

Re: [Python-Dev] 3.5 release schedule PEP

On Wed, 24 Sep 2014 21:32:52 +0200 Victor Stinner wrote: > Most Windows setup are desktop configured with a single user. I would not > be shocked if pip installs modules only for the current user by default. > Maybe it could be an option in Python installer (pip system wide or user). pip install

Re: [Python-Dev] 3.5 release schedule PEP

On Wed, 24 Sep 2014 22:56:20 +0100 Paul Moore wrote: > On 24 September 2014 22:29, Steve Dower wrote: > >> In my experience pip --user works just fine also. We use it on our unmanned > >> media players successfully. > > > > This is good to know. Maybe we aren't as far away as we think. > > Indee

Re: [Python-Dev] 3.5 release schedule PEP

On Thu, 25 Sep 2014 07:34:31 +0100 Paul Moore wrote: > On 25 September 2014 02:08, Antoine Pitrou wrote: > >> Indeed. Moving towards having --user as the norm is definitely > >> something we want to look at for pip. One of the biggest concerns is > >> how well

Re: [Python-Dev] 3.5 release schedule PEP

Le 25/09/2014 09:22, INADA Naoki a écrit : > FYI, homebrew's Python uses prefix option, so I can't use `--user`. > Is it a bug? > > $ /usr/local/bin/pip -V > pip 1.5.6 from > /usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.5.6-py2.7.egg

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Thu, 25 Sep 2014 13:00:16 -0700 Bob Hanson wrote: > Critical bash vulnerability CVE-2014-6271 may affect Python on > *n*x and OSX: > > > >

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Fri, 26 Sep 2014 09:40:17 +1000 Steven D'Aprano wrote: > Perhaps I'm missing something, but aren't there easier ways to attack > os.system than the bash env vulnerability? If I'm accepting and running > arbitrary strings from an untrusted user, there's no need for them to go > to the trouble

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Fri, 26 Sep 2014 01:10:53 -0700 Hasan Diwan wrote: > Matěj, > > On 26 September 2014 00:28, Matěj Cepl wrote: > > > Where does your faith that other /bin/sh implementations (dash, > > busybox, etc.) are less buggy comes from? > > > The fact that they are simpler, in terms of lines of code.

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Fri, 26 Sep 2014 14:56:05 +0200 Stefan Behnel wrote: > Jeremy Sanders schrieb am 26.09.2014 um 09:28: > > Antoine Pitrou wrote: > > > >> Fortunately, Python's subprocess has its `shell` argument default to > >> False. However, `os.system` invokes the sh

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

On Fri, 26 Sep 2014 18:01:31 + Steve Dower wrote: > Hi all, > > (This is advance notice since people on this list will be interested. > Official announcements are coming when setuptools makes their next release.) When you mention "setuptools", do you imply it doesn't work with plain distuti

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

On Sat, 27 Sep 2014 14:10:48 +0100 Paul Moore wrote: > On 27 September 2014 14:01, Nick Coghlan wrote: > > I personally believe we should treat handling both this and the SDK > > compilers properly as a platform-enablement bug for distutils and > > ensure they work properly with the currently mai

Re: [Python-Dev] Fixing 2.7.x

On Mon, 06 Oct 2014 09:08:23 -0700 Ethan Furman wrote: > With the incredibly long life span of 2.7, which bugs should we *not* fix?* Those that are not bugs but enhancement requests. On that issue, you pointed out there was no regression and that enums were never meant to be supported by the json

Re: [Python-Dev] mUTF-7 support?

On Fri, 10 Oct 2014 00:47:46 +0200 Jesus Cea wrote: > I miss mUTF-7 support (as used to encode IMAP4 mailbox names) in Python, > in the codecs module. As an european with a language with 27 different > letters (instead of english 26), tildes, opening question marks, etc., I > find it very inconven

Re: [Python-Dev] mUTF-7 support?

On Thu, 9 Oct 2014 19:12:29 -0700 Dan Stromberg wrote: > On Thu, Oct 9, 2014 at 3:47 PM, Jesus Cea wrote: > > I miss mUTF-7 support (as used to encode IMAP4 mailbox names) in Python, > > in the codecs module. As an european with a language with 27 different > > letters (instead of english 26), ti

Re: [Python-Dev] mUTF-7 support?

On Fri, 10 Oct 2014 13:36:49 +1100 Chris Angelico wrote: > On Fri, Oct 10, 2014 at 11:52 AM, Jesus Cea wrote: > > Actually, it doesn't work in Python 2 either. It never supported > > international mailbox names. > > > > Should I dare to suggest to port this to 2.7, since 2.7 is special and > > wi

Re: [Python-Dev] Sad status of Python 3.x buildbots

On Fri, 10 Oct 2014 12:08:54 -0400 "R. David Murray" wrote: > On Fri, 10 Oct 2014 18:00:06 +0200, Jesus Cea wrote: > > On 10/10/14 17:56, Chris Angelico wrote: > > > Could I write a little > > > monitor at my end that asks every hour if my buildbots can be seen? > > > > AFAIK maintainers already

Re: [Python-Dev] Status of C compilers for Python on Windows

On Sat, 11 Oct 2014 00:30:51 + (UTC) Sturla Molden wrote: > Larry Hastings wrote: > > > CPython doesn't require OpenBLAS. Not that I am not receptive to the > > needs of the numeric community... but, on the other hand, who in the > > hell releases a library with Windows support that doesn't

Re: [Python-Dev] Status of C compilers for Python on Windows

On Sat, 11 Oct 2014 13:59:52 + (UTC) Sturla Molden wrote: > Antoine Pitrou wrote: > > > But you can compile OpenBLAS with one compiler and then link it to > > Python using another compiler, right? There is a single C ABI. > > BLAS and LAPACK are actually Fortra

Re: [Python-Dev] Disabling SSL 3.0

On Wed, 15 Oct 2014 01:16:26 +0200 Victor Stinner wrote: > Hi, > > I opened an issue to track this vulnerability: > http://bugs.python.org/issue22638 > > SSL 3.0 is 8 years old, I guess that TLS is now widely deployed and > well supported? > > I guess that Linux vendors will have to fix the iss

Re: [Python-Dev] How io.IOBase.readline() should behave when used on non-blocking obj and no data available?

On Thu, 16 Oct 2014 03:54:32 +0300 Paul Sokolovsky wrote: > Hello, > > io.RawIOBase.read() is well specified for behavior in case it > immediately gets a would-block condition: "If the object is in > non-blocking mode and no bytes are available, None is returned." > (https://docs.python.org/3/lib

Re: [Python-Dev] XP buildbot problem cloning from hg.python.org

On Fri, 24 Oct 2014 23:47:05 -0400 David Bolen wrote: > Starting yesterday, my XP buildbot began failing to execute clone > operations against hg.python.org. There's not a lot of data being > given aside from a transaction abort message (and my buildbot log > showing the hg command exiting), and

Re: [Python-Dev] Status of C compilers for Python on Windows

On Sun, 26 Oct 2014 08:11:39 +1100 Chris Angelico wrote: > > It might fragment the community to have multiple different binary > distributions. But it ought to be possible for any person/organization > to say "We're going to make our own build of Python, with these > extension modules, built with

Re: [Python-Dev] Status of C compilers for Python on Windows

On Sat, 25 Oct 2014 21:10:23 +0100 Ray Donnelly wrote: > > This is the second time you've used the vacuous "culture on Windows" > argument, now with an added appeal to (vague) authority. [...] > Why are you fighting so hard against having option. > If CPython wants to truly call itself an Open So

Re: [Python-Dev] Status of C compilers for Python on Windows

On Sun, 26 Oct 2014 08:53:29 +1100 Chris Angelico wrote: > On Sun, Oct 26, 2014 at 8:47 AM, Antoine Pitrou wrote: > > And how do you know that it would have worked with MSVC if you only use > > MinGW? > > If you want to ensure compatibility with MSVC, you must build with

Re: [Python-Dev] Status of C compilers for Python on Windows

On Sun, 26 Oct 2014 09:06:36 +1100 Chris Angelico wrote: > On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou wrote: > > How do you know this isn't a problem, since you haven't *tested* with > > MSVC? > > Why on Earth would you want to test your PEP work with an unsup

Re: [Python-Dev] Status of C compilers for Python on Windows

On Sun, 26 Oct 2014 09:22:18 +1100 Chris Angelico wrote: > On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou wrote: > > My point is that your "Windows build" would not have the same behaviour > > as a MSVC-produced Windows build, and so testing it with it would not > &g

  1   2   3   4   5   6   7   8   9   10   >