From report at bugs.python.org Sun Feb 1 00:48:10 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 31 Jan 2015 23:48:10 +0000 Subject: [issue23358] BaseServer missing from socketserver.__all__ In-Reply-To: <1422704522.18.0.713790375362.issue23358@psf.upfronthosting.co.za> Message-ID: <1422748090.93.0.457614051949.issue23358@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Martin. I got the following failure on the 3.4 branch: ====================================================================== FAIL: test_all (test.test_socketserver.SimpleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/berker/projects/cpython/default/Lib/test/test_socketserver.py", line 324, in test_all self.assertCountEqual(socketserver.__all__, expected) AssertionError: Element counts were not equal: First has 0, Second has 1: '_eintr_retry' Here is an updated patch. ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file37946/issue23358.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 00:55:31 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 Jan 2015 23:55:31 +0000 Subject: [issue23358] BaseServer missing from socketserver.__all__ In-Reply-To: <1422704522.18.0.713790375362.issue23358@psf.upfronthosting.co.za> Message-ID: <1422748531.95.0.766864681867.issue23358@psf.upfronthosting.co.za> Martin Panter added the comment: New test case looks good. Checking for the underscore prefix is how I would have done it too, if I had realized it was needed :) I?m not qualified to comment on removing the run_unittest() call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 01:28:25 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 00:28:25 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422750505.82.0.815696637416.issue23255@psf.upfronthosting.co.za> Martin Panter added the comment: Here is an enhancement to the existing SimpleHTTPServerTestCase.test_get() test case, that demonstrates the current implementation breaks serving index.html files by default. ---------- Added file: http://bugs.python.org/file37947/index-test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 01:57:25 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 00:57:25 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1422752245.98.0.86419368712.issue23099@psf.upfronthosting.co.za> Martin Panter added the comment: I can live with the wording of StringIO, but personally prefer my v2 patch. I now understand that calling close() for Bytes and StringIO objects is intended to immediately free the memory buffer holding the file data (like deleting a file in Windows). So I think it would be better to document this as a property of the whole object, rather than a special exception for each of the getbuffer(), getvalue() non-file-API methods. I?m happy to propose a similar wording for the StringIO class if you want to make them consistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 03:07:08 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 02:07:08 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1422756428.21.0.107477909574.issue12916@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a 4th patch that allows None as input. Other changes: * Document and test getdoc() returning None * Limited the splitting and re-joining dance * Document when the synopsis and body strings are empty * More test cases I left the pydoc test there, though I don?t see a big need for this test. It is no problem if the deprecated function remains in version 3.7. ---------- Added file: http://bugs.python.org/file37948/issue12916-splitdoc-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 03:12:03 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 02:12:03 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1422756723.76.0.63357445401.issue12916@psf.upfronthosting.co.za> Martin Panter added the comment: Oops, seems I forgot to refresh my patch ---------- Added file: http://bugs.python.org/file37949/issue12916-splitdoc-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 03:12:16 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 02:12:16 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1422756736.43.0.0820496209738.issue12916@psf.upfronthosting.co.za> Changes by Martin Panter : Removed file: http://bugs.python.org/file37948/issue12916-splitdoc-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 03:29:22 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 02:29:22 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422757762.56.0.808707841757.issue23352@psf.upfronthosting.co.za> Richard Hansen added the comment: (The following message is mostly off-topic but I think it is relevant to those interested in this issue. This message is about the clarity of the documentation regarding flag semantics, and what I think the flags should mean.) > Cython doesn't follow the spec though (use Python 3): > > from _testbuffer import * > cpdef foo(): > cdef unsigned char[:] v = bytearray(b"testing") > nd = ndarray(v, getbuf=PyBUF_ND) > print(nd.suboffsets) > nd = ndarray(v, getbuf=PyBUF_FULL) > print(nd.suboffsets) When I compile and run the above (latest Cython from Git master), I get: () () Looking at the Python source code (Modules/_testbuffer.c ndarray_get_suboffsets() and ssize_array_as_tuple()) the above output is printed if the suboffsets member is NULL. > Cython hands out suboffsets even for a PyBUF_ND request, which is > definitely wrong. For a PyBUF_FULL request they should only be > provided *if needed*. suboffsets appears to be NULL in both cases in your example, which seems acceptable to me given: * the user didn't request suboffsets information in the PyBUF_ND case, and * there are no indirections in the PyBUF_FULL case. Even if suboffsets wasn't NULL, I believe the behavior would still be correct for the PyBUF_ND case. My reading of is that flags=PyBUF_ND implies that shape member MUST NOT be NULL, but strides and suboffsets can be NULL or not (it doesn't matter). This interpretation of mine is due to the sentence, "Note that each flag contains all bits of the flags below it." If flags=PyBUF_ND meant that strides and suboffsets MUST be NULL, then PyBUF_ND and PyBUF_STRIDES would necessarily be mutually exclusive and flags=(PyBUF_ND|PyBUF_STRIDES) would not make sense (the strides member would have to be both NULL and non-NULL). If (flags & PyBUF_INDIRECT) is false, then the consumer is not interested in the suboffsets member so it shouldn't matter what it points to. (And the consumer should not dereference the pointer in case it points to a junk address.) IMHO, if the buffer is C-style contiguous then the producer should be allowed to populate the shape, strides, and suboffsets members regardless of whether or not any of the PyBUF_ND, PyBUF_STRIDES, or PyBUF_INDIRECT flags are set. In other words, for C-style contiguous buffers, the producer should be allowed to act as if PyBUF_INDIRECT was always provided because the consumer will always get an appropriate Py_buffer struct regardless of the actual state of the PyBUF_ND, PyBUF_STRIDES, and PyBUF_INDIRECT flags. It *is* a bug, however, to dereference the strides or suboffsets members with ndarray(v, getbuf=PyBUF_ND) because the consumer didn't ask for strides or suboffsets information and the pointers might be bogus. Stepping back a bit, I believe that the flags should be thought of as imposing requirements on the producer. I think those requirements should be (assuming ndim > 0): * PyBUF_ND: If (flags & PyBUF_ND) is true: - If (flags & PyBUF_STRIDES) is false *and* the producer is unable to produce a block of memory at [buf,buf+len) containing all (len/itemsize) entries in a C-style contiguous chunk, then the producer must raise an exception. - Otherwise, the producer must provide the shape of buffer. If (flags & PyBUF_ND) is false: - If the producer is unable to produce a contiguous chunk of (len/itemsize) entries (of any shape) in the block of memory at [buf,buf+len), then the producer must raise an exception. - Otherwise, the producer is permitted to do any of the following: + don't touch the shape member (don't set it to NULL or any other value; just leave it as-is) + set the shape member to NULL + set the shape member to point to an array describing the shape + set the shape member to point to any other location, even if dereferencing the pointer would result in a segfault * PyBUF_STRIDES: If (flags & PyBUF_STRIDES) is true: - The producer must provide the appropriate strides information. If (flags & PyBUF_STRIDES) is false: - If the producer is unable to produce a block of memory at [buf,buf+len) containing all (len/itemsize) entries, the producer must raise an exception. - Otherwise, the producer is permitted to do any of the following; + don't touch the strides member (don't set it to NULL or any other value; just leave it as-is) + set the strides member to NULL + set the strides member to point to an array describing the strides + set the strides member to point to any other location, even if dereferencing the pointer would result in a segfault * PyBUF_INDIRECT: If (flags & PyBUF_INDIRECT) is true: - If the buffer uses indirections then the producer must set the suboffsets member to point to an array with appropriate entries. - Otherwise, the producer can either set the suboffsets member to NULL or set it to point to an array of all negative entries. If (flags & PyBUF_INDIRECT) is false: - If the producer cannot produce a buffer that does not have indirections, then the producer must raise an exception. - Otherwise, the producer is permitted to do any of the following: + don't touch the suboffsets member (don't set it to NULL or any other value; just leave it as-is) + set the suboffsets member to NULL + set the suboffsets member to point to an array of all negative entries + set the suboffsets member to point to any other location, even if dereferencing the pointer would result in a segfault ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 05:38:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 04:38:22 +0000 Subject: [issue15608] Improve socketserver doc In-Reply-To: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za> Message-ID: <1422765502.59.0.00176460897415.issue15608@psf.upfronthosting.co.za> Martin Panter added the comment: Here is an attempt to tidy up the socketserver documentation: 1. Added headings for each concrete class and mixin 2. Listed the predefined mixin subclasses 3. Changed RequestHandler to BaseRequestHandler and added class heading 4. Included headings for UnixStream/DatagramServer Other fixes: * Fixed many class and method cross references * Pulled out Stream/DatagramRequestHandler definitions * Reordered the request handler setup(), handle(), finish() methods ---------- keywords: +patch Added file: http://bugs.python.org/file37950/socketserver-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 06:02:24 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 01 Feb 2015 05:02:24 +0000 Subject: [issue15608] Improve socketserver doc In-Reply-To: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za> Message-ID: <1422766944.15.0.384928362526.issue15608@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review type: -> enhancement versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 06:50:10 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 01 Feb 2015 05:50:10 +0000 Subject: [issue18454] distutils crashes when uploading to PyPI having only the username (no pw) defined In-Reply-To: <1373822688.67.0.938925989206.issue18454@psf.upfronthosting.co.za> Message-ID: <1422769810.06.0.851532791862.issue18454@psf.upfronthosting.co.za> Nick Coghlan added the comment: I agree the documentation is correct here, and the stdlib should be updated to implement the expected behaviour. While distutils is indeed feature frozen, that's aimed at changing how we approach the larger scale evolution of the packaging ecosystem, it doesn't mean we won't fix bugs and usability issues. (While we may be slow sometimes, that's a general core developer availability issue, rather than a distutils specific problem) ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 07:37:54 2015 From: report at bugs.python.org (Ent) Date: Sun, 01 Feb 2015 06:37:54 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422772674.61.0.741479007458.issue23255@psf.upfronthosting.co.za> Ent added the comment: I have updated the patch such that for any directory, if they have a file with name in index_files, it will be served by default. Also a few tweaks. ---------- Added file: http://bugs.python.org/file37951/Feb1st.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 08:57:34 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 07:57:34 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422777454.06.0.16077257947.issue23352@psf.upfronthosting.co.za> Richard Hansen added the comment: Attached is a documentation patch that adds what I said in msg235141. I doubt everyone will agree with the changes, but maybe it will be a useful starting point. (Despite not having an asterisk next to my username, I have signed the contributor agreement. It just hasn't been processed yet.) ---------- Added file: http://bugs.python.org/file37952/doc_c-api_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 09:05:16 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 08:05:16 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422777916.49.0.280842716403.issue23352@psf.upfronthosting.co.za> Changes by Richard Hansen : Removed file: http://bugs.python.org/file37952/doc_c-api_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 09:05:41 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 08:05:41 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422777941.98.0.939200639885.issue23352@psf.upfronthosting.co.za> Changes by Richard Hansen : Added file: http://bugs.python.org/file37953/doc_c-api_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 09:14:14 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 08:14:14 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422778454.28.0.523189127951.issue23352@psf.upfronthosting.co.za> Changes by Richard Hansen : Removed file: http://bugs.python.org/file37953/doc_c-api_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 09:14:30 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 08:14:30 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422778470.77.0.331156540394.issue23352@psf.upfronthosting.co.za> Changes by Richard Hansen : Added file: http://bugs.python.org/file37954/doc_c-api_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 09:45:35 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 08:45:35 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422780335.82.0.323908543504.issue23352@psf.upfronthosting.co.za> Richard Hansen added the comment: > This leaves me +-0 for the change, with the caveat that applications > might break. How might an application break with this change? Compared to the current PyBuffer_IsContiguous(), the patched version is the same except it returns true for a wider range of actually-contiguous buffers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 09:50:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 08:50:59 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1422780659.98.0.14095002867.issue23359@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >>> s = set() >>> s.add(1<<64) >>> s.add(2<<64) >>> s.add(3<<64) >>> list(s) [36893488147419103232, 18446744073709551616, 55340232221128654848] >>> s.discard(1<<64) >>> s.discard(2<<64) >>> s.add(3<<64) >>> list(s) [55340232221128654848, 55340232221128654848] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 09:59:39 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Feb 2015 08:59:39 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422757762.56.0.808707841757.issue23352@psf.upfronthosting.co.za> Message-ID: <20150201085927.GA3008@bytereef.org> Stefan Krah added the comment: > Richard Hansen added the comment: > > Cython doesn't follow the spec though (use Python 3): > > > > from _testbuffer import * > > cpdef foo(): > > cdef unsigned char[:] v = bytearray(b"testing") > > nd = ndarray(v, getbuf=PyBUF_ND) > > print(nd.suboffsets) > > nd = ndarray(v, getbuf=PyBUF_FULL) > > print(nd.suboffsets) > > When I compile and run the above (latest Cython from Git master), I get: > > () > () With Cython version 0.20.1post0 I get: >>> foo.foo() (-1,) (-1,) If you get the correct output from the latest Cython, it looks like this issue has been fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 10:08:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 09:08:22 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422781702.48.0.67238303097.issue23255@psf.upfronthosting.co.za> Martin Panter added the comment: Here is another addition to the existing test suite to detect the bug with the duplicate 404 Not Found responses. It relies on running the non-Windows, non-root test that says # chmod() doesn't work as expected on Windows, and filesystem # permissions are ignored by root on Unix In other words, you trigger it by requesting an unreadable file or directory. Thanks for your replies to my comments, I think I am understanding your point of view better now. You want functions to either return a file object, or to mutate the connection and send part of the response, but not both (except for sending an error response): * get_file() returns a file object only * redirect() sends response headers only I am trying find a neater way to avoiding calling apply_headers() when list_directory() has already sent the headers. How do you feel about calling apply_headers() from inside get_file_or_dir() and get_index_file()? Or at least put a big fat warning saying get_file_or_dir() may or may not have already sent the headers, indicated by the type of file returned. Another option might be to split list_directory() into a get-file stage and an apply-headers stage. But in my experience the headers to send are usually tightly coupled with the content body. In this case both vary depending on the redirect, generated directory, or static file cases. ---------- Added file: http://bugs.python.org/file37955/index-test.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 10:10:04 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Feb 2015 09:10:04 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422780335.82.0.323908543504.issue23352@psf.upfronthosting.co.za> Message-ID: <20150201090616.GA3380@bytereef.org> Stefan Krah added the comment: > How might an application break with this change? func1: if (!PyBuffer_IsContiguous(view, 'C')) error(); func2(view); func2: assert(view->suboffsets == NULL); ... Yes, I *did* insert sanity checks like this in some places. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 10:21:18 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 09:21:18 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422782478.58.0.298625475587.issue23352@psf.upfronthosting.co.za> Richard Hansen added the comment: >> When I compile and run the above (latest Cython from Git master), I >> get: >> >> () >> () > > With Cython version 0.20.1post0 I get: > > >>> foo.foo() > (-1,) > (-1,) > > If you get the correct output from the latest Cython, it looks like > this issue has been fixed. Oops, I was running a locally modified version of Cython that contained a patch meant to work around issue #23349. When I run the *actual* upstream master I get the same behavior that you do. But either way, I don't see why it's a problem that it prints (-1,) for the PyBUF_ND case. The consumer didn't request suboffsets information so I would expect it to be OK for the producer to put whatever it wants in the suboffsets field, including a junk pointer that would segfault upon dereference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 10:23:25 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 09:23:25 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422782605.55.0.176911832978.issue23352@psf.upfronthosting.co.za> Richard Hansen added the comment: >> How might an application break with this change? > > assert(view->suboffsets == NULL); Fair point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 10:29:13 2015 From: report at bugs.python.org (Sebastian Berg) Date: Sun, 01 Feb 2015 09:29:13 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422782953.49.0.639646011709.issue23352@psf.upfronthosting.co.za> Sebastian Berg added the comment: I do not have an opinion either way, but I do think there is a small difference here compared to the other issue. With the other issue, there are cases where we cannot set the strides correctly. If you ask numpy directly whether the array is contiguous (or create it from numpy) and it says "yes", and then you get it without asking for a contiguous array it is, without the change, possible to get an array that would *not* be considered contiguous. On the other hand, setting suboffsets to NULL when all are -1 is always possible, if tedious I admit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 10:30:15 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 01 Feb 2015 09:30:15 +0000 Subject: [issue19903] Idle: Use inspect.signature for calltips In-Reply-To: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za> Message-ID: <1422783015.85.0.276072480946.issue19903@psf.upfronthosting.co.za> Terry J. Reedy added the comment: .signature also handles wrapped functions better. >>> def deco(f): import functools @functools.wraps(f) def ret(*args, **kw): return f(*args, **kw) return ret >>> @deco def f(n, k): return n + k*2 >>> import inspect as ip >>> isf=ip.signature(f) >>> print(isf) (n, k) >>> ip.formatargspec(*ip.getfullargspec(f)) '(*args, **kw)' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 10:39:43 2015 From: report at bugs.python.org (Richard Hansen) Date: Sun, 01 Feb 2015 09:39:43 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422783583.0.0.227532114486.issue23352@psf.upfronthosting.co.za> Richard Hansen added the comment: My preference is to apply the patch, of course. There is a legitimate concern that it will break existing code, but I think there are more points in favor of applying the patch: * there exists code that the current behavior is known to break * it's easier to remove assert(view->suboffsets == NULL) than to change producers to not provide an all-negative array (though I admit there may be other more subtle ways the patch would break existing code) * I may be the only one who has spoken up about this, but I doubt I'm the only one who has experienced it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 10:50:26 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 01 Feb 2015 09:50:26 +0000 Subject: [issue19903] Idle: Use inspect.signature for calltips In-Reply-To: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za> Message-ID: <1422784226.7.0.450061267687.issue19903@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The above suggests that the change might be applied to 3.4. The difference surprises me because #17481 patched getfullargspec() to 'use' signature() 'behind the scenes', so I expected the result to be the same. It seems that 'use' does not mean what I thought. My hesitation is that only some builtins have been converted to use Argument Clinic, and Idle currently treats builtins special to get the signature from the docstring. Treating just some builting special will be slightly awkward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 11:12:07 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 01 Feb 2015 10:12:07 +0000 Subject: [issue19903] Idle: Use inspect.signature for calltips In-Reply-To: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za> Message-ID: <1422785527.9.0.902331390291.issue19903@psf.upfronthosting.co.za> Terry J. Reedy added the comment: An example should make my concern clearer. str(signature(int)) is '()' because int (and all other builtins) has not been converted whereas the Idle calltip is int(x=0) -> integer int(x, base=10) -> integer I do not want to simply add a line with '()' to the top of the calltip, so a little thought is needed to improve the calltip for the rare cases above without degrading them for existing, more common cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 11:49:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 10:49:38 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1422787778.26.0.839847025632.issue22818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I hesitate about warning type. Originally I was going to emit a DeprecationWarning in 3.5, may be change it to a UserWarning in 3.6, and raise a ValueError or change behavior in 3.7. What would be better? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 11:53:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 10:53:05 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1422787985.41.0.183158326113.issue23099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it would be good to make the documentation of BytesIO and StringIO consistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 12:01:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 11:01:24 +0000 Subject: [issue23321] Crash in str.decode() with special error handler In-Reply-To: <1422227773.79.0.793422498408.issue23321@psf.upfronthosting.co.za> Message-ID: <1422788484.19.0.0718206072942.issue23321@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If you have no enhancements to my quick fix Victor, may be this issue can be closed. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 12:13:49 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 11:13:49 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422789229.78.0.412140986575.issue23055@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 12:36:19 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Feb 2015 11:36:19 +0000 Subject: [issue23352] Document "suboffsets if needed" in 2.7 In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422790579.31.0.706699766376.issue23352@psf.upfronthosting.co.za> Stefan Krah added the comment: But only Cython does not set suboffsets to NULL and you already have a small patch to fix that. The Python 3 docs say "suboffsets only if needed" and the PEP says the same, so the situation is not completely undocumented. I think your doc patch goes too far. Buffers propagate in unpredictable ways, and since the original consumer request is *not stored* in the buffer, setting unneeded fields to NULL provides a way to figure out the original request. It is actually *an optimization* to set suboffsets to NULL: Compliant code that uses arbitrary buffers always has to check for: if (suboffsets != NULL && suboffsets[i] >= 0) ... If suboffsets are consistently NULL, at least hopefully you get branch prediction to kick in. As Sebastian pointed out, it's relatively easy even for slicing/indexing functions to check for all-negative suboffsets and handle that case. All this is probably academic, since no one appears to be using suboffsets at all. :) Let's keep the status-quo and make this a doc issue for 2.7. ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python priority: normal -> low stage: patch review -> title: PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL -> Document "suboffsets if needed" in 2.7 type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 13:09:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 12:09:04 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1422792544.13.0.630121980013.issue22818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be RuntimeWarning or FutureWarning are more appropriate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 13:14:23 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 12:14:23 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1422792863.53.0.848738181121.issue12916@psf.upfronthosting.co.za> Martin Panter added the comment: Uploading issue12916-splitdoc-5.patch: * Documented TypeError * Added stacklevel=2 to warning * Test improvements * Dropped the test for pydoc.splitdoc() removal ---------- Added file: http://bugs.python.org/file37956/issue12916-splitdoc-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 13:21:52 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 12:21:52 +0000 Subject: [issue15608] Improve socketserver doc In-Reply-To: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za> Message-ID: <1422793312.07.0.0804148027641.issue15608@psf.upfronthosting.co.za> Martin Panter added the comment: Main changes in socketserver-doc.2.patch: * Documented constructor parameters for the server classes * Indented class methods and attributes underneath class headings ---------- Added file: http://bugs.python.org/file37957/socketserver-doc.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 13:26:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 12:26:57 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1422793617.51.0.596551159084.issue20204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which adds a warning to PyType_FromSpec and PyType_FromSpecWithBases if type spec name doesn't contain module name. In conjunction with tkinter_typespecs.patch it should fix the issue. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file37958/type_from_spec_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 13:43:32 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 12:43:32 +0000 Subject: [issue23360] Content-Type when sending data with urlopen() Message-ID: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za> New submission from Martin Panter: Currently the documentation gives the impression that the ?data? parameter to Request() has to be in the application/x-www-form-urlencoded format. However I suspect that you can override the type by supplying a Content-Type header, and I would like to document this; see uploaded patch. I noticed that test_urllib2.HandlerTests.test_http() already seems to test the default Content-Type and a custom Content-Type with a Request() object, although I did not see a test for the default Content-Type when supplying ?data? directly to urlopen(). Also I understand the ?charset? parameter on application/x-www-form-urlencoded is not standardized. Would it correspond to the encoding of the %XX codes from urlencode(), which is typically UTF-8, not Latin-1? Or would it correspond to the subsequent string-to-bytes encoding stage, which could just be ASCII since non-ASCII characters are already encoded? Maybe it would be best to drop the advice to set a ?charset? parameter. It was added for Issue 11082. ---------- assignee: docs at python components: Documentation files: non-urlencoded.patch keywords: patch messages: 235166 nosy: docs at python, vadmium priority: normal severity: normal status: open title: Content-Type when sending data with urlopen() versions: Python 3.4 Added file: http://bugs.python.org/file37959/non-urlencoded.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:28:05 2015 From: report at bugs.python.org (Ent) Date: Sun, 01 Feb 2015 13:28:05 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422797285.74.0.377945729936.issue23255@psf.upfronthosting.co.za> Ent added the comment: @vadmium: Thanks for the suggestion - I opted for the first one. While I wasn't happy with it being called twice, wasn't getting an idea of how to address it. Am I supposed to include your patch as part of my patch? I am not much knowledgeable about the protocol to follow in such cases, so I haven't included it. ---------- Added file: http://bugs.python.org/file37960/Feb1stb.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:44:54 2015 From: report at bugs.python.org (Geoffrey Spear) Date: Sun, 01 Feb 2015 13:44:54 +0000 Subject: [issue5187] distutils upload should prompt for the user/password too In-Reply-To: <1234128468.86.0.0554273106388.issue5187@psf.upfronthosting.co.za> Message-ID: <1422798294.26.0.545763319268.issue5187@psf.upfronthosting.co.za> Changes by Geoffrey Spear : ---------- nosy: +geoffreyspear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:45:12 2015 From: report at bugs.python.org (Geoffrey Spear) Date: Sun, 01 Feb 2015 13:45:12 +0000 Subject: [issue18454] distutils crashes when uploading to PyPI having only the username (no pw) defined In-Reply-To: <1373822688.67.0.938925989206.issue18454@psf.upfronthosting.co.za> Message-ID: <1422798312.86.0.373566527674.issue18454@psf.upfronthosting.co.za> Changes by Geoffrey Spear : ---------- nosy: +geoffreyspear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:51:43 2015 From: report at bugs.python.org (paul) Date: Sun, 01 Feb 2015 13:51:43 +0000 Subject: [issue23361] integer overflow in winapi_createprocess Message-ID: <1422798703.49.0.874007534993.issue23361@psf.upfronthosting.co.za> New submission from paul: winapi_createprocess takes env_mapping dictionary as a parameter, mapping variables to their env. values. Dictionary with pathologically large values will cause an integer overflow during computation of total space required to store all key-value pairs File: Modules\_winapi.c static PyObject* getenvironment(PyObject* environment) { Py_ssize_t i, envsize, totalsize; ... envsize = PyMapping_Length(environment); keys = PyMapping_Keys(environment); values = PyMapping_Values(environment); if (!keys || !values) goto error; totalsize = 1; /* trailing null character */ for (i = 0; i < envsize; i++) { PyObject* key = PyList_GET_ITEM(keys, i); PyObject* value = PyList_GET_ITEM(values, i); if (! PyUnicode_Check(key) || ! PyUnicode_Check(value)) { PyErr_SetString(PyExc_TypeError, "environment can only contain strings"); goto error; } totalsize += PyUnicode_GET_LENGTH(key) + 1; /* +1 for '=' */ 1 totalsize += PyUnicode_GET_LENGTH(value) + 1; /* +1 for '\0' */ } 2 buffer = PyMem_Malloc(totalsize * sizeof(Py_UCS4)); if (! buffer) goto error; p = buffer; 3 end = buffer + totalsize; 4 for (i = 0; i < envsize; i++) { PyObject* key = PyList_GET_ITEM(keys, i); PyObject* value = PyList_GET_ITEM(values, i); X if (!PyUnicode_AsUCS4(key, p, end - p, 0)) goto error; p += PyUnicode_GET_LENGTH(key); X *p++ = '='; X if (!PyUnicode_AsUCS4(value, p, end - p, 0)) goto error; p += PyUnicode_GET_LENGTH(value); X *p++ = '\0'; } 1. no overflow checks. We can set totalsize to 2^30, with a crafted dictionary. 2. totalsize*4 == 0, so buffer is 0-bytes long 3. end = buffer+2^30 4. envsize == len(env_mapping). We can make this variable as large as we like. X. write past the buffer's end. Note size checks in PyUnicode_AsUCS4 are inefficient, because the size variable (end-p) is very large. ---------- messages: 235168 nosy: pkt priority: normal severity: normal status: open title: integer overflow in winapi_createprocess type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:53:20 2015 From: report at bugs.python.org (paul) Date: Sun, 01 Feb 2015 13:53:20 +0000 Subject: [issue23362] integer overflow in string translate Message-ID: <1422798800.96.0.0931437199134.issue23362@psf.upfronthosting.co.za> New submission from paul: # Bug # --- # # PyObject * # _PyUnicode_TranslateCharmap(PyObject *input, # PyObject *mapping, # const char *errors) # { # ... # size = PyUnicode_GET_LENGTH(input); # ... # osize = size; # 1 output = PyMem_Malloc(osize * sizeof(Py_UCS4)); # # 1. Input size = 2^30, so osize*sizeof(Py_UCS4)=2^32==0 (modulo 2^32) and malloc # allocates a 0 byte buffer # # Crash # ----- # # Breakpoint 2, _PyUnicode_TranslateCharmap ( # input='aa...', mapping={97: 'b'}, errors=0x828c82b "ignore") at Objects/unicodeobject.c:8597 # 8597 { # ... # 8636 output = PyMem_Malloc(osize * sizeof(Py_UCS4)); # (gdb) print osize # $1 = 1073741824 # (gdb) print osize*4 # $2 = 0 # (gdb) c # Continuing. # # Program received signal SIGSEGV, Segmentation fault. # 0x0814aed2 in charmaptranslate_output ( # input='aa...', ipos=51302, mapping={97: 'b'}, output=0xbfc40860, osize=0xbfc40864, opos=0xbfc40868, # res=0xbfc40874) at Objects/unicodeobject.c:8574 # 8574 (*output)[(*opos)++] = PyUnicode_READ_CHAR(*res, 0); # # OS info # ------- # # % ./python -V # Python 3.4.1 # # % uname -a # Linux ubuntu 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux # s="a"*(2**30) s.translate({ord('a'): 'b'}) ---------- files: poc_translate.py messages: 235169 nosy: pkt priority: normal severity: normal status: open title: integer overflow in string translate type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37961/poc_translate.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:54:13 2015 From: report at bugs.python.org (paul) Date: Sun, 01 Feb 2015 13:54:13 +0000 Subject: [issue23363] integer overflow in itertools.permutations Message-ID: <1422798853.28.0.166749700091.issue23363@psf.upfronthosting.co.za> New submission from paul: # Bug # --- # # static PyObject * # permutations_new(PyTypeObject *type, PyObject *args, PyObject *kwds) # { # ... # 1 cycles = PyMem_Malloc(r * sizeof(Py_ssize_t)); # ... # for (i=0 ; i0, so we write well beyond the buffer's end # # Crash # ----- # # Breakpoint 1, permutations_new (type=0x83394e0 , args=('A', 1073741824), kwds=0x0) at ./Modules/itertoolsmodule.c:3012 # ... # 3044 indices = PyMem_Malloc(n * sizeof(Py_ssize_t)); # (gdb) print r # $2 = 1073741824 # (gdb) print r*4 # $3 = 0 # (gdb) c # Continuing. # # Program received signal SIGSEGV, Segmentation fault. # 0x08230900 in permutations_new (type=0x83394e0 , args=('A', 1073741824), kwds=0x0) at ./Modules/itertoolsmodule.c:3054 # 3054 cycles[i] = n - i; # # OS info # ------- # # % ./python -V # Python 3.4.1 # # % uname -a # Linux ubuntu 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux # import itertools as it it.permutations("A", 2**30) ---------- files: poc_permutations.py messages: 235170 nosy: pkt priority: normal severity: normal status: open title: integer overflow in itertools.permutations type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37962/poc_permutations.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:55:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Feb 2015 13:55:02 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <20150201135424.25843.95305@psf.io> Roundup Robot added the comment: New changeset 369300948f3f by Stefan Krah in branch 'default': Issue #22445: PyBuffer_IsContiguous() now implements precise contiguity https://hg.python.org/cpython/rev/369300948f3f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:55:04 2015 From: report at bugs.python.org (paul) Date: Sun, 01 Feb 2015 13:55:04 +0000 Subject: [issue23364] integer overflow in itertools.product Message-ID: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> New submission from paul: # Bug # --- # # static PyObject * # product_new(PyTypeObject *type, PyObject *args, PyObject *kwds) # { # ... # 1 nargs = (repeat == 0) ? 0 : PyTuple_GET_SIZE(args); # 2 npools = nargs * repeat; # # 3 indices = PyMem_Malloc(npools * sizeof(Py_ssize_t)); # ... # # 4 for (i=0; i < nargs ; ++i) { # ... # indices[i] = 0; # } # # 1. nargs is the number of functions arguments (not counting the keyword arg). # We set this value to 2^16 using argument unpacking (*args). # 2. We set the 'repeat' keyword argument to 2^16, so npools=2^32==0 (modulo 2^32) # 3. npools*4=0, so malloc allocates a 0 byte buffer # 4. nargs=2^16, so the loop writes well beyond the buffer's end # # Breakpoint 1, product_new (type=0x8338c80 , # args=('a', ...(truncated), kwds={'repeat': 65536}) # at ./Modules/itertoolsmodule.c:1998 # ... # 2021 nargs = (repeat == 0) ? 0 : PyTuple_GET_SIZE(args); # (gdb) n # 2022 npools = nargs * repeat; # (gdb) print nargs # $14 = 65536 # (gdb) print repeat # $15 = 65536 # (gdb) n # 2024 indices = PyMem_Malloc(npools * sizeof(Py_ssize_t)); # (gdb) print npools # $16 = 0 # (gdb) c # Continuing. # # Crash # ----- # # We crash in a different place, because there was sufficient allocated memory # after the "indices" buffer. # # Program received signal SIGSEGV, Segmentation fault. # 0x08313940 in PyTuple_Type () # (gdb) bt # #0 0x08313940 in PyTuple_Type () # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # #1 0x080f27c7 in PyObject_Hash (v=) at Objects/object.c:747 # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # #2 0x080e132f in PyDict_GetItem (op=, key=) at Objects/dictobject.c:1070 # #2 0x080e132f in PyDict_GetItem (op=, key=) at Objects/dictobject.c:1070 # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # #3 0x080e5261 in _PyDict_GetItemId (dp=, key=0x832bd20 ) at Objects/dictobject.c:2729 # #4 0x0806f0e8 in _PySys_GetObjectId (key=0x832bd20 ) at ./Python/sysmodule.c:57 # #5 0x081bb52a in PyEval_EvalFrameEx (f=Frame 0x404ea1ac, for file , line 1, in (), throwflag=0) at Python/ceval.c:1848 # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # #6 0x081c8574 in PyEval_EvalCodeEx (_co=, globals=, locals=, args=0x0, argcount=0, kws=0x0, kwcount=0, # defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3578 # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # #7 0x081b51ef in PyEval_EvalCode (co=, globals=, locals=) at Python/ceval.c:773 # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # Python Exception 'utf8' codec can't decode byte 0xc8 in position 1: invalid continuation byte: # #8 0x08065e89 in run_mod (mod=0x9ea5758, filename='', globals=, locals=, flags=0xbf85fbc0, arena=0x9e64220) # at Python/pythonrun.c:2180 # #9 0x080637fd in PyRun_InteractiveOneObject (fp=0x40231ac0 <_IO_2_1_stdin_>, filename='', flags=0xbf85fbc0) # at Python/pythonrun.c:1445 # #10 0x08063243 in PyRun_InteractiveLoopFlags (fp=0x40231ac0 <_IO_2_1_stdin_>, filename_str=0x826bc06 "", flags=0xbf85fbc0) # at Python/pythonrun.c:1324 # #11 0x0806305f in PyRun_AnyFileExFlags (fp=0x40231ac0 <_IO_2_1_stdin_>, filename=0x826bc06 "", closeit=0, flags=0xbf85fbc0) # at Python/pythonrun.c:1286 # #12 0x08079e8a in run_file (fp=0x40231ac0 <_IO_2_1_stdin_>, filename=0x0, p_cf=0xbf85fbc0) at Modules/main.c:319 # #13 0x0807a988 in Py_Main (argc=1, argv=0x9e45010) at Modules/main.c:751 # #14 0x0805dc34 in main (argc=1, argv=0xbf85fd04) at ./Modules/python.c:69 # # OS info # ------- # # % ./python -V # Python 3.4.1 # # % uname -a # Linux ubuntu 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux # import itertools as it args=["a"]*(2**16) it.product(*args, repeat=2**16) ---------- files: poc_product.py messages: 235172 nosy: pkt priority: normal severity: normal status: open title: integer overflow in itertools.product type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37963/poc_product.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:55:43 2015 From: report at bugs.python.org (paul) Date: Sun, 01 Feb 2015 13:55:43 +0000 Subject: [issue23365] integer overflow in itertools.combinations_with_replacement Message-ID: <1422798943.75.0.0941782409051.issue23365@psf.upfronthosting.co.za> New submission from paul: # Bug # --- # # static PyObject * # cwr_new(PyTypeObject *type, PyObject *args, PyObject *kwds) # { # ... # 1 indices = PyMem_Malloc(r * sizeof(Py_ssize_t)); # ... # for (i=0 ; i0, so we write well beyond the buffer's end # # Crash # ----- # # Breakpoint 1, cwr_new (type=0x83392a0 , args=('AA', 1073741824), kwds=0x0) at ./Modules/itertoolsmodule.c:2684 # 2684 PyObject *pool = NULL; # ... # 2703 indices = PyMem_Malloc(r * sizeof(Py_ssize_t)); # (gdb) print r # $1 = 1073741824 # (gdb) print r*4 # $2 = 0 # (gdb) c # Continuing. # # Program received signal SIGSEGV, Segmentation fault. # 0x0822fdcd in cwr_new (type=0x83392a0 , args=('AA', 1073741824), kwds=0x0) at ./Modules/itertoolsmodule.c:2710 # 2710 indices[i] = 0; # # OS info # ------- # # % ./python -V # Python 3.4.1 # # % uname -a # Linux ubuntu 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux # import itertools as it it.combinations_with_replacement("AA", 2**30) ---------- files: poc_cwr.py messages: 235173 nosy: pkt priority: normal severity: normal status: open title: integer overflow in itertools.combinations_with_replacement type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37964/poc_cwr.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:56:22 2015 From: report at bugs.python.org (paul) Date: Sun, 01 Feb 2015 13:56:22 +0000 Subject: [issue23366] integer overflow in itertools.combinations Message-ID: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> New submission from paul: # Bug # --- # # static PyObject * # combinations_new(PyTypeObject *type, PyObject *args, PyObject *kwds) # { # ... # # 1 indices = PyMem_Malloc(r * sizeof(Py_ssize_t)); # ... # # for (i=0 ; i0, so we write well beyond the buffer's end # # Crash # ----- # # Breakpoint 1, combinations_new (type=0x83390c0 , args=('AA', 1073741824), kwds=0x0) # at ./Modules/itertoolsmodule.c:2343 # 2343 PyObject *pool = NULL; # ... # (gdb) n # 2362 indices = PyMem_Malloc(r * sizeof(Py_ssize_t)); # (gdb) print r # $1 = 1073741824 # (gdb) print r*4 # $2 = 0 # (gdb) c # Continuing. # # Program received signal SIGSEGV, Segmentation fault. # 0x0822f359 in combinations_new (type=0x83390c0 , args=('AA', 1073741824), kwds=0x0) # at ./Modules/itertoolsmodule.c:2369 # 2369 indices[i] = i; # OS info # ------- # # % ./python -V # Python 3.4.1 # # % uname -a # Linux ubuntu 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux # import itertools as it it.combinations("AA", 2**30) ---------- files: poc_combinations.py messages: 235174 nosy: pkt priority: normal severity: normal status: open title: integer overflow in itertools.combinations type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37965/poc_combinations.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:57:15 2015 From: report at bugs.python.org (paul) Date: Sun, 01 Feb 2015 13:57:15 +0000 Subject: [issue23367] integer overflow in unicodedata.normalize Message-ID: <1422799035.27.0.978256662941.issue23367@psf.upfronthosting.co.za> New submission from paul: # Bug # --- # # static PyObject* # unicodedata_normalize(PyObject *self, PyObject *args) # { # ... # if (strcmp(form, "NFKC") == 0) { # if (is_normalized(self, input, 1, 1)) { # Py_INCREF(input); # return input; # } # return nfc_nfkc(self, input, 1); # # We need to pass the is_normalized() check (repeated \xa0 char takes care of # that). nfc_nfkc calls: # # static PyObject* # nfd_nfkd(PyObject *self, PyObject *input, int k) # { # ... # Py_ssize_t space, isize; # ... # isize = PyUnicode_GET_LENGTH(input); # /* Overallocate at most 10 characters. */ # space = (isize > 10 ? 10 : isize) + isize; # osize = space; # 1 output = PyMem_Malloc(space * sizeof(Py_UCS4)); # # 1. if isize=2^30, then space=2^30+10, so space*sizeof(Py_UCS4)=(2^30+10)*4 == # 40 (modulo 2^32), so PyMem_Malloc allocates buffer too small to hold the # result. # # Crash # ----- # # nfd_nfkd (self=, input='...', k=1) at /home/p/Python-3.4.1/Modules/unicodedata.c:552 # 552 stackptr = 0; # (gdb) n # 553 isize = PyUnicode_GET_LENGTH(input); # (gdb) n # 555 space = (isize > 10 ? 10 : isize) + isize; # (gdb) n # 556 osize = space; # (gdb) n # 557 output = PyMem_Malloc(space * sizeof(Py_UCS4)); # (gdb) print space # $9 = 1073741834 # (gdb) print space*4 # $10 = 40 # (gdb) c # Continuing. # # Program received signal SIGSEGV, Segmentation fault. # 0x40579cbb in nfd_nfkd (self=, input='', k=1) at /home/p/Python-3.4.1/Modules/unicodedata.c:614 # 614 output[o++] = code; # # OS info # ------- # # % ./python -V # Python 3.4.1 # # % uname -a # Linux ubuntu 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux import unicodedata as ud s="\xa0"*(2**30) ud.normalize("NFKC", s) ---------- files: poc_unidata_normalize.py messages: 235175 nosy: pkt priority: normal severity: normal status: open title: integer overflow in unicodedata.normalize type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37966/poc_unidata_normalize.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:58:39 2015 From: report at bugs.python.org (paul) Date: Sun, 01 Feb 2015 13:58:39 +0000 Subject: [issue23368] integer overflow in _PyUnicode_AsKind Message-ID: <1422799119.61.0.313717828667.issue23368@psf.upfronthosting.co.za> New submission from paul: # Bug # --- # # void* # _PyUnicode_AsKind(PyObject *s, unsigned int kind) # { # Py_ssize_t len; # ... # len = PyUnicode_GET_LENGTH(s); # ... # switch (kind) { # ... # case PyUnicode_4BYTE_KIND: # 1 result = PyMem_Malloc(len * sizeof(Py_UCS4)); # ... # else { # assert(skind == PyUnicode_1BYTE_KIND); # 2 _PyUnicode_CONVERT_BYTES( # Py_UCS1, Py_UCS4, # PyUnicode_1BYTE_DATA(s), # PyUnicode_1BYTE_DATA(s) + len, # result); # } # # 1. len equals 2^30, so len*sizeof(Py_UCS4)=2^30*2^2=2^32, which gets casted # down to 0, since PyMem_Malloc takes size_t as the parameter. Resulting buffer # is 0 bytes big. # 2. chars from the source string s (which are 1 byte long) are expanded to 4 # bytes and copied to the 'result' buffer, which is too small to hold them all # # Stack trace # ----------- # # Breakpoint 2, _PyUnicode_AsKind ( # s='a...', kind=4) at Objects/unicodeobject.c:2176 # 2176 if (PyUnicode_READY(s) == -1) # (gdb) n # 2179 len = PyUnicode_GET_LENGTH(s); # (gdb) n # 2180 skind = PyUnicode_KIND(s); # (gdb) n # 2181 if (skind >= kind) { # (gdb) n # 2185 switch (kind) { # (gdb) n # 2198 result = PyMem_Malloc(len * sizeof(Py_UCS4)); # (gdb) print len # $10 = 1073741824 # (gdb) print skind # $11 = 1 # (gdb) print kind # $12 = 4 # (gdb) print len*4 # $13 = 0 # (gdb) c # Continuing. # # Program received signal SIGSEGV, Segmentation fault. # 0x08130b56 in _PyUnicode_AsKind ( # s='a...', kind=4) at Objects/unicodeobject.c:2210 # 2210 _PyUnicode_CONVERT_BYTES( # # OS info # ------- # # % ./python -V # Python 3.4.1 # # % uname -a # Linux ubuntu 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux # # POC # --- txt=b"\x0a\x0a\x0a\x00" uni=txt.decode("utf-32") sub="a"*(2**30) uni.count(sub) ---------- files: poc_askind.py messages: 235176 nosy: pkt priority: normal severity: normal status: open title: integer overflow in _PyUnicode_AsKind type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37967/poc_askind.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 14:59:35 2015 From: report at bugs.python.org (paul) Date: Sun, 01 Feb 2015 13:59:35 +0000 Subject: [issue23369] integer overflow in _json.encode_basestring_ascii Message-ID: <1422799175.9.0.580347379364.issue23369@psf.upfronthosting.co.za> New submission from paul: # static PyObject * # ascii_escape_unicode(PyObject *pystr) # { # ... # # input_chars = PyUnicode_GET_LENGTH(pystr); # input = PyUnicode_DATA(pystr); # kind = PyUnicode_KIND(pystr); # # /* Compute the output size */ # for (i = 0, output_size = 2; i < input_chars; i++) { # Py_UCS4 c = PyUnicode_READ(kind, input, i); # if (S_CHAR(c)) # output_size++; # else { # switch(c) { # ... # default: # 1 output_size += c >= 0x10000 ? 12 : 6; # ... # # 2 rval = PyUnicode_New(output_size, 127); # # 1. if c is \uFFFF then output_size += 6. There are no overflow checks on this # variable, so we can overflow it with a sufficiently long (2**32/6+1 chars) # string # 2. rval buffer is too small to hold the result # # Crash: # ------ # # Breakpoint 3, ascii_escape_unicode (pystr='...') at /home/p/Python-3.4.1/Modules/_json.c:198 # 198 rval = PyUnicode_New(output_size, 127); # (gdb) print output_size # $9 = 4 # (gdb) c # Continuing. # # Program received signal SIGSEGV, Segmentation fault. # 0x4057888f in ascii_escape_unichar (c=65535, # output=0x40572358 "...", # chars=19624) at /home/p/Python-3.4.1/Modules/_json.c:155 # 155 output[chars++] = Py_hexdigits[(c >> 8) & 0xf]; # # OS info # ------- # # % ./python -V # Python 3.4.1 # # % uname -a # Linux ubuntu 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux # from _json import encode_basestring_ascii as enc s="\uffff"*int((2**32)/6+1) enc(s) ---------- files: poc_ascii_escape.py messages: 235177 nosy: pkt priority: normal severity: normal status: open title: integer overflow in _json.encode_basestring_ascii type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37968/poc_ascii_escape.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 15:28:35 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Feb 2015 14:28:35 +0000 Subject: [issue22445] Memoryviews require more strict contiguous checks then necessary In-Reply-To: <1411153250.02.0.529032306838.issue22445@psf.upfronthosting.co.za> Message-ID: <1422800915.94.0.144668643667.issue22445@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 16:05:51 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Feb 2015 15:05:51 +0000 Subject: [issue23370] PyBuffer_FromContiguous() off-by-one error for non-contiguous buffers Message-ID: <1422803151.79.0.434214643845.issue23370@psf.upfronthosting.co.za> New submission from Stefan Krah: Same as #23349. ---------- messages: 235178 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: PyBuffer_FromContiguous() off-by-one error for non-contiguous buffers type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 16:07:45 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Feb 2015 15:07:45 +0000 Subject: [issue23370] PyBuffer_FromContiguous() off-by-one error for non-contiguous buffers In-Reply-To: <1422803151.79.0.434214643845.issue23370@psf.upfronthosting.co.za> Message-ID: <1422803265.46.0.849013554987.issue23370@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- keywords: +patch Added file: http://bugs.python.org/file37969/issue23370.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 16:58:40 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Lenclud?=) Date: Sun, 01 Feb 2015 15:58:40 +0000 Subject: [issue23371] mimetypes initialization fails on Windows because of TypeError Message-ID: <1422806320.68.0.990065034592.issue23371@psf.upfronthosting.co.za> New submission from St?phane Lenclud: On my Windows 7 installation mimetypes.py in read_windows_registry _winreg.OpenKey can throw a TypeError exception which is not handled and interrupts the execution. To fix it I added: except TypeError: continue To reproduce it I just need to run te following: c:\python27\python -c "import mimetypes; mimetypes.init()" This error is obviously due to the content of my registry. The subkeyname causing issues have names like: {hexid-hexid-hexid-hexid-hexid} ---------- components: Windows messages: 235179 nosy: Slion, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: mimetypes initialization fails on Windows because of TypeError type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 17:19:44 2015 From: report at bugs.python.org (Alec Nikolas Reiter) Date: Sun, 01 Feb 2015 16:19:44 +0000 Subject: [issue23372] defaultdict.fromkeys should accept a callable factory Message-ID: <1422807584.64.0.426042157217.issue23372@psf.upfronthosting.co.za> New submission from Alec Nikolas Reiter: Not something I've noticed until today, but defaultdict.fromkeys only accepts an iterable of keys and an initial value. To set the default_factory for the newly created collection, you need to prod at the attribute itself. This isn't a huge issue for me, however adding an optional default_factory to fromkeys would be a nice convenience. ---------- messages: 235180 nosy: justanr priority: normal severity: normal status: open title: defaultdict.fromkeys should accept a callable factory type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 17:47:15 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 01 Feb 2015 16:47:15 +0000 Subject: [issue23372] defaultdict.fromkeys should accept a callable factory In-Reply-To: <1422807584.64.0.426042157217.issue23372@psf.upfronthosting.co.za> Message-ID: <1422809235.49.0.320179865334.issue23372@psf.upfronthosting.co.za> SilentGhost added the comment: Correct me if I'm wrong but this seem as a very unlikely use case. Why would you need to ensure content of the defaultdict (i.e., why would you ever use its fromkeys method)? And, perhaps, having to implicitly assign default factory is not such a bad tradeoff, considering implementation overhead. ---------- components: +Library (Lib) nosy: +SilentGhost versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 18:03:21 2015 From: report at bugs.python.org (Alex Martelli) Date: Sun, 01 Feb 2015 17:03:21 +0000 Subject: [issue23373] curses.textpad crashes in insert mode on wide window Message-ID: <1422810201.83.0.833050049088.issue23373@psf.upfronthosting.co.za> New submission from Alex Martelli: http://stackoverflow.com/questions/28264353/stack-overflow-in-pythons-curses-is-it-bug-in-the-module/28264823#28264823 for details. a curses.textpad on a wide-enough window, in insert mode, causes a crash by recursion limit exceeded (in _insert_printable_char) upon edit. Workaround is to keep the window underlying the textpad sufficiently narrow. ---------- components: Library (Lib) messages: 235182 nosy: Alex.Martelli priority: normal severity: normal status: open title: curses.textpad crashes in insert mode on wide window type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 18:04:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Feb 2015 17:04:16 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <20150201170146.39274.77322@psf.io> Roundup Robot added the comment: New changeset 4f96e9a8eee8 by Serhiy Storchaka in branch 'default': Don't seek to the start of the file when open ZipFile with the 'w' mode https://hg.python.org/cpython/rev/4f96e9a8eee8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 18:16:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 17:16:27 +0000 Subject: [issue23252] Add support of writing to unseekable file in zipfile In-Reply-To: <1421438148.04.0.307260333821.issue23252@psf.upfronthosting.co.za> Message-ID: <1422810987.92.0.558681874193.issue23252@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. Mercurial wouldn't need a wrapper in Python 3.5. ---------- keywords: +patch nosy: +Matt.Mackall stage: needs patch -> patch review Added file: http://bugs.python.org/file37970/zipfile_write_unseekable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 18:25:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 17:25:11 +0000 Subject: [issue23362] integer overflow in string translate In-Reply-To: <1422798800.96.0.0931437199134.issue23362@psf.upfronthosting.co.za> Message-ID: <1422811511.41.0.17961963532.issue23362@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you want to provide a patch? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 18:33:46 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Feb 2015 17:33:46 +0000 Subject: [issue23371] mimetypes initialization fails on Windows because of TypeError In-Reply-To: <1422806320.68.0.990065034592.issue23371@psf.upfronthosting.co.za> Message-ID: <1422812026.32.0.957677386642.issue23371@psf.upfronthosting.co.za> R. David Murray added the comment: Is this a duplicate of issue 9291? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 18:33:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 17:33:48 +0000 Subject: [issue23372] defaultdict.fromkeys should accept a callable factory In-Reply-To: <1422807584.64.0.426042157217.issue23372@psf.upfronthosting.co.za> Message-ID: <1422812028.42.0.216421700724.issue23372@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:00:06 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 01 Feb 2015 18:00:06 +0000 Subject: [issue23372] defaultdict.fromkeys should accept a callable factory In-Reply-To: <1422807584.64.0.426042157217.issue23372@psf.upfronthosting.co.za> Message-ID: <1422813606.07.0.528769136833.issue23372@psf.upfronthosting.co.za> Raymond Hettinger added the comment: -0 I could see some use cases for this, dict.fromkeys(contestants, factory=list), but it adds complexity to a core container API and it starts to overlap the use cases for collections.defaultdict(). Perhaps set comprehensions should remain the one-obvious-way-to-do-it: {k : [] for k in contestants} ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:13:27 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Lenclud?=) Date: Sun, 01 Feb 2015 18:13:27 +0000 Subject: [issue23371] mimetypes initialization fails on Windows because of TypeError In-Reply-To: <1422806320.68.0.990065034592.issue23371@psf.upfronthosting.co.za> Message-ID: <1422814407.61.0.457285694931.issue23371@psf.upfronthosting.co.za> St?phane Lenclud added the comment: I don't think so. Here is the traceback btw: File "setup.py", line 18, in exec(init_file.read(), command_ns) File "", line 11, in File "c:\users\sl\appdata\local\temp\tmpoaaddk\setuptools-12.0.5\setuptools\__init__.py", line 11, in from setuptools.extension import Extension File "c:\users\sl\appdata\local\temp\tmpoaaddk\setuptools-12.0.5\setuptools\extension.py", line 8, in from .dist import _get_unpatched File "c:\users\sl\appdata\local\temp\tmpoaaddk\setuptools-12.0.5\setuptools\dist.py", line 16, in from setuptools.depends import Require File "c:\users\sl\appdata\local\temp\tmpoaaddk\setuptools-12.0.5\setuptools\depends.py", line 6, in from setuptools import compat File "c:\users\sl\appdata\local\temp\tmpoaaddk\setuptools-12.0.5\setuptools\compat.py", line 19, in from SimpleHTTPServer import SimpleHTTPRequestHandler File "C:\Python27\lib\SimpleHTTPServer.py", line 27, in class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): File "C:\Python27\lib\SimpleHTTPServer.py", line 214, in SimpleHTTPRequestHandler mimetypes.init() # try to read system mime.types File "C:\Python27\lib\mimetypes.py", line 351, in init db.read_windows_registry() File "C:\Python27\lib\mimetypes.py", line 254, in read_windows_registry with _winreg.OpenKey(hkcr, subkeyname) as subkey: TypeError: must be string without null bytes or None, not str Something went wrong during the installation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:15:25 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 01 Feb 2015 18:15:25 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1422814525.51.0.446215635517.issue23359@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thank Serhiy. No early-out on insertion is possible. For discard and contains, there is still no need for testing dummies and tracking freeslots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:21:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Feb 2015 18:21:09 +0000 Subject: [issue23370] PyBuffer_FromContiguous() off-by-one error for non-contiguous buffers In-Reply-To: <1422803151.79.0.434214643845.issue23370@psf.upfronthosting.co.za> Message-ID: <20150201182059.39286.14449@psf.io> Roundup Robot added the comment: New changeset 209776d49a9a by Stefan Krah in branch '2.7': Issue #23370: Fix off-by-one error for non-contiguous buffers. https://hg.python.org/cpython/rev/209776d49a9a New changeset 4d95956a748e by Stefan Krah in branch '3.4': Issue #23370: Fix off-by-one error for non-contiguous buffers. https://hg.python.org/cpython/rev/4d95956a748e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:27:01 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 01 Feb 2015 18:27:01 +0000 Subject: [issue23372] defaultdict.fromkeys should accept a callable factory In-Reply-To: <1422807584.64.0.426042157217.issue23372@psf.upfronthosting.co.za> Message-ID: <1422815221.97.0.227484494426.issue23372@psf.upfronthosting.co.za> SilentGhost added the comment: Raymond, but Alec talks about defaultdict.fromkeys(constants, factory=list) as opposed to current solution d = defaultdict.fromkeys(constants) d.default_factory = list for i in d: d[i] = [] I wouldn't think that the dict.fromkeys should be affected by this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:31:28 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Feb 2015 18:31:28 +0000 Subject: [issue23370] PyBuffer_FromContiguous() off-by-one error for non-contiguous buffers In-Reply-To: <1422803151.79.0.434214643845.issue23370@psf.upfronthosting.co.za> Message-ID: <1422815488.97.0.31912264429.issue23370@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:31:41 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Feb 2015 18:31:41 +0000 Subject: [issue23370] PyBuffer_FromContiguous() off-by-one error for non-contiguous buffers In-Reply-To: <1422803151.79.0.434214643845.issue23370@psf.upfronthosting.co.za> Message-ID: <1422815501.35.0.410916587738.issue23370@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:38:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 18:38:28 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1422815908.55.0.150088444487.issue23359@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are more ideas. I would probe to use set_lookkey_dummy_ignored() with following set_find_free_slot() (from set_faster_copy_2.patch in issue23290) if former hadn't find a key. If set hash == -1 for key == NULL, we can use only one comparison for testing key == NULL || key == dummy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:38:31 2015 From: report at bugs.python.org (Alec Nikolas Reiter) Date: Sun, 01 Feb 2015 18:38:31 +0000 Subject: [issue23372] defaultdict.fromkeys should accept a callable factory In-Reply-To: <1422807584.64.0.426042157217.issue23372@psf.upfronthosting.co.za> Message-ID: <1422815911.9.0.457206103108.issue23372@psf.upfronthosting.co.za> Alec Nikolas Reiter added the comment: @SilentGhost I was playing with a voting algorithm (Instant Runoff, rather than traditional majority). Ultimately, I ended up using Counter in place of a defaultdict, but that's how I ended up noticing it. Not so much ensuring the content so much as setting an initial default state to mutate. @rhettinger I had considered a comprehension and passing it into a defaultdict (or Counter) to get that nice missing key handling. Implicitly assigning the factory is a pretty good compromise, like I said fromkeys accepting the factory would be a nice convenience rather than correcting a major oversight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:50:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Feb 2015 18:50:57 +0000 Subject: [issue23352] Document "suboffsets if needed" in 2.7 In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <20150201185054.106379.39849@psf.io> Roundup Robot added the comment: New changeset c4c1d68b6301 by Stefan Krah in branch '2.7': Issue #23352: Document that Py_buffer.suboffsets must be NULL if no suboffsets https://hg.python.org/cpython/rev/c4c1d68b6301 New changeset de5c8ee002bf by Stefan Krah in branch '3.4': Issue #23352: Document that Py_buffer.suboffsets must be NULL if no suboffsets https://hg.python.org/cpython/rev/de5c8ee002bf New changeset 5d097a74766f by Stefan Krah in branch 'default': Issue #23352: Merge from 3.4. https://hg.python.org/cpython/rev/5d097a74766f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:51:05 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 01 Feb 2015 18:51:05 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1422816665.77.0.863485689456.issue12916@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi Martin, you reused my own patch for this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:53:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 18:53:22 +0000 Subject: [issue23372] defaultdict.fromkeys should accept a callable factory In-Reply-To: <1422807584.64.0.426042157217.issue23372@psf.upfronthosting.co.za> Message-ID: <1422816802.24.0.357754012998.issue23372@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It may be written simpler: d = defaultdict(factory) for i in constants: d[i] or d = defaultdict(factory, {i: factory() for i in constants}) I'm inclined to reject this proposition. It serves very special use case. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 19:55:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 18:55:55 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1422816955.33.0.00626989462404.issue22896@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please look at the patch Stefan? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 20:10:20 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 01 Feb 2015 19:10:20 +0000 Subject: [issue23371] mimetypes initialization fails on Windows because of TypeError In-Reply-To: <1422806320.68.0.990065034592.issue23371@psf.upfronthosting.co.za> Message-ID: <1422817820.42.0.958992807221.issue23371@psf.upfronthosting.co.za> Steve Dower added the comment: Definitely a dup, though I don't have the number handy. There's a patch on the other issue waiting for a mimetypes maintainer to step up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 20:22:39 2015 From: report at bugs.python.org (Tim Golden) Date: Sun, 01 Feb 2015 19:22:39 +0000 Subject: [issue23371] mimetypes initialization fails on Windows because of TypeError In-Reply-To: <1422817820.42.0.958992807221.issue23371@psf.upfronthosting.co.za> Message-ID: <54CE7CFE.30607@timgolden.me.uk> Tim Golden added the comment: It's right there on my to-do list which is, unfortunately, not getting any shorter. TJG On 01/02/2015 19:10, Steve Dower wrote: > > Steve Dower added the comment: > > Definitely a dup, though I don't have the number handy. There's a patch on the other issue waiting for a mimetypes maintainer to step up. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 20:24:18 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 01 Feb 2015 19:24:18 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package Message-ID: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> New submission from Skip Montanaro: I'm probably doing something wrong, but I've tried everything I can think of without any success. In Python 2.7, the pydoc command successfully displays help for the sqlite3 package, though it muffs the output of Gerhard H?ring's name, spitting out the original Latin-1 spelling. In Python 3.x, I get a UnicodeEncodeError for my trouble, and it hoses my tty settings to boot, requiring a LF reset LF sequence to put right unless I set PAGER to "cat". Here's a sample run: % PAGER=cat pydoc3.5 sqlite3 Traceback (most recent call last): File "/Users/skip/local/bin/pydoc3.5", line 5, in pydoc.cli() File "/Users/skip/local/lib/python3.5/pydoc.py", line 2591, in cli help.help(arg) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1874, in help elif request: doc(request, 'Help on %s:', output=self._output) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1612, in doc pager(render_doc(thing, title, forceload)) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1412, in pager pager(text) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1428, in return lambda text: pipepager(text, os.environ['PAGER']) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1455, in pipepager pipe.write(text) UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 600: ordinal not in range(128) I understand the error, but I see no way to convince it to use any codec other than "ascii". Stuff I tried: * setting PYTHONIOENCODING to "UTF-8" (suggested by Peter Otten on c.l.py) * setting LANG to "en_US.utf8" This is on a Mac running Yosemite with pydoc invoked in Apple's Terminal app. Display is fine in my browser when I run pydoc as a web server. The source it is attempting to display has a coding cookie, so it should know that the code is encoded using Latin-1. The problem seems to all be about generating output. ---------- components: Library (Lib) messages: 235200 nosy: skip.montanaro priority: normal severity: normal status: open title: pydoc 3.x raises UnicodeEncodeError on sqlite3 package type: crash versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 20:51:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 19:51:30 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <1422820290.9.0.329189755834.issue23374@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What are sys.getfilesystemencoding(), locale.getpreferredencoding(False), os.popen('cat', 'w').encoding? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 21:15:41 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 01 Feb 2015 20:15:41 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422820290.9.0.329189755834.issue23374@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: Without setting any environment variables: >>> import sys >>> sys.getfilesystemencoding() 'utf-8' >>> import locale >>> locale.getpreferredencoding(False) 'US-ASCII' >>> import os >>> os.popen('cat', 'w').encoding 'US-ASCII' If I set PYTHONIOENCODING=UTF-8: >>> import sys, locale, os >>> sys.getfilesystemencoding() 'utf-8' >>> locale.getpreferredencoding(False) 'US-ASCII' >>> os.popen('cat', 'w').encoding 'US-ASCII' If I set LANG=en_US.utf8: >>> import sys, locale, os >>> sys.getfilesystemencoding() 'utf-8' >>> locale.getpreferredencoding(False) 'US-ASCII' >>> os.popen('cat', 'w').encoding 'US-ASCII' It appears neither of these environment variables does much in my environment. I should point out that I just updated to Mac OS X 10.10.2 a couple days ago. I have no idea if this problem existed before that upgrade. Realizing that perhaps something had changed in the underlying operating system support, I rebuilt Python 2.6 through 3.5 from scratch. Same result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 21:19:07 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 01 Feb 2015 20:19:07 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: Message-ID: Skip Montanaro added the comment: Peter Otten posted a solution on c.l.py. The issue is that I didn't mix my case properly when setting LANG: hgpython% LANG=en_US.UTF-8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' UTF-8 hgpython% LANG=en_US.utf8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' US-ASCII ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 21:26:39 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 01 Feb 2015 20:26:39 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: Message-ID: Skip Montanaro added the comment: On Sun, Feb 1, 2015 at 2:19 PM, Skip Montanaro wrote: > The issue is that I didn't > mix my case properly when setting LANG: Actually, it's that the hyphen is required in "utf-8" or "UTF-8". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 21:32:24 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Feb 2015 20:32:24 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1422822744.91.0.589858199011.issue22896@psf.upfronthosting.co.za> Stefan Krah added the comment: [Slow internet connection, can't use Rietveld.] CDataType_from_buffer(): I'm not that familiar with ctypes. What is the high level goal here? Allocate a chunk of memory, wrap it in a memoryview and have the memoryview release that memory when its refcount is 0? If so, I think we desperately need direct support for that in memoryview. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 21:59:39 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 01 Feb 2015 20:59:39 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: Message-ID: Skip Montanaro added the comment: Final note here. Peter also did a bit of digging. Here's his note about what he found on c.l.py: The pager is invoked by os.popen(), and after some digging I find that it uses a io.TestIOWrapper() to write the help text. This in turn uses locale.getpreferredencoding(False), i. e. you were right to set LANG and PYTHONIOENCODING is not relevant. I was also able to provoke this problem on an openSuSE 12.2 system with 3.2.3 installed. In that environment (confirmed by Chris Angelico on his Linux system), the case of "utf" didn't matter, nor did it matter if "utf-8" was hyphenated or not. Obviously the Mac continues to be a rather touchy system w.r.t. locale. I don't know if Python should try to be accommodating here, but my inclination is "no". OTOH, maybe io.TestIOWrapper should look at PYTHONIOENCODING, or the pager should be invoked through something other than os.popen (assuming there is a suitable replacement which does pay attention to PYTHONIOENCODING). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:03:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 21:03:38 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1422824618.77.0.6890097868.issue12916@psf.upfronthosting.co.za> Martin Panter added the comment: Yes, this is based on your patch, St?phane. On top of it I added support for splitdoc(None), and made the other changes in the bullet points. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:16:48 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 21:16:48 +0000 Subject: [issue23361] integer overflow in winapi_createprocess In-Reply-To: <1422798703.49.0.874007534993.issue23361@psf.upfronthosting.co.za> Message-ID: <1422825408.89.0.501257331786.issue23361@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:16:58 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 21:16:58 +0000 Subject: [issue23362] integer overflow in string translate In-Reply-To: <1422798800.96.0.0931437199134.issue23362@psf.upfronthosting.co.za> Message-ID: <1422825418.1.0.421354504823.issue23362@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:17:08 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 21:17:08 +0000 Subject: [issue23363] integer overflow in itertools.permutations In-Reply-To: <1422798853.28.0.166749700091.issue23363@psf.upfronthosting.co.za> Message-ID: <1422825428.44.0.637917931676.issue23363@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:17:21 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 21:17:21 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <1422825441.28.0.163572876038.issue23364@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:17:29 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 21:17:29 +0000 Subject: [issue23365] integer overflow in itertools.combinations_with_replacement In-Reply-To: <1422798943.75.0.0941782409051.issue23365@psf.upfronthosting.co.za> Message-ID: <1422825449.45.0.375648696808.issue23365@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:17:40 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 21:17:40 +0000 Subject: [issue23366] integer overflow in itertools.combinations In-Reply-To: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> Message-ID: <1422825460.14.0.34520048244.issue23366@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:17:48 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 21:17:48 +0000 Subject: [issue23367] integer overflow in unicodedata.normalize In-Reply-To: <1422799035.27.0.978256662941.issue23367@psf.upfronthosting.co.za> Message-ID: <1422825468.97.0.953290464272.issue23367@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:17:59 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 21:17:59 +0000 Subject: [issue23368] integer overflow in _PyUnicode_AsKind In-Reply-To: <1422799119.61.0.313717828667.issue23368@psf.upfronthosting.co.za> Message-ID: <1422825479.05.0.821392281234.issue23368@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:18:10 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Feb 2015 21:18:10 +0000 Subject: [issue23369] integer overflow in _json.encode_basestring_ascii In-Reply-To: <1422799175.9.0.580347379364.issue23369@psf.upfronthosting.co.za> Message-ID: <1422825490.21.0.385303216071.issue23369@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:32:48 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 21:32:48 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <1422826368.27.0.663257717805.issue23374@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe because a pager sends its bytes more-or-less straight throught from input to output, the PYTHONIOENCODING (sys.stdout.encoding?) should be used for the TextIOWrapper to the pager?s input in this case. I?m not so sure this should be assumed in general though. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:43:51 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 01 Feb 2015 21:43:51 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1422827031.29.0.290783563001.issue22818@psf.upfronthosting.co.za> Ezio Melotti added the comment: DeprecationWarning: Base class for warnings about deprecated features. UserWarning: Base class for warnings generated by user code. RuntimeWarning: Base class for warnings about dubious runtime behavior. FutureWarning: Base class for warnings about constructs that will change semantically in the future. I think FutureWarning would be a good choice here, since we are going to change the semantics of a construct (before zero-width pattern didn't split -> in the future they will). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 22:52:44 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 01 Feb 2015 21:52:44 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1422827564.52.0.111144343508.issue22896@psf.upfronthosting.co.za> Martin Panter added the comment: _CData.from_buffer() is meant to take a writable buffer, and create a ?ctypes? object that shares the same memory. So it should not release the buffer until that ?ctypes? object is no longer needed. However I don?t know the insides of memoryview() objects that well so I can?t say if the hack-the-memoryview code is correct or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 23:13:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 22:13:01 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1422828781.74.0.0703292308184.issue22896@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: from_buffer() uses a memory buffer of other object. It keeps a reference to the object to prevent deallocation of memory when there will be no more external references. But this doesn't prevent from reallocating of memory of living object (e.g. for resizing of bytearray). So we need to grab the buffer (with PyObject_GetBuffer) in from_buffer() and free it (with PyBuffer_Release) when it is no longer needed. menoryview can do this but needs a hack, because a memoryview created by PyMemoryView_FromBuffer() doesn't release the buffer. May be there is more official way? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 1 23:15:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Feb 2015 22:15:29 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1422828929.49.0.794758024251.issue22896@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, Martin expressed the same thing better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 00:00:19 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Feb 2015 23:00:19 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <1422831619.86.0.285760513674.issue23374@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 00:02:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Feb 2015 23:02:33 +0000 Subject: [issue23369] integer overflow in _json.encode_basestring_ascii In-Reply-To: <1422799175.9.0.580347379364.issue23369@psf.upfronthosting.co.za> Message-ID: <20150201230226.96080.70774@psf.io> Roundup Robot added the comment: New changeset 8699b3085db3 by Benjamin Peterson in branch '3.3': fix possible overflow in encode_basestring_ascii (closes #23369) https://hg.python.org/cpython/rev/8699b3085db3 New changeset 4f47509d7417 by Benjamin Peterson in branch '3.4': merge 3.3 (#23369) https://hg.python.org/cpython/rev/4f47509d7417 New changeset 02aeca4974ac by Benjamin Peterson in branch 'default': merge 3.4 (#23369) https://hg.python.org/cpython/rev/02aeca4974ac ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 01:54:04 2015 From: report at bugs.python.org (Link Mauve) Date: Mon, 02 Feb 2015 00:54:04 +0000 Subject: [issue22623] Missing guards for some POSIX functions In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za> Message-ID: <1422838444.26.0.287193908006.issue22623@psf.upfronthosting.co.za> Link Mauve added the comment: This issue is still present in latest 3.5, all the way down to 2.7. ---------- components: +Extension Modules -Build versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file37971/guards.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 01:54:24 2015 From: report at bugs.python.org (Link Mauve) Date: Mon, 02 Feb 2015 00:54:24 +0000 Subject: [issue22623] Missing guards for some POSIX functions In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za> Message-ID: <1422838464.53.0.756043517888.issue22623@psf.upfronthosting.co.za> Changes by Link Mauve : Removed file: http://bugs.python.org/file36898/f3cf19e38efe.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 02:39:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 02 Feb 2015 01:39:57 +0000 Subject: [issue23373] curses.textpad crashes in insert mode on wide window In-Reply-To: <1422810201.83.0.833050049088.issue23373@psf.upfronthosting.co.za> Message-ID: <1422841197.96.0.96615986048.issue23373@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. This is a duplicate of issue 13051. The insert_mode parameter was committed in issue 1048820. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Infinite recursion in curses.textpad.Textbox type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 03:04:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Feb 2015 02:04:58 +0000 Subject: [issue23366] integer overflow in itertools.combinations In-Reply-To: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> Message-ID: <20150202020453.34398.96230@psf.io> Roundup Robot added the comment: New changeset 014886dae5c4 by Benjamin Peterson in branch '3.3': detect overflow in combinations (closes #23366) https://hg.python.org/cpython/rev/014886dae5c4 New changeset 2f73de7ffcf5 by Benjamin Peterson in branch '3.4': merge 3.3 (#23366) https://hg.python.org/cpython/rev/2f73de7ffcf5 New changeset 886559229911 by Benjamin Peterson in branch 'default': merge 3.4 (#23366) https://hg.python.org/cpython/rev/886559229911 New changeset fe203370c049 by Benjamin Peterson in branch '2.7': detect overflow in combinations (closes #23366) https://hg.python.org/cpython/rev/fe203370c049 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 03:13:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Feb 2015 02:13:54 +0000 Subject: [issue23365] integer overflow in itertools.combinations_with_replacement In-Reply-To: <1422798943.75.0.0941782409051.issue23365@psf.upfronthosting.co.za> Message-ID: <20150202021349.106271.5451@psf.io> Roundup Robot added the comment: New changeset 93d445cd5f70 by Benjamin Peterson in branch '3.3': check for overflow in combinations_with_replacement (closes #23365) https://hg.python.org/cpython/rev/93d445cd5f70 New changeset 2e7a02e4cf2c by Benjamin Peterson in branch '3.4': merge 3.3 (#23365) https://hg.python.org/cpython/rev/2e7a02e4cf2c New changeset 4d875a690c01 by Benjamin Peterson in branch 'default': merge 3.4 (#23365) https://hg.python.org/cpython/rev/4d875a690c01 New changeset 366018a91457 by Benjamin Peterson in branch '2.7': check for overflow in combinations_with_replacement (closes #23365) https://hg.python.org/cpython/rev/366018a91457 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 03:15:18 2015 From: report at bugs.python.org (Ricky Zhou) Date: Mon, 02 Feb 2015 02:15:18 +0000 Subject: [issue16632] Enable DEP and ASLR In-Reply-To: <1354875781.46.0.686705865065.issue16632@psf.upfronthosting.co.za> Message-ID: <1422843318.97.0.704012075962.issue16632@psf.upfronthosting.co.za> Ricky Zhou added the comment: Sorry to revive this old bug, but would it be possible to get ASLR/DEP for windows on the 2.7 branch as well? Also, re Christian's comment about DEP being disabled if a single libray doesn't support it - are you sure that's the case? I'm very new to windows stuff, but the only information about this I saw online was http://0xdabbad00.com/2012/12/07/dep-data-execution-prevention-explanation/, which says that only /NXCOMPAT on the EXE matters. ---------- nosy: +ricky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 03:18:22 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Feb 2015 02:18:22 +0000 Subject: [issue23360] Content-Type when sending data with urlopen() In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za> Message-ID: <1422843502.34.0.136217197635.issue23360@psf.upfronthosting.co.za> Martin Panter added the comment: Updated patch to explain that a Request object is generated internally for urlopen(data=...), and added a test to confirm. Also removed some confusing dead code. ---------- Added file: http://bugs.python.org/file37972/non-urlencoded.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 03:39:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Feb 2015 02:39:04 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <20150202023853.39278.73094@psf.io> Roundup Robot added the comment: New changeset 7133582b6769 by Benjamin Peterson in branch '3.3': check for overflows in permutations() and product() (closes #23363, closes #23364) https://hg.python.org/cpython/rev/7133582b6769 New changeset 9ae055c3db32 by Benjamin Peterson in branch '3.4': merge 3.3 (#23364, #23363) https://hg.python.org/cpython/rev/9ae055c3db32 New changeset 31dc5a40d2ab by Benjamin Peterson in branch 'default': merge 3.4 (#23364, #23363) https://hg.python.org/cpython/rev/31dc5a40d2ab New changeset acc2c3479f2e by Benjamin Peterson in branch '2.7': check for overflows in permutations() and product() (closes #23363, closes #23364) https://hg.python.org/cpython/rev/acc2c3479f2e ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 03:39:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Feb 2015 02:39:04 +0000 Subject: [issue23363] integer overflow in itertools.permutations In-Reply-To: <1422798853.28.0.166749700091.issue23363@psf.upfronthosting.co.za> Message-ID: <20150202023853.39278.54692@psf.io> Roundup Robot added the comment: New changeset 7133582b6769 by Benjamin Peterson in branch '3.3': check for overflows in permutations() and product() (closes #23363, closes #23364) https://hg.python.org/cpython/rev/7133582b6769 New changeset 9ae055c3db32 by Benjamin Peterson in branch '3.4': merge 3.3 (#23364, #23363) https://hg.python.org/cpython/rev/9ae055c3db32 New changeset 31dc5a40d2ab by Benjamin Peterson in branch 'default': merge 3.4 (#23364, #23363) https://hg.python.org/cpython/rev/31dc5a40d2ab New changeset acc2c3479f2e by Benjamin Peterson in branch '2.7': check for overflows in permutations() and product() (closes #23363, closes #23364) https://hg.python.org/cpython/rev/acc2c3479f2e ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 03:55:48 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 02 Feb 2015 02:55:48 +0000 Subject: [issue23254] Document how to close the TCPServer listening socket In-Reply-To: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za> Message-ID: <1422845748.5.0.453085722977.issue23254@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 04:07:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 02 Feb 2015 03:07:25 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422846445.07.0.750092219767.issue23357@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +vinay.sajip stage: -> patch review versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 04:24:33 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Feb 2015 03:24:33 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1422847473.89.0.820155048866.issue23099@psf.upfronthosting.co.za> Martin Panter added the comment: Here is an option that moves the documentation for discarding the buffer into the class description for both BytesIO and StringIO; what do you think? I would be happy enough with any of the last three patches, so I don?t want to hold this up forever :) ---------- Added file: http://bugs.python.org/file37973/bytesio_exported_reject_close.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 07:33:46 2015 From: report at bugs.python.org (Zeke) Date: Mon, 02 Feb 2015 06:33:46 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1422858826.95.0.597737352905.issue7434@psf.upfronthosting.co.za> Changes by Zeke : ---------- nosy: +Ezekiel.Fairfax _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 07:33:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 06:33:51 +0000 Subject: [issue23365] integer overflow in itertools.combinations_with_replacement In-Reply-To: <1422798943.75.0.0941782409051.issue23365@psf.upfronthosting.co.za> Message-ID: <1422858831.12.0.151834123121.issue23365@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The test needs 4GiB. May be use 2**29? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 07:51:59 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 02 Feb 2015 06:51:59 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1422824618.77.0.6890097868.issue12916@psf.upfronthosting.co.za> Message-ID: <8653A07B-A762-4145-AFD0-7873CF3E5F5C@wirtel.be> St?phane Wirtel added the comment: On 1 Feb 2015, at 22:03, Martin Panter wrote: > Martin Panter added the comment: > > Yes, this is based on your patch, St?phane. On top of it I added > support for splitdoc(None), and made the other changes in the bullet > points. Great good news. Hope these patches will be accepted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 07:59:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 06:59:29 +0000 Subject: [issue23363] integer overflow in itertools.permutations In-Reply-To: <1422798853.28.0.166749700091.issue23363@psf.upfronthosting.co.za> Message-ID: <1422860369.55.0.577257672854.issue23363@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: An overflow in n * sizeof(Py_ssize_t) is not possible because n is the length of already allocated array of pointers. + with self.assertRaises(OverflowError): + permutations("A", 2**30) The test needs 4GiB. May be use 2**29? + with self.assertRaises(OverflowError): + permutations("A", 2, 2**30) permutations() takes at most 2 arguments. ---------- nosy: +serhiy.storchaka status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 08:01:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 07:01:42 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <1422860502.28.0.579324197749.issue23364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: + with self.assertRaises(OverflowError): + product(["a"]*(2**16), repeat=2**16) The test needs 16GiB. May be use repeat=2**13? ---------- nosy: +serhiy.storchaka status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 08:05:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 07:05:08 +0000 Subject: [issue23366] integer overflow in itertools.combinations In-Reply-To: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> Message-ID: <1422860708.04.0.140205429116.issue23366@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This commit (and three other) causes compiler warnings: ./Modules/itertoolsmodule.c: In function ?product_new?: ./Modules/itertoolsmodule.c:2025:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (repeat > PY_SSIZE_T_MAX/sizeof(Py_ssize_t) || ^ ./Modules/itertoolsmodule.c:2026:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] nargs > PY_SSIZE_T_MAX/(repeat * sizeof(Py_ssize_t))) { ^ ./Modules/itertoolsmodule.c: In function ?combinations_new?: ./Modules/itertoolsmodule.c:2371:11: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (r > PY_SSIZE_T_MAX/sizeof(Py_ssize_t)) { ^ ./Modules/itertoolsmodule.c: In function ?cwr_new?: ./Modules/itertoolsmodule.c:2716:11: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (r > PY_SSIZE_T_MAX/sizeof(Py_ssize_t)) { ^ ./Modules/itertoolsmodule.c: In function ?permutations_new?: ./Modules/itertoolsmodule.c:3061:11: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (n > PY_SSIZE_T_MAX/sizeof(Py_ssize_t) || ^ ./Modules/itertoolsmodule.c:3062:11: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] r > PY_SSIZE_T_MAX/sizeof(Py_ssize_t)) { ^ May be use PyMem_New instead of PyMem_Malloc? ---------- keywords: +patch nosy: +serhiy.storchaka status: closed -> open Added file: http://bugs.python.org/file37974/itertools_overflows.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 08:06:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 07:06:27 +0000 Subject: [issue23365] integer overflow in itertools.combinations_with_replacement In-Reply-To: <1422798943.75.0.0941782409051.issue23365@psf.upfronthosting.co.za> Message-ID: <1422860787.21.0.28734350731.issue23365@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 08:21:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 07:21:29 +0000 Subject: [issue23375] test_py3kwarn fails on Windows Message-ID: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: http://buildbot.python.org/all/builders/x86%20XP-4%202.7/builds/3092/steps/test/logs/stdio ====================================================================== FAIL: test_optional_module_removals (test.test_py3kwarn.TestStdlibRemovals) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_py3kwarn.py", line 395, in test_optional_module_removals self.check_removal(module_name, optional=True) File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_py3kwarn.py", line 379, in check_removal .format(module_name)) AssertionError: DeprecationWarning not raised for imageop ---------------------------------------------------------------------- ---------- components: Windows messages: 235228 nosy: serhiy.storchaka, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: test_py3kwarn fails on Windows type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 08:32:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 07:32:50 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1422862370.88.0.149745251118.issue23099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 08:33:20 2015 From: report at bugs.python.org (paul) Date: Mon, 02 Feb 2015 07:33:20 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <1422862400.64.0.673677903214.issue23364@psf.upfronthosting.co.za> paul added the comment: Why do you think this test needs 16GiB? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 08:35:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 07:35:22 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <1422862522.85.0.865057533148.issue23364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 2**16 * 2**16 * sizeof(Py_ssize_t) = 16GiB ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 09:03:29 2015 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 02 Feb 2015 08:03:29 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422864209.91.0.420911872409.issue23357@psf.upfronthosting.co.za> Vinay Sajip added the comment: Thanks for the suggestion, but (a) I don't think it's worth making this change. (b) Your change still won't do the right thing in all cases. (c) Your approach (of passing a parameter just for this) doesn't feel right. For example, what if pyvenv is invoked using a symlink such as pyvenv-3.4? Your code would say "pyvenv", which seems "just as wrong" as saying "venv". I don't believe the current state of affairs is really confusing (it hasn't been brought up before) - and even if it is, the right fix seems to be to mention in the documentation that the usage statement may vary slightly depending on exactly how the venv functionality is invoked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 09:16:34 2015 From: report at bugs.python.org (paul) Date: Mon, 02 Feb 2015 08:16:34 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <1422864994.48.0.383979238069.issue23364@psf.upfronthosting.co.za> paul added the comment: You mean 64bit? On 32 it'll overflow and that's the point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 09:29:48 2015 From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=) Date: Mon, 02 Feb 2015 08:29:48 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422865788.7.0.542176173572.issue23357@psf.upfronthosting.co.za> Ra?l Cumplido added the comment: So, do you think that maybe adding something to the documentation. Or we just leave it as it is? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 09:41:03 2015 From: report at bugs.python.org (Tim Golden) Date: Mon, 02 Feb 2015 08:41:03 +0000 Subject: [issue20709] os.utime(path_to_directory): wrong documentation for Windows. In-Reply-To: <1392937056.04.0.541478480244.issue20709@psf.upfronthosting.co.za> Message-ID: <1422866463.19.0.0689611129095.issue20709@psf.upfronthosting.co.za> Tim Golden added the comment: I think we should simply take out the example, ie the part in brackets. The statement remains true but I don't think we need to cast around for whichever OS / filesystem happens to implement this particular setup. ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 10:54:34 2015 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 02 Feb 2015 09:54:34 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422870874.17.0.0682276860621.issue23357@psf.upfronthosting.co.za> Vinay Sajip added the comment: I will add to the documentation, and leave this issue open till I've done that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 11:17:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 10:17:12 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422872232.19.0.410385700385.issue23357@psf.upfronthosting.co.za> STINNER Victor added the comment: > Added tests (hope is what you expect) and changed some bits on the test file to be pep8 comliant. Nooo, please don't change two things in same patch: open a new issue for your PEP 8 changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 11:23:51 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 02 Feb 2015 10:23:51 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1422872631.81.0.0349720331675.issue23359@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Before doing more study on the other variants, I would like to get the second transformation done (avoiding the mask computation in the case where there is no wrap-around). Attaching a patch for just that step. ---------- Added file: http://bugs.python.org/file37975/hoist_mask_only.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 11:41:06 2015 From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=) Date: Mon, 02 Feb 2015 10:41:06 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422873666.81.0.286403476536.issue23357@psf.upfronthosting.co.za> Ra?l Cumplido added the comment: thanks for the comments. @haypo I'll add a new one for the pep8 fixes, sorry. @vinay.sajip I would like to help and try to do the change myself, if this is ok with you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 12:17:24 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 02 Feb 2015 11:17:24 +0000 Subject: [issue20709] os.utime(path_to_directory): wrong documentation for Windows. In-Reply-To: <1392937056.04.0.541478480244.issue20709@psf.upfronthosting.co.za> Message-ID: <1422875844.88.0.507556108676.issue20709@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm not sure we support 2.7 supports any versions of Windows earlier than XP. If so, we could drop the provision entirely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 12:24:26 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 11:24:26 +0000 Subject: [issue16632] Enable DEP and ASLR In-Reply-To: <1354875781.46.0.686705865065.issue16632@psf.upfronthosting.co.za> Message-ID: <1422876266.74.0.00954406452601.issue16632@psf.upfronthosting.co.za> STINNER Victor added the comment: I reopen the issue, so the question of porting the change to Python 2.7 can be replied. ---------- nosy: +steve.dower resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 12:25:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 11:25:17 +0000 Subject: [issue23321] Crash in str.decode() with special error handler In-Reply-To: <1422227773.79.0.793422498408.issue23321@psf.upfronthosting.co.za> Message-ID: <1422876317.72.0.419162664219.issue23321@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 12:25:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 11:25:23 +0000 Subject: [issue23321] Crash in str.decode() with special error handler In-Reply-To: <1422227773.79.0.793422498408.issue23321@psf.upfronthosting.co.za> Message-ID: <1422876323.72.0.784946350333.issue23321@psf.upfronthosting.co.za> STINNER Victor added the comment: I closed the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 12:50:38 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Feb 2015 11:50:38 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422877838.44.0.462787071213.issue23255@psf.upfronthosting.co.za> Martin Panter added the comment: You?re welcome to merge my test patch into yours if you want to. Or I could open a separate issue for it, I don?t mind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:10:22 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 12:10:22 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check Message-ID: <1422879022.25.0.491994888207.issue23376@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: skrah priority: normal severity: normal status: open title: getargs.c: redundant C-contiguity check type: performance versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:17:17 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 12:17:17 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check Message-ID: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> New submission from Stefan Krah: The call to PyBuffer_IsContiguous() (see patch) is redundant: PyBUF_WRITABLE is a flag that can be added to any buffer request. The real request here is (PyBUF_SIMPLE|PyBUF_WRITABLE), which is equal to PyBUF_WRITABLE since PyBUF_SIMPLE==0. PyBUF_SIMPLE implies C-contiguous with format 'B'. Perhaps the check was added for broken buffer providers, but I think at some point we should assume correct providers. ---------- keywords: +patch nosy: +larry Added file: http://bugs.python.org/file37976/issue23376.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:21:32 2015 From: report at bugs.python.org (Mark Shannon) Date: Mon, 02 Feb 2015 12:21:32 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <1422879692.33.0.367102100012.issue21295@psf.upfronthosting.co.za> Mark Shannon added the comment: This is caused by https://hg.python.org/cpython/rev/7c5c678e4164/ which is a supposed fix for http://bugs.python.org/issue16795 which claims to make "some changes to AST to make it more useful for static language analysis", seemingly by breaking all existing static analysis tools. Could we just revert https://hg.python.org/cpython/rev/7c5c678e4164/ ? ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:23:40 2015 From: report at bugs.python.org (Mark Shannon) Date: Mon, 02 Feb 2015 12:23:40 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <1422879820.14.0.158877033899.issue21295@psf.upfronthosting.co.za> Mark Shannon added the comment: It is now very hard to determine accurate locations for an expression such as (x+y).attr as the column offset of leftmost subexpression of the expression is not the same as the column offset of the location. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:45:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 12:45:18 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1422881118.16.0.740807882173.issue23376@psf.upfronthosting.co.za> STINNER Victor added the comment: Do you have unit test with non contiguous buffers? If not, it would help to have such buffer in _testcapi. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:52:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 12:52:00 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1422881520.84.0.737814862238.issue23376@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think memoryview(bytearray)[::2] provides non contiguous buffers. But I'm not sure this is tested. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:52:30 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Feb 2015 12:52:30 +0000 Subject: [issue13322] buffered read() and write() does not raise BlockingIOError In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za> Message-ID: <1422881550.14.0.255323463545.issue13322@psf.upfronthosting.co.za> Martin Panter added the comment: Looking at test_io.BufferedReaderTest.test_read_non_blocking(), at Lib/test/test_io.py:1037, there are explicit tests for ?peek(1) == b"" ? and ?read() is None?. The peek() test was added in revision 3049ac17e256, in 2009 (large merge of ?io? implementation in C; can?t find more detailed history). The read() test was added in revision 21233c2e5d09 in 2007, with a remark about a ?tentative decision to drop nonblocking I/O support from the buffering layers?. My suggestion is to make the read/into/1/all/peek() methods all return None if no non-blocking data is available, and return a short non-empty result if some data was available but not enough to satisfy the equivalent blocking call. However, this would invove changing the behaviour of BufferedReader.read1() and peek(); would that be allowed? The readline() based methods could probably work similarly, but that would be another issue and a bigger change, because the equivalent RawIOBase methods do not return None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:53:44 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 12:53:44 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1422881624.86.0.937488503209.issue23376@psf.upfronthosting.co.za> Stefan Krah added the comment: Yes, _testbuffer.ndarray can create any buffer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:56:17 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Feb 2015 12:56:17 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response Message-ID: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> New submission from Martin Panter: This is the same issue raised at . Currently, every time a new response is to be received, HTTPConnection passes its raw socket object to HTTPResponse, which calls sock.makefile("rb") and creates a BufferedReader. The BufferedReader is used to parse the header section and read the response body. The problem is that the BufferedReader is closed at the end of reading the response, potentially losing buffered data read from a subsequent response. Normally no data is lost, because most users would read the full response before triggering a new request, and the server would wait for a request before sending a response. But if a user pipelined a second request without reading all of the first response, and the server happened to send the end of the first response and the start of the second response in the same packet, it could trigger the problem. I have added a test called test_httplib.ServerTest.testDoubleResponse() which emulates this scenario. The problem also makes it hard to detect misbehaving servers, or use HTTPConnection to test that a server is behaving correctly. I am adding a patch which creates the BufferedReader once for each connection. This involves changing the API of the HTTPResponse constructor. I think this should be okay because even though it is documented, it says ?Not instantiated directly by user?. It did require changing the tests that call the HTTPResponse constructor though. If absolutely necessary, it may be possible to maintain backwards compatibility if we added a new constructor parameter, and carefully juggled how the close() calls work. ---------- components: Library (Lib) files: http-buffer.patch keywords: patch messages: 235251 nosy: vadmium priority: normal severity: normal status: open title: HTTPResponse may drop buffer holding next response type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file37977/http-buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:59:10 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 12:59:10 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1422881950.38.0.561787425656.issue23376@psf.upfronthosting.co.za> Stefan Krah added the comment: A unit test would not be so helpful. The potential problem is that third party extensions with broken getbufferprocs would suffer. But at some point we have to streamline PEP-3118 code, or it will remain inscrutable forever. Extension writers often copy code from cpython, and I'm afraid if we don't remove redundancy, people will think such contiguity checks are necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 13:59:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 12:59:37 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1422881977.51.0.325507115094.issue23376@psf.upfronthosting.co.za> STINNER Victor added the comment: > Yes, _testbuffer.ndarray can create any buffer. Cool. So could you please add non regression tests to test_w_star() of test_getargs2? Other formats expect a contiguous buffer: 'y*', 's*', 'z*'. Formats which "convert" a buffer: 'y', 's#', 'z#. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 14:03:17 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Feb 2015 13:03:17 +0000 Subject: [issue4879] Allow buffering for HTTPResponse In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za> Message-ID: <1422882197.24.0.832891716072.issue4879@psf.upfronthosting.co.za> Martin Panter added the comment: Opened Issue 23377 for the problem of dropping extra buffered data at the end of a response. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 14:04:06 2015 From: report at bugs.python.org (koobs) Date: Mon, 02 Feb 2015 13:04:06 +0000 Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++ compilation In-Reply-To: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za> Message-ID: <1422882246.08.0.162321011391.issue10910@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 14:09:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 13:09:28 +0000 Subject: [issue23369] integer overflow in _json.encode_basestring_ascii In-Reply-To: <1422799175.9.0.580347379364.issue23369@psf.upfronthosting.co.za> Message-ID: <1422882568.25.0.916544938298.issue23369@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: "\uffff"*((2**32)//6 + 1) is calculated at compile time. This requires much memory and can cause swapping. May be this was a cause of failing tests on some buildbots: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/2623/steps/test/logs/stdio http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4/builds/749/steps/test/logs/stdio Traceback (most recent call last): File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/regrtest.py", line 1564, in main_in_temp_cwd main() File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_json: Exit code -9 *** [buildbottest] Error code 1 At least my computer hanged on first run of this test. To prevent computing this string constant at compile time you can use a variable. And '\x00' can be used instead of '\uffff', it needs less memory. ---------- keywords: +patch nosy: +serhiy.storchaka status: closed -> open Added file: http://bugs.python.org/file37978/test_encode_basestring_ascii_overflow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 14:09:51 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 13:09:51 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1422828781.74.0.0703292308184.issue22896@psf.upfronthosting.co.za> Message-ID: <20150202130939.GA15261@bytereef.org> Stefan Krah added the comment: Thanks. No, I don't think there's an official way to accomplish that, but let's create one. How about a new function that takes the buffer request flags: PyMemoryView_FromObjectEx(exporter, PyBUF_SIMPLE|PyBUF_WRITABLE) If we can spare a new format code, this could be called directly in PyArg_ParseTuple(), which would give back the memoryview. Otherwise, you get the exporter from PyArg_ParseTuple() and call PyMemoryView_FromObjectEx() manually. If I'm not mistaken, this would save us the intermediate buffer on the stack, and it's more readable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 14:15:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 13:15:53 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1422882953.52.0.191894962129.issue22896@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In any case we need a hack in 3.4. Let open new issue for adding PyMemoryView_FromObjectEx() or like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 14:39:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 13:39:17 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422881977.51.0.325507115094.issue23376@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > A unit test would not be so helpful. The potential problem is that > third party extensions with broken getbufferprocs would suffer. I don't understand the link between third party extensions and test_getargs2. test_getargs2 is a unit test for non-regression of CPython. Can you please elaborate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 14:53:30 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 13:53:30 +0000 Subject: [issue20709] os.utime(path_to_directory): wrong documentation for Windows. In-Reply-To: <1392937056.04.0.541478480244.issue20709@psf.upfronthosting.co.za> Message-ID: <1422885210.26.0.462721194618.issue20709@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: Windows is the only Python-supported platform where utime did not work for directories, ages ago, right? If that is the case, I support Larry Hastings' approach of removing the entire sentence: "Whether a directory can be given for path depends on whether the operating system implements directories as files (for example, *Windows does not*)" Agreed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 15:23:10 2015 From: report at bugs.python.org (the mulhern) Date: Mon, 02 Feb 2015 14:23:10 +0000 Subject: [issue23378] argparse.add_argument action parameter should allow value extend Message-ID: <1422886990.52.0.318776752581.issue23378@psf.upfronthosting.co.za> New submission from the mulhern: As well as the append action it would be convenient for there to be an extend action. This is kind of useful to allow something like: parser.add_argument("--foo", action="extend", nargs="+", type=str) given parser.parse_args("--foo f1 --foo f2 f3 f4".split()) to result in ["f1", "f2", "f3", "f4"]. The action "append" results in [["f1"], ["f2", "f3", "f4"]] And action store in ["f2", "f3", "f4"]. It is easy to write a custom action, but it feels like a fairly common requirement. Probably it would make sense to extend the default, similarly to how append behaves. ---------- components: Library (Lib) messages: 235260 nosy: the.mulhern priority: normal severity: normal status: open title: argparse.add_argument action parameter should allow value extend type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 15:30:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 14:30:42 +0000 Subject: [issue23337] [IDLE/Windows] Run python with restricted rights In-Reply-To: <1422440682.84.0.195958964107.issue23337@psf.upfronthosting.co.za> Message-ID: <1422887442.56.0.644166106917.issue23337@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Run python with restricted rights -> [IDLE/Windows] Run python with restricted rights _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 15:41:41 2015 From: report at bugs.python.org (Mark Shannon) Date: Mon, 02 Feb 2015 14:41:41 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <1422888101.82.0.130495550361.issue21295@psf.upfronthosting.co.za> Mark Shannon added the comment: This also breaks the col_offset for subscripts like x[y] and, of course any statement with one of these expressions as its leftmost sub-expression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 16:07:46 2015 From: report at bugs.python.org (Tim Golden) Date: Mon, 02 Feb 2015 15:07:46 +0000 Subject: [issue20709] os.utime(path_to_directory): wrong documentation for Windows. In-Reply-To: <1422885210.26.0.462721194618.issue20709@psf.upfronthosting.co.za> Message-ID: <54CF92BF.3000601@timgolden.me.uk> Tim Golden added the comment: Fine by me ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 16:19:03 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 15:19:03 +0000 Subject: [issue20709] os.utime(path_to_directory): wrong documentation for Windows. In-Reply-To: <1392937056.04.0.541478480244.issue20709@psf.upfronthosting.co.za> Message-ID: <1422890343.24.0.779983660626.issue20709@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : ---------- keywords: +patch Added file: http://bugs.python.org/file37979/issue20709_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 16:20:15 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 15:20:15 +0000 Subject: [issue20709] os.utime(path_to_directory): wrong documentation for Windows. In-Reply-To: <1392937056.04.0.541478480244.issue20709@psf.upfronthosting.co.za> Message-ID: <1422890415.42.0.225260830801.issue20709@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : Added file: http://bugs.python.org/file37980/issue20709_tip.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 16:21:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 15:21:25 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <1422890485.44.0.661003326302.issue23374@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are few levels of this issue: 1) pydoc doesn't escape characters according to output encoding. It escapes characters uneencodable with sys.getfilesystemencoding(), but this encoding can differ from the encoding of sys.stdout or default encoding. 2) Default encoding for io.TestIOWrapper() and open() can be different from sys.getfilesystemencoding(). And it unexpectedly can be ASCII. 3) Mac OS doesn't support locales with the utf8 encoding (without hyphen). Here is a patch which solves first level -- makes pydoc using appropriate encoding with the backslashreplace error handler. ---------- keywords: +patch stage: -> patch review type: crash -> behavior versions: -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file37981/pydoc_encoding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 16:25:57 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 15:25:57 +0000 Subject: [issue20709] os.utime(path_to_directory): wrong documentation for Windows. In-Reply-To: <1392937056.04.0.541478480244.issue20709@psf.upfronthosting.co.za> Message-ID: <1422890757.83.0.543148057061.issue20709@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: I have added patches for the documentation, where I removed the sentence in question and re-wrapped the paragraph. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 16:26:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 15:26:03 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1422890763.42.0.872574075998.issue23359@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree, applying simple steps one by one would be more robust. How large the benefit, do you have any timing results? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 16:53:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Feb 2015 15:53:31 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <20150202155302.96098.51429@psf.io> Roundup Robot added the comment: New changeset 7d1c32ddc432 by Benjamin Peterson in branch '3.4': revert lineno and col_offset changes from #16795 (closes #21295) https://hg.python.org/cpython/rev/7d1c32ddc432 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 16:53:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Feb 2015 15:53:31 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <20150202155303.96098.10431@psf.io> Roundup Robot added the comment: New changeset 7d1c32ddc432 by Benjamin Peterson in branch '3.4': revert lineno and col_offset changes from #16795 (closes #21295) https://hg.python.org/cpython/rev/7d1c32ddc432 New changeset 8ab6b404248c by Benjamin Peterson in branch 'default': merge 3.4 (#21295) https://hg.python.org/cpython/rev/8ab6b404248c ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 16:53:56 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 02 Feb 2015 15:53:56 +0000 Subject: [issue16795] Patch: some changes to AST to make it more useful for static language analysis In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za> Message-ID: <1422892436.26.0.812809025251.issue16795@psf.upfronthosting.co.za> Benjamin Peterson added the comment: People pointed out in #21295 that this made some things that were possible before impossible, so the lineno and col_offset changes of this have been reverted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 17:27:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 16:27:58 +0000 Subject: [issue23254] Document how to close the TCPServer listening socket In-Reply-To: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za> Message-ID: <1422894478.22.0.148176022688.issue23254@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 17:35:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Feb 2015 16:35:12 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <20150202163507.106317.4108@psf.io> Roundup Robot added the comment: New changeset 0b3bc51341aa by Raymond Hettinger in branch 'default': Issue 23359: Tighten inner search loop for sets (don't and-mask every entry lookup). https://hg.python.org/cpython/rev/0b3bc51341aa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 17:44:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 16:44:56 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <1422895496.87.0.9515512734.issue23364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, and actually the test is wrong. It fails on 32-bit with -M2G. Should be: - with self.assertRaises(OverflowError): - product(["a"]*(2**16), repeat=2**16) + with self.assertRaises((OverflowError, MemoryError)): + product(*(['ab']*2**5), repeat=2**25) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 17:55:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 16:55:20 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <1422896120.24.0.184146027402.issue23364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And this means that this test (and other tests with the bigaddrspacetest decorator) is not executed on any of our buildbots. It skipped on 64-bit builders and 32-bit builders ran tests without the -M2G option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 18:00:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 17:00:09 +0000 Subject: [issue23366] integer overflow in itertools.combinations In-Reply-To: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> Message-ID: <1422896409.58.0.983570382693.issue23366@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And with this patch an OverflowError in tests should be replaced with (OverflowError, MemoryError). Updated patch also fixes other bugs in itertools tests. ---------- resolution: fixed -> stage: resolved -> patch review Added file: http://bugs.python.org/file37982/itertools_overflows_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 18:02:23 2015 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 02 Feb 2015 17:02:23 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422896543.94.0.670646843407.issue23357@psf.upfronthosting.co.za> Vinay Sajip added the comment: > I would like to help and try to do the change myself You mean the documentation change? Go right ahead! Just make the change to the 3.4 branch, and I will ensure it's merged into the default branch (3.5). Have you completed a contributor form, as a matter of interest? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 18:05:41 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 17:05:41 +0000 Subject: [issue23352] Document "suboffsets if needed" in 2.7 In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422896741.82.0.662424929981.issue23352@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 18:14:31 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 17:14:31 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1422897271.13.0.34363147871.issue22896@psf.upfronthosting.co.za> Stefan Krah added the comment: Nice patch. I've found one issue (see Rietveld). I'm not sure about 3.4 (the patch contains minor refactorings), but otherwise I'd say go ahead with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 18:24:20 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 02 Feb 2015 17:24:20 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1422897860.25.0.576155329779.issue23375@psf.upfronthosting.co.za> Steve Dower added the comment: Looks like a test ordering issue. When test_imageop runs before test_py3kwarn, the warning has presumably already been shown once and so isn't triggered when the test is looking for it (compare build 3092 linked above with 3093, which passed). I haven't looked any further into this, but I don't see how it's Windows specific. Adding the test coverage folks, since nobody seems to obviously own test_py3kwarn. ---------- components: +Tests nosy: +christian.heimes, giampaolo.rodola, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 18:29:19 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 17:29:19 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: Message-ID: <20150202172907.GA32275@bytereef.org> Stefan Krah added the comment: STINNER Victor wrote: > I don't understand the link between third party extensions and > test_getargs2. test_getargs2 is a unit test for non-regression of > CPython. Can you please elaborate? A test failure needs a broken buffer provider that hands out a non-contiguous buffer in response to a PyBUF_SIMPLE request. The only non-contiguous buffer provider in the stdlib is memoryview. If I break memoryview's getbufferproc ... diff --git a/Objects/memoryobject.c b/Objects/memoryobject.c --- a/Objects/memoryobject.c +++ b/Objects/memoryobject.c @@ -1465,11 +1465,6 @@ return -1; } if (!REQ_STRIDES(flags)) { - if (!MV_C_CONTIGUOUS(baseflags)) { - PyErr_SetString(PyExc_BufferError, - "memoryview: underlying buffer is not C-contiguous"); - return -1; - } view->strides = NULL; } if (!REQ_SHAPE(flags)) { ... test_buffer already fails. So what should I test? Perhaps ctypes has some capabilities that I'm unaware of. If I'm using _testbuffer.ndarray(), I'm effectively testing that the getbufferproc of ndarray is correct (which is also tested multiple times in test_buffer). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 18:38:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Feb 2015 17:38:37 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <20150202173755.25855.17098@psf.io> Roundup Robot added the comment: New changeset 2cd6621a9fbc by Victor Stinner in branch '3.4': Issue #23353, asyncio: Workaround CPython bug #23353 https://hg.python.org/cpython/rev/2cd6621a9fbc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 19:06:08 2015 From: report at bugs.python.org (Jonathan Sharpe) Date: Mon, 02 Feb 2015 18:06:08 +0000 Subject: [issue23379] Incorrect links within PEPs Message-ID: <1422900368.04.0.67258841473.issue23379@psf.upfronthosting.co.za> New submission from Jonathan Sharpe: For example, the link to PEP-340 in PEP-343 points to https://www.python.org/dev/peps/pep-0343/pep-0340.html rather than https://www.python.org/dev/peps/pep-0340/ and the link to PEP-288 from PEP-340 points to https://www.python.org/dev/peps/pep-0340/pep-0288.html rather than https://www.python.org/dev/peps/pep-0288/ ---------- assignee: docs at python components: Documentation messages: 235278 nosy: docs at python, jonrsharpe priority: normal severity: normal status: open title: Incorrect links within PEPs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 19:23:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 18:23:20 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1422901400.2.0.965742173276.issue23375@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I can't reproduce the failure on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 19:38:57 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 18:38:57 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422902337.27.0.383460579807.issue6634@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: For Python 2.7, we will not change behavior, even if unexpected. Instead, the sys.exit-docs should be adjusted and - warn about the fact that nothing is written to stderr if sys.exit(msg) gets called from a non-primary thread, and - note that SystemExit raised in a non-primary thread lets the thread exit silently. I have attached a corresponding patch, please review my wording! ---------- keywords: +patch Added file: http://bugs.python.org/file37983/issue6634_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 19:52:28 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 02 Feb 2015 18:52:28 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422903148.82.0.213606283418.issue2292@psf.upfronthosting.co.za> Ethan Furman added the comment: Tried running tests, tests that failed with patch: test_ast test_collections test_extcall test_grammar test_importlib test_parser test_syntax test_unpack_ex test_zipfile Running Ubuntu 13.04 (GNU/Linux 3.8.0-22-generic x86_64). Should I copy/paste the errors, email them, or what? It's going to be a wall of text. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 20:02:45 2015 From: report at bugs.python.org (Buck Golemon) Date: Mon, 02 Feb 2015 19:02:45 +0000 Subject: [issue5945] PyMapping_Check returns 1 for lists In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za> Message-ID: <1422903765.87.0.500170896379.issue5945@psf.upfronthosting.co.za> Buck Golemon added the comment: We've hit this problem today. What are we supposed to do in the meantime? ---------- nosy: +bukzor _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 20:07:16 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 02 Feb 2015 19:07:16 +0000 Subject: [issue5945] PyMapping_Check returns 1 for lists In-Reply-To: <1422903765.87.0.500170896379.issue5945@psf.upfronthosting.co.za> Message-ID: <1422904033.3113150.222111609.532B2E94@webmail.messagingengine.com> Benjamin Peterson added the comment: Not use PyMapping_Check? On Mon, Feb 2, 2015, at 14:02, Buck Golemon wrote: > > Buck Golemon added the comment: > > We've hit this problem today. > > What are we supposed to do in the meantime? > > ---------- > nosy: +bukzor > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 20:18:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Feb 2015 19:18:12 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1422904692.51.0.471288231302.issue23359@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be the code can be simplified without affecting performance if remove slower "else" branch in set_lookkey and set_insert_clean. At least I didn't find a regression in microbenchmarks, but found small benefit. For example: $ ./python -m timeit -s "n = 10**6; s = set(range(n, n+10)); a = list(range(n, n+10))*10**4" -- "s.intersection(a)" Before 0b3bc51341aa: 10 loops, best of 3: 26.6 msec per loop After 0b3bc51341aa: 10 loops, best of 3: 25.4 msec per loop With set_simpler_linear_probes.patch: 10 loops, best of 3: 23.9 msec per loop $ ./python -m timeit -s "n = 10**6; s = set(range(n, n+100)); a = list(range(n, n+100))*10**3" -- "s.intersection(a)" Before 0b3bc51341aa: 10 loops, best of 3: 26.3 msec per loop After 0b3bc51341aa: 10 loops, best of 3: 25.3 msec per loop With set_simpler_linear_probes.patch: 10 loops, best of 3: 23.3 msec per loop $ ./python -m timeit -s "n = 10**6; s = set(range(n, n+10)); a = list(range(n, n+10**5))" -- "s.intersection(a)" Before 0b3bc51341aa: 100 loops, best of 3: 12 msec per loop After 0b3bc51341aa: 100 loops, best of 3: 11.3 msec per loop With set_simpler_linear_probes.patch: 100 loops, best of 3: 11.4 msec per loop ---------- Added file: http://bugs.python.org/file37984/set_simpler_linear_probes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 20:56:36 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 19:56:36 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422906996.77.0.72588953358.issue6634@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : Removed file: http://bugs.python.org/file19006/thread_sys_exit_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 21:39:05 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 02 Feb 2015 20:39:05 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1422909545.44.0.22959487941.issue23285@psf.upfronthosting.co.za> Antoine Pitrou added the comment: PEP is now updated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 21:55:22 2015 From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=) Date: Mon, 02 Feb 2015 20:55:22 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422910522.74.0.994318299547.issue23357@psf.upfronthosting.co.za> Ra?l Cumplido added the comment: >From your question, yes I have completed the form. I've added a new patch just with the documentation change and changing the output from the help command as it was wrong. If it doesn't make sense do let me know. I've done it from 3.4 ---------- Added file: http://bugs.python.org/file37985/23357.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 22:18:50 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 21:18:50 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422911930.89.0.181037740366.issue6634@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: For Python 3.5, I have attached a patch that - adds relevant test cases to test_threading.py which probe the interpreter's stderr output for compliance with what the docs state. - makes sys.exit(msg) write msg to stderr, even if called from a non-primary thread, so that the tests succeed. If we take this path, the documentation for 3.5 does not need to be adjusted. The discussion in this thread diversified itself a bit: > Why don't threads have their own ThreadExit exception, > rather than overloading the use, and therefore, the > meaning, of the SystemExit exception? sys.exit and the > SystemExit exception should *only* be used to exit the > entire system, not just a thread! While I absolutely agree that this would be conceptually cleaner, implementing this would be a larger refactoring task. Deciding whether this should be done or not slows this issue down, and I think this discussion should probably be taken elsewhere. ---------- versions: +Python 3.5 -Python 3.1, Python 3.2 Added file: http://bugs.python.org/file37986/issue6634_py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 22:29:55 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 02 Feb 2015 21:29:55 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422912595.08.0.381085415563.issue6634@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding the documentation patch: I like to start sentences with a capital letter. Perhaps change it to start ?Calling :func:`exit` only terminates . . .?. With the code change patch, it might be neater to use the SystemExit.code attribute rather than e.args[0]. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 22:31:34 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 02 Feb 2015 21:31:34 +0000 Subject: [issue23351] socket.settimeout(5.0) does not have any effect In-Reply-To: <1422581292.34.0.901742947923.issue23351@psf.upfronthosting.co.za> Message-ID: <1422912694.09.0.535676987359.issue23351@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 22:41:45 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 21:41:45 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1422913305.92.0.843460723762.issue23376@psf.upfronthosting.co.za> Stefan Krah added the comment: Well, here's a patch with tests. Victor, I think you added the contiguity test in 9d49b744078c. Do you remember why? ---------- Added file: http://bugs.python.org/file37987/issue23376-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 22:45:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 21:45:00 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1422913499.99.0.150761548103.issue23376@psf.upfronthosting.co.za> STINNER Victor added the comment: > Victor, I think you added the contiguity test in 9d49b744078c. Do you remember why? I don't understand the change like that. The call to PyBuffer_IsContiguous(view, 'C') was older than this changeset. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:03:39 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Feb 2015 22:03:39 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1422914619.04.0.856456183443.issue23376@psf.upfronthosting.co.za> Stefan Krah added the comment: Ah yes, it seems to originate from #3139. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:09:07 2015 From: report at bugs.python.org (Joshua Landau) Date: Mon, 02 Feb 2015 22:09:07 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422914947.07.0.626359011389.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: I don't know the etiquette rules for the issue tracker, but I'd really appreciate having something to debug -- it's working for me, you see. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:19:23 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 22:19:23 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422915563.14.0.823152269508.issue6634@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : Removed file: http://bugs.python.org/file37986/issue6634_py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:19:35 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 22:19:35 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422915575.95.0.863228562347.issue6634@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : Added file: http://bugs.python.org/file37988/issue6634_py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:20:27 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 22:20:27 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422915627.5.0.811233527348.issue6634@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : Removed file: http://bugs.python.org/file37988/issue6634_py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:24:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 02 Feb 2015 22:24:42 +0000 Subject: [issue5945] PyMapping_Check returns 1 for lists In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za> Message-ID: <1422915882.84.0.157537209537.issue5945@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:27:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Feb 2015 22:27:51 +0000 Subject: [issue23380] Python 2.7.9 test_gdb fails on Fedora 21 In-Reply-To: <1422915287.22.0.702973088229.issue23380@psf.upfronthosting.co.za> Message-ID: <1422916071.36.0.617499713956.issue23380@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm using Fedora 21 with gdb 7.8.2-38.fc21 on x86_64. With the development 2.7 branch, test_gdb pass here. How did you get Python 2.7.9? What is your gdb version? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:31:39 2015 From: report at bugs.python.org (Vinson Lee) Date: Mon, 02 Feb 2015 22:31:39 +0000 Subject: [issue23380] Python 2.7.9 test_gdb fails on Fedora 21 In-Reply-To: <1422915287.22.0.702973088229.issue23380@psf.upfronthosting.co.za> Message-ID: <1422916299.68.0.55112014039.issue23380@psf.upfronthosting.co.za> Vinson Lee added the comment: I downloaded Python 2.7.9 release tarball from https://www.python.org/downloads/release/python-279. $ gdb --version GNU gdb (GDB) Fedora 7.8.2-38.fc21 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:33:42 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 22:33:42 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422916422.22.0.0801048434624.issue6634@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: > Regarding the documentation patch: I like to start sentences > with a capital letter. Perhaps change it to start > ?Calling :func:`exit` only terminates . . .?. Thanks for feedback. Have now used "Invocation of ...." to not repeat "call*" in the sentence, because I left the "when called from the main thread" part unchanged. Okay? > With the code change patch, it might be neater to use > the SystemExit.code attribute rather than e.args[0]. Oh, thanks. Was not aware of the existence of the `code` attribute. If anyone else was wondering: existence and behavior are defined in Objects/exceptions.c via `static PyMemberDef SystemExit_members[]` and via `static int SystemExit_init()`. It is populated upon construction of a SystemExit instance: Py_CLEAR(self->code); if (size == 1) self->code = PyTuple_GET_ITEM(args, 0); else /* size > 1 */ self->code = args; Hence, the translation from arguments to exit code considers *all* arguments. I adjusted the patch to use the `code` attribute. ---------- Added file: http://bugs.python.org/file37989/issue6634_py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:33:59 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 22:33:59 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422916439.47.0.0336708144852.issue6634@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : Removed file: http://bugs.python.org/file37983/issue6634_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:34:13 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 02 Feb 2015 22:34:13 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422916452.99.0.531162082135.issue6634@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : Added file: http://bugs.python.org/file37990/issue6634_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:37:02 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 02 Feb 2015 22:37:02 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422916622.45.0.862590950623.issue2292@psf.upfronthosting.co.za> Ethan Furman added the comment: Argh -- I applied the patch, but didn't recompile. Doing that now... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:47:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Feb 2015 22:47:38 +0000 Subject: [issue23369] integer overflow in _json.encode_basestring_ascii In-Reply-To: <1422799175.9.0.580347379364.issue23369@psf.upfronthosting.co.za> Message-ID: <20150202224736.96074.87249@psf.io> Roundup Robot added the comment: New changeset 5c730d30ffbc by Benjamin Peterson in branch '3.3': reduce memory usage of test (closes #23369) https://hg.python.org/cpython/rev/5c730d30ffbc ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:54:29 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 02 Feb 2015 22:54:29 +0000 Subject: [issue23366] integer overflow in itertools.combinations In-Reply-To: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> Message-ID: <1422917669.93.0.600601996966.issue23366@psf.upfronthosting.co.za> Benjamin Peterson added the comment: lgtm ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 00:19:13 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 02 Feb 2015 23:19:13 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422919153.57.0.791574261029.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Third version of the patch (subprocess_run3): - Simplifies the documentation of the trio (call, check_call, check_output) to describe them in terms of the equivalent run() call. - Remove a warning about using PIPE with check_output - I believe this was already incorrect, since check_output uses .communicate() internally, it shouldn't have deadlock issues. - Replace the implementation of check_output() with a call to run(). I didn't reimplement call or check_call - as previously discussed, they are more different from the code in run(), so subtly breaking things is more possible. They are also simpler. ---------- Added file: http://bugs.python.org/file37991/subprocess_run3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 00:40:35 2015 From: report at bugs.python.org (Armin Rigo) Date: Mon, 02 Feb 2015 23:40:35 +0000 Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop() In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za> Message-ID: <1422920435.68.0.437315765769.issue19542@psf.upfronthosting.co.za> Changes by Armin Rigo : ---------- keywords: +patch Added file: http://bugs.python.org/file37992/fix-weakvaluedict.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 00:40:50 2015 From: report at bugs.python.org (Armin Rigo) Date: Mon, 02 Feb 2015 23:40:50 +0000 Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop() In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za> Message-ID: <1422920450.27.0.453204863289.issue19542@psf.upfronthosting.co.za> Changes by Armin Rigo : Added file: http://bugs.python.org/file37993/fix-weakvaluedict-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 00:42:34 2015 From: report at bugs.python.org (Armin Rigo) Date: Mon, 02 Feb 2015 23:42:34 +0000 Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop() In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za> Message-ID: <1422920554.76.0.148886340827.issue19542@psf.upfronthosting.co.za> Armin Rigo added the comment: Converted the test into an official test, which fails; and wrote the patch for CPython "3.trunk" and for CPython 2.7. Please review and commit. ---------- keywords: +needs review -patch stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:02:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 03 Feb 2015 00:02:47 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422921766.99.0.14584107406.issue2292@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Upload a .txt file if there is really too much for a message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:03:13 2015 From: report at bugs.python.org (Vinson Lee) Date: Tue, 03 Feb 2015 00:03:13 +0000 Subject: [issue23380] Python 2.7.9 test_gdb fails on Fedora 21 In-Reply-To: <1422915287.22.0.702973088229.issue23380@psf.upfronthosting.co.za> Message-ID: <1422921793.63.0.999354097743.issue23380@psf.upfronthosting.co.za> Vinson Lee added the comment: Python 2.7.9+ test_gdb passes on Fedora 21 with the latest 2.7 branch. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:05:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 00:05:21 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <20150203000513.34384.31854@psf.io> Roundup Robot added the comment: New changeset e62d54128bd3 by Serhiy Storchaka in branch '3.4': Issue #23099: Closing io.BytesIO with exported buffer is rejected now to https://hg.python.org/cpython/rev/e62d54128bd3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:05:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 00:05:21 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <20150203000514.34384.74106@psf.io> Roundup Robot added the comment: New changeset 1da9630e9b7f by Serhiy Storchaka in branch '3.4': Issue #22896: Avoid to use PyObject_AsCharBuffer(), PyObject_AsReadBuffer() https://hg.python.org/cpython/rev/1da9630e9b7f New changeset 2e684ce772de by Serhiy Storchaka in branch 'default': Issue #22896: Avoid to use PyObject_AsCharBuffer(), PyObject_AsReadBuffer() https://hg.python.org/cpython/rev/2e684ce772de New changeset 0024537a4687 by Serhiy Storchaka in branch 'default': Issue #22896: Fixed using _getbuffer() in recently added _PyBytes_Format(). https://hg.python.org/cpython/rev/0024537a4687 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:05:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 00:05:22 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <20150203000514.34384.77608@psf.io> Roundup Robot added the comment: New changeset 356ed025dbae by Serhiy Storchaka in branch '3.3': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/356ed025dbae New changeset 98c720c3e061 by Serhiy Storchaka in branch '3.4': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/98c720c3e061 New changeset 4cb316fe6bf2 by Serhiy Storchaka in branch 'default': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/4cb316fe6bf2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:05:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 00:05:22 +0000 Subject: [issue23365] integer overflow in itertools.combinations_with_replacement In-Reply-To: <1422798943.75.0.0941782409051.issue23365@psf.upfronthosting.co.za> Message-ID: <20150203000514.34384.42072@psf.io> Roundup Robot added the comment: New changeset 356ed025dbae by Serhiy Storchaka in branch '3.3': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/356ed025dbae New changeset 98c720c3e061 by Serhiy Storchaka in branch '3.4': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/98c720c3e061 New changeset 4cb316fe6bf2 by Serhiy Storchaka in branch 'default': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/4cb316fe6bf2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:05:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 00:05:22 +0000 Subject: [issue23366] integer overflow in itertools.combinations In-Reply-To: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> Message-ID: <20150203000513.34384.64636@psf.io> Roundup Robot added the comment: New changeset 356ed025dbae by Serhiy Storchaka in branch '3.3': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/356ed025dbae New changeset 98c720c3e061 by Serhiy Storchaka in branch '3.4': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/98c720c3e061 New changeset 4cb316fe6bf2 by Serhiy Storchaka in branch 'default': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/4cb316fe6bf2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:05:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 00:05:22 +0000 Subject: [issue23363] integer overflow in itertools.permutations In-Reply-To: <1422798853.28.0.166749700091.issue23363@psf.upfronthosting.co.za> Message-ID: <20150203000513.34384.88553@psf.io> Roundup Robot added the comment: New changeset 356ed025dbae by Serhiy Storchaka in branch '3.3': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/356ed025dbae New changeset 98c720c3e061 by Serhiy Storchaka in branch '3.4': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/98c720c3e061 New changeset 4cb316fe6bf2 by Serhiy Storchaka in branch 'default': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/4cb316fe6bf2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:08:46 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 03 Feb 2015 00:08:46 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1422921766.99.0.14584107406.issue2292@psf.upfronthosting.co.za> Message-ID: <54D0116A.6090206@stoneleaf.us> Ethan Furman added the comment: Thanks, Terry! I'll do that next time -- after I make sure and re-compile. :/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:14:54 2015 From: report at bugs.python.org (Vinson Lee) Date: Tue, 03 Feb 2015 00:14:54 +0000 Subject: [issue23381] Python 2.7.9+ test_gdb regression on Ubuntu 10.04 Message-ID: <1422922493.9.0.93892499408.issue23381@psf.upfronthosting.co.za> New submission from Vinson Lee: Python 2.7.9+ test_gdb regressed on Ubuntu 10.04. 063d966b78f0c0b7cf4c937991bf883c563f574e is the first bad commit commit 063d966b78f0c0b7cf4c937991bf883c563f574e Author: Serhiy Storchaka Date: Sat Jan 31 11:48:36 2015 +0200 Issue #22765: Fixed test_gdb failures. Supressed unexpected gdb output. Patch by Bohuslav Kabrda. :040000 040000 dd420a96366b568ad8ae5e7c88759d743b29584c 0eb56f3c2d8d731985ae93258170e00571ae9a35 M Lib bisect run success $ gdb --version GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: . $ ./python Lib/test/regrtest.py -v test_gdb == CPython 2.7.9+ (default, Feb 2 2015, 15:48:27) [GCC 4.4.3] == Linux-2.6.32-71-generic-x86_64-with-debian-squeeze-sid little-endian == cpython/build/test_python_29238 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) [1/1] test_gdb test_NULL_instance_dict (test.test_gdb.PrettyPrintTests) Ensure that a PyInstanceObject with with a NULL in_dict is handled ... FAIL test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully ... FAIL test_NULL_ptr (test.test_gdb.PrettyPrintTests) Ensure that a NULL PyObject* is handled gracefully ... FAIL test_builtin_function (test.test_gdb.PrettyPrintTests) ... FAIL test_builtin_method (test.test_gdb.PrettyPrintTests) ... FAIL test_builtins_help (test.test_gdb.PrettyPrintTests) Ensure that the new-style class _Helper in site.py can be handled ... FAIL test_classic_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of classic class instances ... FAIL test_corrupt_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a corrupt ob_type is handled gracefully ... FAIL test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_flags is handled ... FAIL test_corrupt_tp_name (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_name is handled ... FAIL test_dicts (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of dictionaries ... FAIL test_exceptions (test.test_gdb.PrettyPrintTests) ... FAIL test_frames (test.test_gdb.PrettyPrintTests) ... FAIL test_frozensets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of frozensets ... FAIL test_getting_backtrace (test.test_gdb.PrettyPrintTests) ... FAIL test_int (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "int" values ... FAIL test_lists (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of lists ... FAIL test_long (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "long" values ... FAIL test_modern_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of new-style class instances ... FAIL test_selfreferential_dict (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a dict doesn't lead proxyval ... FAIL test_selfreferential_list (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a list doesn't lead proxyval ... FAIL test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL test_sets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of sets ... FAIL test_singletons (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of True, False and None ... FAIL test_strings (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of strings ... FAIL test_subclassing_list (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a list subclass ... FAIL test_subclassing_tuple (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a tuple subclass ... FAIL test_truncation (test.test_gdb.PrettyPrintTests) Verify that very long output is truncated ... FAIL test_tuples (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of tuples ... FAIL test_unicode (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of unicode values ... FAIL test_basic_command (test.test_gdb.PyListTests) Verify that the "py-list" command works ... skipped 'Python was compiled with optimizations' test_one_abs_arg (test.test_gdb.PyListTests) Verify the "py-list" command with one absolute argument ... skipped 'Python was compiled with optimizations' test_two_abs_args (test.test_gdb.PyListTests) Verify the "py-list" command with two absolute arguments ... skipped 'Python was compiled with optimizations' test_down_at_bottom (test.test_gdb.StackNavigationTests) Verify handling of "py-down" at the bottom of the stack ... skipped 'test requires py-up/py-down commands' test_pyup_command (test.test_gdb.StackNavigationTests) Verify that the "py-up" command works ... skipped 'test requires py-up/py-down commands' test_up_at_top (test.test_gdb.StackNavigationTests) Verify handling of "py-up" at the top of the stack ... skipped 'test requires py-up/py-down commands' test_up_then_down (test.test_gdb.StackNavigationTests) Verify "py-up" followed by "py-down" ... skipped 'test requires py-up/py-down commands' test_basic_command (test.test_gdb.PyBtTests) Verify that the "py-bt" command works ... skipped 'Python was compiled with optimizations' test_basic_command (test.test_gdb.PyPrintTests) Verify that the "py-print" command works ... skipped 'Python was compiled with optimizations' test_print_after_up (test.test_gdb.PyPrintTests) ... skipped 'test requires py-up/py-down commands' test_printing_builtin (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations' test_printing_global (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations' test_basic_command (test.test_gdb.PyLocalsTests) ... skipped 'Python was compiled with optimizations' test_locals_after_up (test.test_gdb.PyLocalsTests) ... skipped 'test requires py-up/py-down commands' ====================================================================== FAIL: test_NULL_instance_dict (test.test_gdb.PrettyPrintTests) Ensure that a PyInstanceObject with with a NULL in_dict is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 495, in test_NULL_instance_dict exptype='Foo') File "cpython/Lib/test/test_gdb.py", line 433, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 466, in test_NULL_ob_type 'set op->ob_type=0') File "cpython/Lib/test/test_gdb.py", line 433, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_NULL_ptr (test.test_gdb.PrettyPrintTests) Ensure that a NULL PyObject* is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 458, in test_NULL_ptr 'backtrace']) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_builtin_function (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 597, in test_builtin_function gdb_repr, gdb_output = self.get_gdb_repr('print len') File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_builtin_method (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 601, in test_builtin_method gdb_repr, gdb_output = self.get_gdb_repr('import sys; print sys.stdout.readlines') File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_builtins_help (test.test_gdb.PrettyPrintTests) Ensure that the new-style class _Helper in site.py can be handled ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 502, in test_builtins_help gdb_repr, gdb_output = self.get_gdb_repr('print __builtins__.help', import_site=True) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_classic_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of classic class instances ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 376, in test_classic_class print foo''') File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_corrupt_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a corrupt ob_type is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 472, in test_corrupt_ob_type expvalue=42) File "cpython/Lib/test/test_gdb.py", line 433, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_flags is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 478, in test_corrupt_tp_flags expvalue=42) File "cpython/Lib/test/test_gdb.py", line 433, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_name is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 484, in test_corrupt_tp_name expvalue=42) File "cpython/Lib/test/test_gdb.py", line 433, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_dicts (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of dictionaries ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 270, in test_dicts self.assertGdbRepr({}) File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_exceptions (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 354, in test_exceptions ''') File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_frames (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 615, in test_frames cmds_after_breakpoint=['print (PyFrameObject*)(((PyCodeObject*)op)->co_zombieframe)'] File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_frozensets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of frozensets ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 337, in test_frozensets self.assertGdbRepr(frozenset()) File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_getting_backtrace (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 237, in test_getting_backtrace gdb_output = self.get_stack_trace('print 42') File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_int (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "int" values ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 249, in test_int self.assertGdbRepr(42) File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_lists (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of lists ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 276, in test_lists self.assertGdbRepr([]) File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_long (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "long" values ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 257, in test_long self.assertGdbRepr(0L) File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_modern_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of new-style class instances ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 388, in test_modern_class print foo''') File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_selfreferential_dict (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a dict doesn't lead proxyval ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 524, in test_selfreferential_dict self.get_gdb_repr("a = {} ; b = {'bar':a} ; a['foo'] = b ; print a") File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_selfreferential_list (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a list doesn't lead proxyval ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 511, in test_selfreferential_list self.get_gdb_repr("a = [3, 4, 5] ; a.append(a) ; print a") File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 548, in test_selfreferential_new_style_instance print foo''') File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 535, in test_selfreferential_old_style_instance print foo''') File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_sets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of sets ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 318, in test_sets self.assertGdbRepr(set()) File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_singletons (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of True, False and None ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 264, in test_singletons self.assertGdbRepr(True) File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_strings (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of strings ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 281, in test_strings self.assertGdbRepr('') File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_subclassing_list (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a list subclass ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 401, in test_subclassing_list print foo''') File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_subclassing_tuple (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a tuple subclass ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 415, in test_subclassing_tuple print foo''') File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_truncation (test.test_gdb.PrettyPrintTests) Verify that very long output is truncated ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 570, in test_truncation gdb_repr, gdb_output = self.get_gdb_repr('print range(1000)') File "cpython/Lib/test/test_gdb.py", linetest test_gdb failed -- multiple errors occurred 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_tuples (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of tuples ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 288, in test_tuples self.assertGdbRepr(tuple()) File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ====================================================================== FAIL: test_unicode (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of unicode values ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython/Lib/test/test_gdb.py", line 295, in test_unicode self.assertGdbRepr(u'') File "cpython/Lib/test/test_gdb.py", line 244, in assertGdbRepr cmds_after_breakpoint) File "cpython/Lib/test/test_gdb.py", line 213, in get_gdb_repr import_site=import_site) File "cpython/Lib/test/test_gdb.py", line 198, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Undefined set print command:... != [] First list contains 1 additional elements. First extra element 0: Undefined set print command: "entry-values no". Try "help set print". - ['Undefined set print command: "entry-values no". Try "help set print".'] + [] ---------------------------------------------------------------------- Ran 45 tests in 3.121s FAILED (failures=31, skipped=14) 1 test failed: test_gdb ---------- components: Tests messages: 235311 nosy: serhiy.storchaka, vlee priority: normal severity: normal status: open title: Python 2.7.9+ test_gdb regression on Ubuntu 10.04 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 01:49:49 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Feb 2015 00:49:49 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422924589.82.0.325614407992.issue6634@psf.upfronthosting.co.za> Martin Panter added the comment: New patches look fine. BTW SystemExit.code is also documented at . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 04:16:31 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 03 Feb 2015 03:16:31 +0000 Subject: [issue23336] Thread.LockType is misnamed In-Reply-To: <1422424947.14.0.409463431872.issue23336@psf.upfronthosting.co.za> Message-ID: <1422933391.44.0.404692782174.issue23336@psf.upfronthosting.co.za> Josh Rosenberg added the comment: The thread and dummy_thread modules have a leading underscore in Py3.4, but the same naming issue is present there as well. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 07:32:18 2015 From: report at bugs.python.org (Daniil Bondarev) Date: Tue, 03 Feb 2015 06:32:18 +0000 Subject: [issue2786] Names in traceback should have class names, if they're methods In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za> Message-ID: <1422945138.51.0.961330678624.issue2786@psf.upfronthosting.co.za> Daniil Bondarev added the comment: Made a straightforward patch for this. Probably not that pretty, so suggestions are welcome. Note that some function names will become pretty long in exceptions: >>> class A: ... def __init__(self): ... def f(): ... pass ... f(1,2,3) ... >>> A() Traceback (most recent call last): File "", line 1, in File "", line 5, in __init__ TypeError: A.__init__..f() takes 0 positional arguments but 3 were given Passing UTs from lastest snapshot. ---------- keywords: +patch nosy: +xonatius Added file: http://bugs.python.org/file37994/full_names.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 07:34:40 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 03 Feb 2015 06:34:40 +0000 Subject: [issue2786] Names in traceback should have class names, if they're methods In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za> Message-ID: <1422945280.84.0.891500653665.issue2786@psf.upfronthosting.co.za> Robert Collins added the comment: I wonder if you could add this to the new code in http://bugs.python.org/issue17911 which I'm hoping to commit this week. ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 08:17:43 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Feb 2015 07:17:43 +0000 Subject: [issue13322] buffered read() and write() does not raise BlockingIOError In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za> Message-ID: <1422947863.46.0.636744684309.issue13322@psf.upfronthosting.co.za> Martin Panter added the comment: I?m adding nonblock-none.patch, which changes all the simple buffered read methods to return None when there is no non-blocking data available. I?d be interested to see if other people thought this was a sensible change. * Documented existing behaviour of C ?io? module buffered read(), readinto/1() returning None * io.BufferedIOBase.read() and io.FileIO.readall() doc strings already mention returning None * Removed false claims of buffered reads returning short for interactive streams, sockets and pipes * Fixed _pyio return values to match C ?io? module returning None * Fixed BufferedIOBase.readinto/1() implementation to handle read/1() returning None * Changed buffered read1() and peek() to return None ---------- Added file: http://bugs.python.org/file37995/nonblock-none.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 08:31:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 07:31:49 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <20150203073130.39268.48038@psf.io> Roundup Robot added the comment: New changeset b9d4c013b09a by Serhiy Storchaka in branch 'default': Issue #23099: Closing io.BytesIO with exported buffer is rejected now to https://hg.python.org/cpython/rev/b9d4c013b09a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 08:39:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 07:39:05 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1422949145.36.0.96233421323.issue22896@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Antoine and Stefan for your reviews. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 08:40:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 07:40:55 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1422949255.93.0.303724108962.issue23099@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 08:41:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 07:41:24 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <1422949284.02.0.130423365494.issue23364@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 08:41:37 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 03 Feb 2015 07:41:37 +0000 Subject: [issue2786] Names in traceback should have class names, if they're methods In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za> Message-ID: <1422949297.0.0.0926433820731.issue2786@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 08:41:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 07:41:41 +0000 Subject: [issue23365] integer overflow in itertools.combinations_with_replacement In-Reply-To: <1422798943.75.0.0941782409051.issue23365@psf.upfronthosting.co.za> Message-ID: <1422949301.16.0.740737252187.issue23365@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 08:42:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 07:42:09 +0000 Subject: [issue23366] integer overflow in itertools.combinations In-Reply-To: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> Message-ID: <1422949329.05.0.486361794.issue23366@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 08:42:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 07:42:28 +0000 Subject: [issue23363] integer overflow in itertools.permutations In-Reply-To: <1422798853.28.0.166749700091.issue23363@psf.upfronthosting.co.za> Message-ID: <1422949348.54.0.415161099673.issue23363@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 09:20:03 2015 From: report at bugs.python.org (miles) Date: Tue, 03 Feb 2015 08:20:03 +0000 Subject: [issue23382] Maybe can not shutdown ThreadPoolExecutor when call the method of shutdown Message-ID: <1422951603.17.0.63584283635.issue23382@psf.upfronthosting.co.za> New submission from miles: Maybe can not shutdown ThreadPoolExecutor when call the method shutdown. Though the variable of _shutdown is set to true in the method of shutdown, it may also reads the variable of _shutdown from cpu cache in the method of _worker, and the worst case is that it could see an out-of-date value of _shutdown forever. so need to acquire lock before reading the variable of _shutdown to make sure see an up-to-date value. the following is the new code: def _worker(executor_reference, work_queue): try: while True: work_item = work_queue.get(block=True) if work_item is not None: work_item.run() continue executor = executor_reference() shutdown = False with executor._shutdown_lock.acquire(): shutdown = executor._shutdown # Exit if: # - The interpreter is shutting down OR # - The executor that owns the worker has been collected OR # - The executor that owns the worker has been shutdown. if _shutdown or executor is None or shutdown: # Notice other workers work_queue.put(None) return del executor except BaseException: _base.LOGGER.critical('Exception in worker', exc_info=True) def shutdown(self, wait=True): with self._shutdown_lock: self._shutdown = True self._work_queue.put(None) if wait: for t in self._threads: t.join() ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 235319 nosy: miles priority: normal severity: normal status: open title: Maybe can not shutdown ThreadPoolExecutor when call the method of shutdown versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 09:42:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 08:42:53 +0000 Subject: [issue23383] Clean up bytes formatting Message-ID: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes following changes to bytes formatting code: 1) Fixes a bug when PyUnicode_AsEncodedObject() returns non-bytes byte-like object. 2) Avoid few non-neccessary memory allocations and copyings (converting bytearray or ASCII string to bytes). 3) Clean up the code. ---------- components: Interpreter Core files: bytes_format.patch keywords: patch messages: 235320 nosy: Arfrever, eric.smith, ethan.furman, haypo, nascheme, ncoghlan, python-dev, serhiy.storchaka, vadmium priority: normal severity: normal stage: patch review status: open title: Clean up bytes formatting type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37996/bytes_format.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:05:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 09:05:34 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <20150203090509.39292.32095@psf.io> Roundup Robot added the comment: New changeset 7c667d8ae10d by Serhiy Storchaka in branch 'default': Issue #22818: Splitting on a pattern that could match an empty string now https://hg.python.org/cpython/rev/7c667d8ae10d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:05:39 2015 From: report at bugs.python.org (Valeriy Osipov) Date: Tue, 03 Feb 2015 09:05:39 +0000 Subject: [issue23384] urllib.proxy_bypass_registry slow down under Windows if website has no reverse DNS and Fiddler is runing Message-ID: <1422954339.65.0.892974237114.issue23384@psf.upfronthosting.co.za> New submission from Valeriy Osipov: Environment: OS Windows 8, Fiddler is running To reproduce the issue launch this code snippet: import requests import datetime import urllib print datetime.datetime.now() #print requests.get('http://torgi.gov.ru/lotSearchArchive.html?bidKindId=2') #print urllib.proxy_bypass_registry('torgi.gov.ru') print datetime.datetime.now() This on? GET requests to this wesite takes 6-7 seconds. Now comment the following code from the urllib.py from the proxy_bypass_registry function: try: fqdn = socket.getfqdn(rawHost) if fqdn != rawHost: host.append(fqdn) except socket.error: pass Now the same GET request takes 2 second. It is normal because this website takes 2 seconds for response. ---------- components: Windows messages: 235322 nosy: aristotel, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: urllib.proxy_bypass_registry slow down under Windows if website has no reverse DNS and Fiddler is runing versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:12:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 09:12:16 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1422954736.0.0.416582636461.issue22818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Ezio and Berker for your reviews. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:15:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 03 Feb 2015 09:15:16 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422954916.09.0.460247636838.issue6634@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure what the doc patch achieves. It only states more verbosely what is already said in the current version. Also, warnings are really for important issues (such as security issues); using them too liberally is a disservice to the reader. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:30:37 2015 From: report at bugs.python.org (miles) Date: Tue, 03 Feb 2015 09:30:37 +0000 Subject: [issue23382] Maybe can not shutdown ThreadPoolExecutor when call the method of shutdown In-Reply-To: <1422951603.17.0.63584283635.issue23382@psf.upfronthosting.co.za> Message-ID: <1422955837.42.0.862412644368.issue23382@psf.upfronthosting.co.za> miles added the comment: The attachment includes the new code ---------- Added file: http://bugs.python.org/file37997/thread.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:31:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 09:31:05 +0000 Subject: [issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <20150203093057.96084.13636@psf.io> Roundup Robot added the comment: New changeset 2e29d54843a4 by Serhiy Storchaka in branch 'default': Issue #15381: Optimized io.BytesIO to make less allocations and copyings. https://hg.python.org/cpython/rev/2e29d54843a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:49:55 2015 From: report at bugs.python.org (nivin) Date: Tue, 03 Feb 2015 09:49:55 +0000 Subject: [issue23385] snmp - mib error Message-ID: <1422956995.0.0.309413347292.issue23385@psf.upfronthosting.co.za> New submission from nivin: Hi , I have created one snmp mib , and tried to send a sample trap using a script written in python using pysnmp. but i got error as follows ,'pysnmp.smi.error.SmiError: MIB file "mymib.py[co]" not found in search path'. Can any one help me please? I'm attaching the script i used and mib file. Thank you ---------- components: Build files: snmp_script.txt messages: 235327 nosy: nivin priority: normal severity: normal status: open title: snmp - mib error type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file37998/snmp_script.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:50:23 2015 From: report at bugs.python.org (nivin) Date: Tue, 03 Feb 2015 09:50:23 +0000 Subject: [issue23386] snmp - mib error Message-ID: <1422957022.99.0.675855776064.issue23386@psf.upfronthosting.co.za> New submission from nivin: Hi , I have created one snmp mib , and tried to send a sample trap using a script written in python using pysnmp. but i got error as follows ,'pysnmp.smi.error.SmiError: MIB file "mymib.py[co]" not found in search path'. Can any one help me please? I'm attaching the script i used and mib file. Thank you ---------- components: Build files: snmp_script.txt messages: 235328 nosy: nivin priority: normal severity: normal status: open title: snmp - mib error type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file37999/snmp_script.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:55:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 09:55:29 +0000 Subject: [issue23358] BaseServer missing from socketserver.__all__ In-Reply-To: <1422704522.18.0.713790375362.issue23358@psf.upfronthosting.co.za> Message-ID: <20150203095524.39268.71041@psf.io> Roundup Robot added the comment: New changeset e614ff664877 by Berker Peksag in branch '3.4': Issue #23358: Add missing BaseServer entry to socketserver.__all__. https://hg.python.org/cpython/rev/e614ff664877 New changeset 80d282505d21 by Berker Peksag in branch 'default': Issue #23358: Add missing BaseServer entry to socketserver.__all__. https://hg.python.org/cpython/rev/80d282505d21 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:56:33 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 03 Feb 2015 09:56:33 +0000 Subject: [issue23358] BaseServer missing from socketserver.__all__ In-Reply-To: <1422704522.18.0.713790375362.issue23358@psf.upfronthosting.co.za> Message-ID: <1422957393.42.0.615963237952.issue23358@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Martin. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:58:18 2015 From: report at bugs.python.org (Shinto Peter) Date: Tue, 03 Feb 2015 09:58:18 +0000 Subject: [issue23386] snmp - mib error In-Reply-To: <1422957022.99.0.675855776064.issue23386@psf.upfronthosting.co.za> Message-ID: <1422957498.21.0.968091802784.issue23386@psf.upfronthosting.co.za> Shinto Peter added the comment: please attach MIB file also ---------- nosy: +shinto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:59:14 2015 From: report at bugs.python.org (nivin) Date: Tue, 03 Feb 2015 09:59:14 +0000 Subject: [issue23386] snmp - mib error In-Reply-To: <1422957022.99.0.675855776064.issue23386@psf.upfronthosting.co.za> Message-ID: <1422957554.92.0.950970738488.issue23386@psf.upfronthosting.co.za> Changes by nivin : Added file: http://bugs.python.org/file38000/MY-MIB.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 10:59:26 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 03 Feb 2015 09:59:26 +0000 Subject: [issue23385] snmp - mib error In-Reply-To: <1422956995.0.0.309413347292.issue23385@psf.upfronthosting.co.za> Message-ID: <1422957566.31.0.360752333894.issue23385@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> snmp - mib error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 11:00:10 2015 From: report at bugs.python.org (nivin) Date: Tue, 03 Feb 2015 10:00:10 +0000 Subject: [issue23386] snmp - mib error In-Reply-To: <1422957022.99.0.675855776064.issue23386@psf.upfronthosting.co.za> Message-ID: <1422957610.85.0.182497611134.issue23386@psf.upfronthosting.co.za> nivin added the comment: I have attached mib file also ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 2 23:14:47 2015 From: report at bugs.python.org (Vinson Lee) Date: Mon, 02 Feb 2015 22:14:47 +0000 Subject: [issue23380] Python 2.7.9 test_gdb fails on Fedora 21 Message-ID: <1422915287.22.0.702973088229.issue23380@psf.upfronthosting.co.za> New submission from Vinson Lee: Python 2.7.9 test_gdb fails on Fedora 21. $ ./python Lib/test/regrtest.py -v test_gdb == CPython 2.7.9 (default, Feb 2 2015, 13:43:56) [GCC 4.9.2 20141101 (Red Hat 4.9.2-1)] == Linux-3.18.3-201.fc21.x86_64-x86_64-with-fedora-21-Twenty_One little-endian == Python-2.7.9/build/test_python_18852 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) [1/1] test_gdb test_NULL_instance_dict (test.test_gdb.PrettyPrintTests) Ensure that a PyInstanceObject with with a NULL in_dict is handled ... FAIL test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully ... FAIL test_NULL_ptr (test.test_gdb.PrettyPrintTests) Ensure that a NULL PyObject* is handled gracefully ... FAIL test_builtin_function (test.test_gdb.PrettyPrintTests) ... FAIL test_builtin_method (test.test_gdb.PrettyPrintTests) ... FAIL test_builtins_help (test.test_gdb.PrettyPrintTests) Ensure that the new-style class _Helper in site.py can be handled ... FAIL test_classic_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of classic class instances ... FAIL test_corrupt_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a corrupt ob_type is handled gracefully ... FAIL test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_flags is handled ... FAIL test_corrupt_tp_name (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_name is handled ... FAIL test_dicts (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of dictionaries ... FAIL test_exceptions (test.test_gdb.PrettyPrintTests) ... FAIL test_frames (test.test_gdb.PrettyPrintTests) ... ok test_frozensets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of frozensets ... FAIL test_getting_backtrace (test.test_gdb.PrettyPrintTests) ... ok test_int (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "int" values ... FAIL test_lists (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of lists ... FAIL test_long (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "long" values ... FAIL test_modern_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of new-style class instances ... FAIL test_selfreferential_dict (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a dict doesn't lead proxyval ... FAIL test_selfreferential_list (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a list doesn't lead proxyval ... FAIL test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL test_sets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of sets ... FAIL test_singletons (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of True, False and None ... FAIL test_strings (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of strings ... FAIL test_subclassing_list (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a list subclass ... FAIL test_subclassing_tuple (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a tuple subclass ... FAIL test_truncation (test.test_gdb.PrettyPrintTests) Verify that very long output is truncated ... FAIL test_tuples (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of tuples ... FAIL test_unicode (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of unicode values ... FAIL test_basic_command (test.test_gdb.PyListTests) Verify that the "py-list" command works ... skipped 'Python was compiled with optimizations' test_one_abs_arg (test.test_gdb.PyListTests) Verify the "py-list" command with one absolute argument ... skipped 'Python was compiled with optimizations' test_two_abs_args (test.test_gdb.PyListTests) Verify the "py-list" command with two absolute arguments ... skipped 'Python was compiled with optimizations' test_down_at_bottom (test.test_gdb.StackNavigationTests) Verify handling of "py-down" at the bottom of the stack ... ok test_pyup_command (test.test_gdb.StackNavigationTests) Verify that the "py-up" command works ... skipped 'Python was compiled with optimizations' test_up_at_top (test.test_gdb.StackNavigationTests) Verify handling of "py-up" at the top of the stack ... ok test_up_then_down (test.test_gdb.StackNavigationTests) Verify "py-up" followed by "py-down" ... skipped 'Python was compiled with optimizations' test_basic_command (test.test_gdb.PyBtTests) Verify that the "py-bt" command works ... skipped 'Python was compiled with optimizations' test_basic_command (test.test_gdb.PyPrintTests) Verify that the "py-print" command works ... skipped 'Python was compiled with optimizations' test_print_after_up (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations' test_printing_builtin (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations' test_printing_global (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations' test_basic_command (test.test_gdb.PyLocalsTests) ... skipped 'Python was compiled with optimizations' test_locals_after_up (test.test_gdb.PyLocalsTests) ... skipped 'Python was compiled with optimizations' ====================================================================== FAIL: test_NULL_instance_dict (test.test_gdb.PrettyPrintTests) Ensure that a PyInstanceObject with with a NULL in_dict is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 476, in test_NULL_instance_dict exptype='Foo') File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45e3a0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a13b in file_PyObject_Print (f=0x7ffff7fb7150, f=0x7ffff7fb7150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b4bc5 in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f17050, for file , line 6, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b800b in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fa8bb0, globals=globals at entry={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #5 0x00000000004b8119 in PyEval_EvalCode (co=co at entry=0x7ffff7fa8bb0, globals=globals at entry={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}) at Python/ceval.c:667 #6 0x00000000004e0f0f in run_mod (arena=0x7f4710, flags=0x7fffffffe130, locals={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, filename=0x544076 "", mod=0x833030) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe130, locals={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, start=257, str=0x7ed010 "\nclass Foo:\n pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ed010 "\nclass Foo:\n pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n", flags=flags at entry=0x7fffffffe130) at Python/pythonrun.c:975 #9 0x00000000004157d0 in Py_Main (argc=4, argv=) at Modules/main.c:584 #10 0x00007ffff7112fe0 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414e3e in _start () ====================================================================== FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 447, in test_NULL_ob_type 'set op->ob_type=0') File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45e3a0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a13b in file_PyObject_Print (f=0x7ffff7fb7150, f=0x7ffff7fb7150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b4bc5 in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f861f8, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b800b in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #5 0x00000000004b8119 in PyEval_EvalCode (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e0f0f in run_mod (arena=0x7f46e0, flags=0x7fffffffe160, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x544076 "", mod=0x832da8) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe160, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ed010 "print 42\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ed010 "print 42\n", flags=flags at entry=0x7fffffffe160) at Python/pythonrun.c:975 #9 0x00000000004157d0 in Py_Main (argc=4, argv=) at Modules/main.c:584 #10 0x00007ffff7112fe0 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414e3e in _start () ====================================================================== FAIL: test_NULL_ptr (test.test_gdb.PrettyPrintTests) Ensure that a NULL PyObject* is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 442, in test_NULL_ptr self.assertEqual(gdb_repr, '0x0') AssertionError: '0x0, op at entry=42' != '0x0' ====================================================================== FAIL: test_builtin_function (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 579, in test_builtin_function self.assertEqual(gdb_repr, '') AssertionError: 'op at entry=' != '' ====================================================================== FAIL: test_builtin_method (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 586, in test_builtin_method (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45e3a0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a13b in file_PyObject_Print (f=0x7ffff7fb7150, f=0x7ffff7fb7150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b4bc5 in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7fbe200, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b800b in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #5 0x00000000004b8119 in PyEval_EvalCode (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e0f0f in run_mod (arena=0x7f46f0, flags=0x7fffffffe140, locals={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, filename=0x544076 "", mod=0x832e80) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe140, locals={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, start=257, str=0x7ed010 "import sys; print sys.stdout.readlines\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ed010 "import sys; print sys.stdout.readlines\n", flags=flags at entry=0x7fffffffe140) at Python/pythonrun.c:975 #9 0x00000000004157d0 in Py_Main (argc=4, argv=) at Modules/main.c:584 #10 0x00007ffff7112fe0 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414e3e in _start () ====================================================================== FAIL: test_builtins_help (test.test_gdb.PrettyPrintTests) Ensure that the new-style class _Helper in site.py can be handled ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 486, in test_builtins_help msg='Unexpected rendering %r' % gdb_repr) AssertionError: Unexpected rendering 'op at entry=<_Helper at remote 0x7ffff7ee3dd0>' ====================================================================== FAIL: test_classic_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of classic class instances ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 360, in test_classic_class msg='Unexpected classic-class rendering %r' % gdb_repr) AssertionError: Unexpected classic-class rendering 'op at entry=' ====================================================================== FAIL: test_corrupt_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a corrupt ob_type is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 453, in test_corrupt_ob_type expvalue=42) File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45e3a0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a13b in file_PyObject_Print (f=0x7ffff7fb7150, f=0x7ffff7fb7150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b4bc5 in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f861f8, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b800b in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #5 0x00000000004b8119 in PyEval_EvalCode (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e0f0f in run_mod (arena=0x7f46e0, flags=0x7fffffffe160, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x544076 "", mod=0x832da8) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe160, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ed010 "print 42\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ed010 "print 42\n", flags=flags at entry=0x7fffffffe160) at Python/pythonrun.c:975 #9 0x00000000004157d0 in Py_Main (argc=4, argv=) at Modules/main.c:584 #10 0x00007ffff7112fe0 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414e3e in _start () ====================================================================== FAIL: test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_flags is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 459, in test_corrupt_tp_flags expvalue=42) File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45e3a0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a13b in file_PyObject_Print (f=0x7ffff7fb7150, f=0x7ffff7fb7150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b4bc5 in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f861f8, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b800b in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #5 0x00000000004b8119 in PyEval_EvalCode (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e0f0f in run_mod (arena=0x7f46e0, flags=0x7fffffffe160, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x544076 "", mod=0x832da8) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe160, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ed010 "print 42\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ed010 "print 42\n", flags=flags at entry=0x7fffffffe160) at Python/pythonrun.c:975 #9 0x00000000004157d0 in Py_Main (argc=4, argv=) at Modules/main.c:584 #10 0x00007ffff7112fe0 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414e3e in _start () ====================================================================== FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_name is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 465, in test_corrupt_tp_name expvalue=42) File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45e3a0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a13b in file_PyObject_Print (f=0x7ffff7fb7150, f=0x7ffff7fb7150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b4bc5 in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f861f8, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b800b in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #5 0x00000000004b8119 in PyEval_EvalCode (co=co at entry=0x7ffff7fa8830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e0f0f in run_mod (arena=0x7f46e0, flags=0x7fffffffe160, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x544076 "", mod=0x832da8) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe160, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ed010 "print 42\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ed010 "print 42\n", flags=flags at entry=0x7fffffffe160) at Python/pythonrun.c:975 #9 0x00000000004157d0 in Py_Main (argc=4, argv=) at Modules/main.c:584 #10 0x00007ffff7112fe0 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414e3e in _start () ====================================================================== FAIL: test_dicts (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of dictionaries ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 251, in test_dicts self.assertGdbRepr({}) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry={}' != '{}' ====================================================================== FAIL: test_exceptions (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 337, in test_exceptions "exceptions.RuntimeError('I am an error',)") AssertionError: "op at entry=exceptions.RuntimeError('I am an error',)" != "exceptions.RuntimeError('I am an error',)" ====================================================================== FAIL: test_frozensets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of frozensets ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 318, in test_frozensets self.assertGdbRepr(frozenset()) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=frozenset([])' != 'frozenset([])' ====================================================================== FAIL: test_int (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "int" values ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 230, in test_int self.assertGdbRepr(42) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=42' != '42' ====================================================================== FAIL: test_lists (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of lists ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 257, in test_lists self.assertGdbRepr([]) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=[]' != '[]' ====================================================================== FAIL: test_long (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "long" values ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 238, in test_long self.assertGdbRepr(0L) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=0L' != '0L' ====================================================================== FAIL: test_modern_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of new-style class instances ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 372, in test_modern_class msg='Unexpected new-style class rendering %r' % gdb_repr) AssertionError: Unexpected new-style class rendering 'op at entry=' ====================================================================== FAIL: test_selfreferential_dict (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a dict doesn't lead proxyval ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 507, in test_selfreferential_dict self.assertEqual(gdb_repr, "{'foo': {'bar': {...}}}") AssertionError: "op at entry={'foo': {'bar': {...}}}" != "{'foo': {'bar': {...}}}" ====================================================================== FAIL: test_selfreferential_list (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a list doesn't lead proxyval ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 494, in test_selfreferential_list self.assertEqual(gdb_repr, '[3, 4, 5, [...]]') AssertionError: 'op at entry=[3, 4, 5, [...]]' != '[3, 4, 5, [...]]' ====================================================================== FAIL: test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 533, in test_selfreferential_new_style_instance (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=) at remote 0x7ffff7f64310>' Breakpoint 1 at 0x45e3a0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=) at remote 0x7ffff7f64310>, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=) at remote 0x7ffff7f64310>, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a13b in file_PyObject_Print (f=0x7ffff7fb7150, f=0x7ffff7fb7150, flags=1, op=) at remote 0x7ffff7f64310>) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=) at remote 0x7ffff7f64310>, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b4bc5 in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f17050, for file , line 6, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b800b in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fa8bb0, globals=globals at entry={'foo': ) at remote 0x7ffff7f64310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': ) at remote 0x7ffff7f64310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #5 0x00000000004b8119 in PyEval_EvalCode (co=co at entry=0x7ffff7fa8bb0, globals=globals at entry={'foo': ) at remote 0x7ffff7f64310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': ) at remote 0x7ffff7f64310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}) at Python/ceval.c:667 #6 0x00000000004e0f0f in run_mod (arena=0x7f4710, flags=0x7fffffffe120, locals={'foo': ) at remote 0x7ffff7f64310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': ) at remote 0x7ffff7f64310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, filename=0x544076 "", mod=0x833078) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe120, locals={'foo': ) at remote 0x7ffff7f64310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': ) at remote 0x7ffff7f64310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, start=257, str=0x7ed010 "\nclass Foo(object):\n pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ed010 "\nclass Foo(object):\n pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffe120) at Python/pythonrun.c:975 #9 0x00000000004157d0 in Py_Main (argc=4, argv=) at Modules/main.c:584 #10 0x00007ffff7112fe0 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414e3e in _start () ====================================================================== FAIL: test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 520, in test_selfreferential_old_style_instance (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=) at remote 0x7ffff7f8a6c8>' Breakpoint 1 at 0x45e3a0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=) at remote 0x7ffff7f8a6c8>, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=) at remote 0x7ffff7f8a6c8>, fp=0x7ffff74ab800 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a13b in file_PyObject_Print (f=0x7ffff7fb7150, f=0x7ffff7fb7150, flags=1, op=) at remote 0x7ffff7f8a6c8>) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=) at remote 0x7ffff7f8a6c8>, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b4bc5 in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f17050, for file , line 6, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b800b in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fa8bb0, globals=globals at entry={'foo': ) at remote 0x7ffff7f8a6c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': ) at remote 0x7ffff7f8a6c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #5 0x00000000004b8119 in PyEval_EvalCode (co=co at entry=0x7ffff7fa8bb0, globals=globals at entry={'foo': ) at remote 0x7ffff7f8a6c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': ) at remote 0x7ffff7f8a6c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}) at Python/ceval.c:667 #6 0x00000000004e0f0f in run_mod (arena=0x7f4710, flags=0x7fffffffe130, locals={'foo': ) at remote 0x7ffff7f8a6c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': ) at remote 0x7ffff7f8a6c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, filename=0x544076 "", mod=0x833030) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe130, locals={'foo': ) at remote 0x7ffff7f8a6c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': ) at remote 0x7ffff7f8a6c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, start=257, str=0x7ed010 "\nclass Foo:\n pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ed010 "\nclass Foo:\n pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffe130) at Python/pythonrun.c:975 #9 0x00000000004157d0 in Py_Main (argc=4, argv=) at Modules/main.c:584 #10 0x00007ffff7112fe0 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414e3e in _start () ====================================================================== FAIL: test_sets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of sets ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 299, in test_sets self.assertGdbRepr(set()) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=set([])' != 'set([])' ====================================================================== FAIL: test_singletons (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of True, False and None ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 245, in test_singletons self.assertGdbRepr(True) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=True' != 'True' ====================================================================== FAIL: test_strings (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of strings ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 262, in test_strings self.assertGdbRepr('') File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: "op at entry=''" != "''" ====================================================================== FAIL: test_subclassing_list (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a list subclass ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 385, in test_subclassing_list msg='Unexpected new-style class rendering %r' % gdb_repr) AssertionError: Unexpected new-style class rendering 'op at entry=' ====================================================================== FAIL: test_subclassing_tuple (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a tuple subclass ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 399, in test_subclassing_tuple msg='Unexpected new-style class rendering %r' % gdb_repr) AssertionError: Unexpected new-style class rendering 'op at entry=' ====================================================================== FAIL: test_truncation (test.test_gdb.PrettyPrintTests) Verify that very long output is truncated ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jenkins/test test_gdb failed -- multiple errors occurred Downloads/Python-2.7.9/Lib/test/test_gdb.py", line 553, in test_truncation "[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, " AssertionError: 'op at entry=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226...(truncated)' != '[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226...(truncated)' ====================================================================== FAIL: test_tuples (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of tuples ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 269, in test_tuples self.assertGdbRepr(tuple()) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=()' != '()' ====================================================================== FAIL: test_unicode (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of unicode values ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 276, in test_unicode self.assertGdbRepr(u'') File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: "op at entry=u''" != "u''" ---------------------------------------------------------------------- Ran 45 tests in 7.045s FAILED (failures=29, skipped=12) 1 test failed: test_gdb ---------- components: Tests messages: 235293 nosy: vlee priority: normal severity: normal status: open title: Python 2.7.9 test_gdb fails on Fedora 21 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 11:22:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 10:22:06 +0000 Subject: [issue13128] httplib debuglevel on CONNECT doesn't print response headers In-Reply-To: <1318050704.97.0.551622649018.issue13128@psf.upfronthosting.co.za> Message-ID: <20150203102203.96094.1798@psf.io> Roundup Robot added the comment: New changeset dfbd07cdc031 by Berker Peksag in branch 'default': Issue #13128: Print response headers for CONNECT requests when debuglevel > 0. https://hg.python.org/cpython/rev/dfbd07cdc031 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 11:25:14 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 03 Feb 2015 10:25:14 +0000 Subject: [issue13128] httplib debuglevel on CONNECT doesn't print response headers In-Reply-To: <1318050704.97.0.551622649018.issue13128@psf.upfronthosting.co.za> Message-ID: <1422959114.07.0.161076526036.issue13128@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Demian. I've simplified the test code a bit and committed it. Also, thanks for the report and for the initial patch Matt. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 11:36:14 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 03 Feb 2015 10:36:14 +0000 Subject: [issue23379] Incorrect links within PEPs In-Reply-To: <1422900368.04.0.67258841473.issue23379@psf.upfronthosting.co.za> Message-ID: <1422959774.77.0.841528013597.issue23379@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Jonathan. This is a website issue, so I've created a new issue on GitHub: https://github.com/python/pythondotorg/issues/561 ---------- nosy: +berker.peksag resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 12:11:45 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 03 Feb 2015 11:11:45 +0000 Subject: [issue23387] test_urllib2 fails with HTTP Error 502: Bad Gateway Message-ID: <1422961904.97.0.978548371135.issue23387@psf.upfronthosting.co.za> New submission from Berker Peksag: ====================================================================== ERROR: test_issue16464 (test.test_urllib2.MiscTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_urllib2.py", line 1491, in test_issue16464 opener.open(request, "1".encode("us-ascii")) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/urllib/request.py", line 469, in open response = meth(req, response) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/urllib/request.py", line 579, in http_response 'http', request, response, code, msg, hdrs) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/urllib/request.py", line 507, in error return self._call_chain(*args) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/urllib/request.py", line 441, in _call_chain result = func(*args) File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/urllib/request.py", line 587, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) urllib.error.HTTPError: HTTP Error 502: Bad Gateway http://buildbot.python.org/all/builders/ARMv7%20Ubuntu%203.x/builds/2140/steps/test/logs/stdio ---------- components: Tests files: httperror.diff keywords: patch messages: 235336 nosy: berker.peksag, orsenthil priority: normal severity: normal stage: patch review status: open title: test_urllib2 fails with HTTP Error 502: Bad Gateway type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38001/httperror.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 12:12:45 2015 From: report at bugs.python.org (miles) Date: Tue, 03 Feb 2015 11:12:45 +0000 Subject: [issue23382] Maybe can not shutdown ThreadPoolExecutor when call the method of shutdown In-Reply-To: <1422951603.17.0.63584283635.issue23382@psf.upfronthosting.co.za> Message-ID: <1422961965.41.0.299914627762.issue23382@psf.upfronthosting.co.za> miles added the comment: the attachment includes the new code ---------- Added file: http://bugs.python.org/file38002/thread.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 12:24:02 2015 From: report at bugs.python.org (cameris) Date: Tue, 03 Feb 2015 11:24:02 +0000 Subject: [issue23388] datetime.strftime('%s') does not take timezone into account Message-ID: <1422962642.68.0.522001893601.issue23388@psf.upfronthosting.co.za> New submission from cameris: The following occured on linux with python 3.4.2, the machines local timezone is tz2: >>> import datetime >>> tz1 = datetime.timezone.utc; tz2 = datetime.timezone(datetime.timedelta(seconds=3600)); tz3 = datetime.timezone(datetime.timedelta(seconds=18000)) >>> d1 = datetime.datetime.now(tz=tz1); d2 = datetime.datetime.now(tz=tz2); d3 = datetime.datetime.now(tz=tz3) >>> d1.timestamp(), d2.timestamp(), d3.timestamp() (1422962091.603168, 1422962091.603181, 1422962091.603185) >>> d1.strftime('%s'), d2.strftime('%s'), d3.strftime('%s') ('1422958491', '1422962091', '1422976491') Or in other words: >>> d1.strftime('%s') == str(int(d1.timestamp())), d2.strftime('%s') == str(int(d2.timestamp())), d3.strftime('%s') == str(int(d3.timestamp())) (False, True, False) Expected result of the last line would be (True, True, True). ---------- components: Library (Lib) messages: 235338 nosy: cameris priority: normal severity: normal status: open title: datetime.strftime('%s') does not take timezone into account type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 12:44:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 11:44:44 +0000 Subject: [issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <1422963884.95.0.588893392062.issue15381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Some buildbots crash: http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11152/steps/test/logs/stdio http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.x/builds/4/steps/test/logs/stdio http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/1715/steps/test/logs/stdio http://buildbot.python.org/all/builders/AMD64%20Solaris%2011%20%5BSB%5D%203.x/builds/3836/steps/test/logs/stdio E.g.: Fatal Python error: Objects/frameobject.c:429 object at 0x406dd878 has negative ref count -5 Current thread 0x40525ce0 (most recent call first): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 605 in run File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 625 in __call__ File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__ File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__ File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__ File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 168 in run File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1770 in _run_suite File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1804 in run_unittest File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1283 in test_runner File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1284 in runtest_inner File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 967 in runtest File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 763 in main File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/__main__.py", line 3 in File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 85 in _run_code File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 170 in _run_module_as_main Aborted make: *** [buildbottest] Error 134 Trying to reproduce locally and investigate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 13:58:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 12:58:46 +0000 Subject: [issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <20150203125839.106309.98869@psf.io> Roundup Robot added the comment: New changeset 3fdbdf4d2ac7 by Serhiy Storchaka in branch 'default': Issue #15381: Try to fix refcount bug. Empty and 1-byte buffers are always shared. https://hg.python.org/cpython/rev/3fdbdf4d2ac7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 14:30:07 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 03 Feb 2015 13:30:07 +0000 Subject: [issue23386] snmp - mib error In-Reply-To: <1422957022.99.0.675855776064.issue23386@psf.upfronthosting.co.za> Message-ID: <1422970207.59.0.0922278801106.issue23386@psf.upfronthosting.co.za> Eric V. Smith added the comment: pysnmp is not part of the Python standard library. It looks like you should report issues or search for help at at pysnmp.sourceforge.net. ---------- components: -Build nosy: +eric.smith resolution: -> third party stage: -> resolved status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 14:41:02 2015 From: report at bugs.python.org (nivin) Date: Tue, 03 Feb 2015 13:41:02 +0000 Subject: [issue23386] snmp - mib error In-Reply-To: <1422957022.99.0.675855776064.issue23386@psf.upfronthosting.co.za> Message-ID: <1422970862.9.0.375289254729.issue23386@psf.upfronthosting.co.za> nivin added the comment: I have fixed the issue that i reported by creating my mib file into py by the command 'build-pysnmp-mib -o MY-MIB.py MY-MIB' and copy it into the path '/usr/local/lib/python2.7/dist-packages/pysnmp/smi/mibs' But my doubts are : Is there any other option to send snmp trap using python with OID and host id only and without mib file in trap sender. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 14:49:22 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 03 Feb 2015 13:49:22 +0000 Subject: [issue23386] snmp - mib error In-Reply-To: <1422957022.99.0.675855776064.issue23386@psf.upfronthosting.co.za> Message-ID: <1422971362.05.0.0284725008691.issue23386@psf.upfronthosting.co.za> Eric V. Smith added the comment: Your question is not appropriate here, and you're unlikely to get an answer. This tracker is for bugs in python and its standard library. It is not for asking for help with third party packages. See my other comment for a pointer to an appropriate venue for pysnmp questions. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 15:00:58 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Tue, 03 Feb 2015 14:00:58 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1422972058.57.0.803527365609.issue6634@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: Thanks for your feedback Antoine. > I'm not sure what the doc patch achieves. Let me try to bring things in order. It should achieve two things: 1. Properly describe the stderr-writing behavior of sys.exit(). =============================================================== Current 2.7 docs: "..., and any other object is printed to stderr". This is wrong in its generality and requires clarification. Agreed? How would you improve the docs in this regard? This is the reasoning I had in mind: We could change the original sentence, but IMO it then contains too many pieces of important information and becomes difficult to digest, e.g.: "If another type of object is passed, None is equivalent to passing zero, and any other object is printed to stderr (only when called in the main thread) and results in an exit code of 1.". Difficult, right? I thought about removing the stderr part from this sentence and discussing this topic separately, in simpler sentences. But: I think the stderr part needs to stay in the original sentence, because it clarifies how different argument types are dealt with. Then I took another point of view: we have acknowledged that the behavior is problematic, we just cannot change it anymore for 2.7. The direct consequence from this point of view is to warn about current behavior. 6 years ago, I took the docs literally and relied on getting proper error messages printed to stderr. And I didn't get those. I would have appreciated a warning, I guess. With this being said, I'd love to look at an alternative proposal of how we could change the docs in this regard. 2. Clarify that when called from a thread, the thread exits silently ==================================================================== Current 2.7 docs: "Since exit ultimately "only" raises an exception, it will only exit the process when called from the main thread." This sentence is problematic. It relates a cause to an effect, and this relation is wrong or at least incomplete. The only valuable information left in the sentence is the *effect*, without providing an explanation. I would rather want to take the inverse approach, and explain the *cause* as correct as possible. In other words: the above sentence misses to explain what actually happens when sys.exit() is called in a non-primary thread. The actual behavior and cause for mentioned effect is, as far as I am aware: If raised in a non-primary thread, SystemExit is caught automatically and causes the calling thread to exit silently. This is what I added as a note. And I think that we agree that this cause may have many effects, whereas only one of them is that sys.exit() called from a non-primary thread can not terminate the process. > It only states more verbosely what is already > said in the current version. I hope to have convinced you that this is not true. > Also, warnings are really for important issues > (such as security issues); using them too liberally > is a disservice to the reader. I agree. I really think that both points need to be addressed in the docs, and I have now clarified my reasoning, but am very open to further suggestions. And I really do not want to make a strong point about whether things should end up in red or blue boxes :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 15:30:36 2015 From: report at bugs.python.org (Han Choongwoo) Date: Tue, 03 Feb 2015 14:30:36 +0000 Subject: [issue23388] datetime.strftime('%s') does not take timezone into account In-Reply-To: <1422962642.68.0.522001893601.issue23388@psf.upfronthosting.co.za> Message-ID: <1422973836.87.0.837168689935.issue23388@psf.upfronthosting.co.za> Changes by Han Choongwoo : ---------- nosy: +tunz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 15:51:33 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Feb 2015 14:51:33 +0000 Subject: [issue23388] datetime.strftime('%s') does not take timezone into account In-Reply-To: <1422962642.68.0.522001893601.issue23388@psf.upfronthosting.co.za> Message-ID: <1422975093.82.0.204286954488.issue23388@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 16:01:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Feb 2015 15:01:22 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1422975682.61.0.524221603309.issue18932@psf.upfronthosting.co.za> STINNER Victor added the comment: selectors.EpollSelector.modify() should use epoll.modify() instead of unregister()+register(). ---------- title: selectors and modify() -> Optimize selectors.EpollSelector.modify() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 16:01:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Feb 2015 15:01:38 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1422975698.3.0.36298501938.issue18932@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +asyncio nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 16:01:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Feb 2015 15:01:42 +0000 Subject: [issue19017] selectors: towards uniform EBADF handling In-Reply-To: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za> Message-ID: <1422975702.84.0.473166931896.issue19017@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +asyncio nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 16:14:14 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 03 Feb 2015 15:14:14 +0000 Subject: [issue14203] bytearray_getbuffer: unnecessary code In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <1422976454.63.0.366719641812.issue14203@psf.upfronthosting.co.za> Stefan Krah added the comment: New patch with tests. ---------- Added file: http://bugs.python.org/file38003/issue14203-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 16:37:13 2015 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 03 Feb 2015 15:37:13 +0000 Subject: [issue23344] Faster marshalling In-Reply-To: <1422483726.85.0.28053556963.issue23344@psf.upfronthosting.co.za> Message-ID: <1422977833.67.0.715374551301.issue23344@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: looks good to me, although it has been pointed out that marshal _write_ speed is less critical than read speed :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 16:57:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 15:57:59 +0000 Subject: [issue14203] bytearray_getbuffer: unnecessary code In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <20150203155753.39292.99456@psf.io> Roundup Robot added the comment: New changeset e8fe32d43c96 by Stefan Krah in branch 'default': Issue #14203: Remove obsolete support for view==NULL in PyBuffer_FillInfo() https://hg.python.org/cpython/rev/e8fe32d43c96 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 17:16:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 16:16:01 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <20150203161548.25859.79448@psf.io> Roundup Robot added the comment: New changeset 17cda5a92b6a by Raymond Hettinger in branch 'default': Issue 23359: Reduce size of code in set_lookkey. Only do linear probes when there is no wrap-around. https://hg.python.org/cpython/rev/17cda5a92b6a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 17:16:42 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 03 Feb 2015 16:16:42 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1422980202.93.0.686802757389.issue23359@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Serhiy, that was brilliant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 17:34:01 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 03 Feb 2015 16:34:01 +0000 Subject: [issue23388] datetime.strftime('%s') does not take timezone into account In-Reply-To: <1422962642.68.0.522001893601.issue23388@psf.upfronthosting.co.za> Message-ID: <1422981241.28.0.946739837793.issue23388@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This looks like a duplicate of #12750. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 17:35:24 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 03 Feb 2015 16:35:24 +0000 Subject: [issue14203] PEP-3118: remove obsolete write-locks In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <1422981324.2.0.718448600284.issue14203@psf.upfronthosting.co.za> Stefan Krah added the comment: bytesiobuf_getbuffer() also still has this obsolete feature, so BufferError should be raised if view==NULL. I'm unsure if this plays well with the new SHARED_BUF(b) thing. Should the exception be raised before or after? ---------- nosy: +serhiy.storchaka title: bytearray_getbuffer: unnecessary code -> PEP-3118: remove obsolete write-locks _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 17:53:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 16:53:52 +0000 Subject: [issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <20150203165256.34400.79105@psf.io> Roundup Robot added the comment: New changeset ea33b61cac74 by Serhiy Storchaka in branch 'default': Issue #15381: Fixed a bug in BytesIO.write(). https://hg.python.org/cpython/rev/ea33b61cac74 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 18:05:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 17:05:45 +0000 Subject: [issue14203] PEP-3118: remove obsolete write-locks In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <1422983145.54.0.66590289711.issue14203@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think before. It doesn't harm, but it doesn't make much sense to unshare the buffer if its address is not used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 18:11:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 17:11:20 +0000 Subject: [issue14203] PEP-3118: remove obsolete write-locks In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <1422983480.68.0.14720288409.issue14203@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: E.g. the buffer should be unshared before incrementing b->exports, but if an exception is raised instead, there is no need to unshare the buffer before raising. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 18:19:20 2015 From: report at bugs.python.org (cameris) Date: Tue, 03 Feb 2015 17:19:20 +0000 Subject: [issue23388] datetime.strftime('%s') does not take timezone into account In-Reply-To: <1422962642.68.0.522001893601.issue23388@psf.upfronthosting.co.za> Message-ID: <1422983960.2.0.145902343278.issue23388@psf.upfronthosting.co.za> cameris added the comment: Yes, this seems to be exactly the same. Searching with "All text*: '%s'" didn't return anything, therefore I thought it is an unknown bug/behaviour. Well, sorry for the duplicate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 18:55:40 2015 From: report at bugs.python.org (Alistair Lynn) Date: Tue, 03 Feb 2015 17:55:40 +0000 Subject: [issue23389] pkgutil.find_loader raises an ImportError on PEP 420 implicit namespace packages Message-ID: <1422986140.16.0.155842945597.issue23389@psf.upfronthosting.co.za> New submission from Alistair Lynn: The documentation states that __spec__ is None in?and only in?__main__. That this happens also for PEP 420 implicit namespace packages appears to be the cause of the error. ---------- components: Interpreter Core messages: 235357 nosy: alynn priority: normal severity: normal status: open title: pkgutil.find_loader raises an ImportError on PEP 420 implicit namespace packages type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 19:24:13 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 03 Feb 2015 18:24:13 +0000 Subject: [issue23389] pkgutil.find_loader raises an ImportError on PEP 420 implicit namespace packages In-Reply-To: <1422986140.16.0.155842945597.issue23389@psf.upfronthosting.co.za> Message-ID: <1422987853.82.0.0251122350876.issue23389@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 19:44:43 2015 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 03 Feb 2015 18:44:43 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1422989083.98.0.57296462488.issue7434@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. : ---------- nosy: -fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 21:17:27 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 03 Feb 2015 20:17:27 +0000 Subject: [issue14203] PEP-3118: remove obsolete write-locks In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <1422994647.24.0.508854705711.issue14203@psf.upfronthosting.co.za> Stefan Krah added the comment: Ok, thanks! issue14203-3.diff should be correct, then. ---------- Added file: http://bugs.python.org/file38004/issue14203-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 21:43:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 20:43:54 +0000 Subject: [issue14203] PEP-3118: remove obsolete write-locks In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <20150203204349.96080.25092@psf.io> Roundup Robot added the comment: New changeset 0d5095a2422f by Stefan Krah in branch 'default': Issue #14203: Remove obsolete support for view==NULL in bytesiobuf_getbuffer() https://hg.python.org/cpython/rev/0d5095a2422f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 21:57:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 03 Feb 2015 20:57:28 +0000 Subject: [issue14203] PEP-3118: remove obsolete write-locks In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <1422997048.08.0.410122641057.issue14203@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Compiling failed on Windows: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5650 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 22:02:46 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 03 Feb 2015 21:02:46 +0000 Subject: [issue14203] PEP-3118: remove obsolete write-locks In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <1422997366.22.0.630202913785.issue14203@psf.upfronthosting.co.za> Stefan Krah added the comment: Argh, the extern _PyBytesIOBuffer_Type hack. I knew it would cause some trouble. Any ideas how to test bytesiobuf_getbuffer() with a NULL view in a more dignified way? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 22:03:03 2015 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Tue, 03 Feb 2015 21:03:03 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1422997383.38.0.162845627598.issue14910@psf.upfronthosting.co.za> R?mi Rampin added the comment: It looks like the previous comments were addressed in the latest patch. Is this still planned for 3.5? Alpha 1 is next week according to PEP478. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 3 22:27:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Feb 2015 21:27:57 +0000 Subject: [issue14203] PEP-3118: remove obsolete write-locks In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <20150203212748.25841.22481@psf.io> Roundup Robot added the comment: New changeset 17a8c5f8ca48 by Stefan Krah in branch 'default': Issue #14203: Temporary fix for the compile failure on Windows. https://hg.python.org/cpython/rev/17a8c5f8ca48 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 00:09:54 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Tue, 03 Feb 2015 23:09:54 +0000 Subject: [issue18454] distutils crashes when uploading to PyPI having only the username (no pw) defined In-Reply-To: <1373822688.67.0.938925989206.issue18454@psf.upfronthosting.co.za> Message-ID: <1423004994.49.0.0179395680429.issue18454@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: First, I want to address the situation in 2.7. Please have a look at my patch and my reasoning. This is my setup.py test file content: from distutils.core import setup setup(name='foo', version='1.0', packages=['testpackage']) This is the current situation for 2.7 head, in summary: 1) Without a proper .pypirc file in place, uploading fails with "Upload failed (401): You must be identified to edit package information" 2) With a valid .pypirc in place which does not define a password this exception is raised: TypeError: cannot concatenate 'str' and 'NoneType' objects (1) happens due to the fact that the default username/password strings are empty, but the request is still fired against PyPI. This obviously fails. This could be fixed by prompting for both, username and password or by aborting before sending the request. However, this would be quite a significant change in behavior. I think we should not do this, because AFAIK the 2.7 documentation does not specify what the behavior should be *without* existing .pypirc file. So, I think there might not be enough reason to consider such a change a bug fix. What do you think? (2) violates the docs and I guess this is what Nick meant when he said that the stdlib should be updated. I propose a patch so that what the docs say ("If omitted, the user will be prompt to type it when needed") is what actually happens. The patch consists of two parts: Part A: issue18454_py27_prompt.patch ------------------------------------ This uses getpass/sys.stdin.readline() for retrieving the password, depending on whether the process is attached to a tty or not, respectively. The config parsing and value propagation is a little messy in the command/upload.py module, so I have also added comments for clarity and simplified the logic a little. Part B: issue18454_py27_prompt_test.patch ----------------------------------------- Here it gets messy. Normally, we want to have a new test case that fails before applying patch A, and succeeds after applying it. However, here we actually have to deal with an already existing bogus test case which succeeds before and fails after A gets applied. A very bad sign, usually. But in this case I am of the strong opinion that we can and have to change the test implementation, because: - the test actually makes sure that `cmd.password` is set to None when `cmd.finalize_options()` has done its work. However,`cmd.password` being None leads to the TypeError exception described above. That is, this test case basically ensures the very existance of the bug that we want to fix. - it has a suspiciously useless name. It is called `test_saved_password`, but actually tests the case when no password is saved in .pypirc. - this test actually has quite low code coverage. AFAIK it *only* tests the behavior of `cmd.finalize_options()`. We want to change this behavior, so we have to consider changing the test. My patch modifies this test case so that it has a proper name and makes sure that `cmd.finalize_options()` obtains a password from stdin. The involvement of stdin makes testing a little complicated. In a proper testing environment, we'd probably spawn a subprocess and provide it with some real stdin data. The distutils upload command test structure seems not to be prepared for this endeavor, so I have decided to temporarily/locally patch sys.stdin, and ensure restoration with a try/finally clause. With A and B in place, all distutils unit tests validate. I used two methods of invocation, for covering the two cases (with and without attached tty): $ nohup python test_distutils.py 2>&1 > out.log & $ python test_distutils.py ---------- keywords: +patch Added file: http://bugs.python.org/file38005/issue18454_py27_prompt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 00:10:17 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Tue, 03 Feb 2015 23:10:17 +0000 Subject: [issue18454] distutils crashes when uploading to PyPI having only the username (no pw) defined In-Reply-To: <1373822688.67.0.938925989206.issue18454@psf.upfronthosting.co.za> Message-ID: <1423005017.73.0.483987542162.issue18454@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : Added file: http://bugs.python.org/file38006/issue18454_py27_prompt_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 00:28:49 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 03 Feb 2015 23:28:49 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423006129.21.0.847911017415.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: This iteration provides two constructors for TracebackException, one for exception objects, one for exc_info tuples. So it should be easy to use. The __init__ takes the exc_info tuple because thats less code (much easier to destructure rather than restructure), but in the docs and docstrings I point to the classmethods, which includes from_exception - that takes a single exception object. ---------- Added file: http://bugs.python.org/file38007/issue17911-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 00:29:23 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 03 Feb 2015 23:29:23 +0000 Subject: [issue22936] traceback module has no way to show locals In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za> Message-ID: <1423006163.02.0.882052975112.issue22936@psf.upfronthosting.co.za> Robert Collins added the comment: updated with the latest 17911 patch basis. ---------- Added file: http://bugs.python.org/file38008/issue-22936-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 00:44:57 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 03 Feb 2015 23:44:57 +0000 Subject: [issue23390] make profile-opt: test_distutils failure Message-ID: <1423007097.16.0.224366200931.issue23390@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: skrah priority: normal severity: normal status: open title: make profile-opt: test_distutils failure type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 00:48:51 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 03 Feb 2015 23:48:51 +0000 Subject: [issue23390] make profile-opt: test_distutils failure Message-ID: <1423007331.91.0.809486039107.issue23390@psf.upfronthosting.co.za> New submission from Stefan Krah: Currently -fprofile-use etc. appear in the distutils CFLAGS, which causes test_distutils to fail. ---------- keywords: +patch nosy: +gregory.p.smith Added file: http://bugs.python.org/file38009/issue23390.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 02:09:01 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 04 Feb 2015 01:09:01 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1423012141.81.0.437182718463.issue2292@psf.upfronthosting.co.za> Ethan Furman added the comment: All test pass on my system. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 02:19:18 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 04 Feb 2015 01:19:18 +0000 Subject: [issue23363] integer overflow in itertools.permutations In-Reply-To: <1422798853.28.0.166749700091.issue23363@psf.upfronthosting.co.za> Message-ID: <1423012758.3.0.235196513019.issue23363@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: The last fix should be applied also in 2.7 branch. ---------- resolution: fixed -> stage: resolved -> status: closed -> open versions: +Python 2.7, Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 02:20:17 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 04 Feb 2015 01:20:17 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <1423012817.28.0.559076596625.issue23364@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- versions: +Python 2.7, Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 02:22:10 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 04 Feb 2015 01:22:10 +0000 Subject: [issue23365] integer overflow in itertools.combinations_with_replacement In-Reply-To: <1422798943.75.0.0941782409051.issue23365@psf.upfronthosting.co.za> Message-ID: <1423012930.51.0.408000000325.issue23365@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- versions: +Python 2.7, Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 02:25:02 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 04 Feb 2015 01:25:02 +0000 Subject: [issue23366] integer overflow in itertools.combinations In-Reply-To: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> Message-ID: <1423013102.0.0.228779439732.issue23366@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- versions: +Python 2.7, Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 02:28:27 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 04 Feb 2015 01:28:27 +0000 Subject: [issue23369] integer overflow in _json.encode_basestring_ascii In-Reply-To: <1422799175.9.0.580347379364.issue23369@psf.upfronthosting.co.za> Message-ID: <1423013307.61.0.423658019515.issue23369@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- versions: +Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 05:19:54 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 04 Feb 2015 04:19:54 +0000 Subject: [issue23390] make profile-opt: test_distutils failure In-Reply-To: <1423007331.91.0.809486039107.issue23390@psf.upfronthosting.co.za> Message-ID: <1423023594.92.0.0681151901348.issue23390@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Likely a dupe of http://bugs.python.org/issue22904 which is why i set the buildbot up. :) I like your patch here better than my non-fixing poor hack in the other issue. I hadn't noticed CFLAGS_NODIST before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 05:20:25 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 04 Feb 2015 04:20:25 +0000 Subject: [issue22904] make profile-opt includes -fprofile* flags in _sysconfigdata CFLAGS In-Reply-To: <1416437734.43.0.575909256617.issue22904@psf.upfronthosting.co.za> Message-ID: <1423023625.24.0.0968903030586.issue22904@psf.upfronthosting.co.za> Gregory P. Smith added the comment: see also issue23390 ---------- superseder: -> make profile-opt: test_distutils failure _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 05:21:00 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 04 Feb 2015 04:21:00 +0000 Subject: [issue22904] make profile-opt includes -fprofile* flags in _sysconfigdata CFLAGS In-Reply-To: <1416437734.43.0.575909256617.issue22904@psf.upfronthosting.co.za> Message-ID: <1423023660.99.0.932888058188.issue22904@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 06:06:50 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 04 Feb 2015 05:06:50 +0000 Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments disappeared Message-ID: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za> New submission from Martin Panter: Seems to have been removed in revision 097f4fda61a4, for PEP 3151. The older EnvironmentError documentation talks about creating the exception with two and three constructor arguments, however I don?t see this in the new documentation. Is this usage meant to be deprecated, or still allowed? Either way, I think the documentation should mention it. ---------- assignee: docs at python components: Documentation messages: 235372 nosy: docs at python, vadmium priority: normal severity: normal status: open title: Documentation of EnvironmentError (OSError) arguments disappeared versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 06:53:37 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 04 Feb 2015 05:53:37 +0000 Subject: [issue22963] broken link in PEP 102 In-Reply-To: <1417204144.27.0.6150414989.issue22963@psf.upfronthosting.co.za> Message-ID: <1423029217.69.0.395330397909.issue22963@psf.upfronthosting.co.za> Ezio Melotti added the comment: The link in PEP 102 is still wrong, even though the pydotorg issue has been closed. The problem seems to affect txt PEPs (not rst ones), and it can be fixed by simply doing: diff --git a/pep2html.py b/pep2html.py --- a/pep2html.py +++ b/pep2html.py @@ -48,11 +48,11 @@ 'docutils': '0.2.7'} PROGRAM = sys.argv[0] RFCURL = 'http://www.faqs.org/rfcs/rfc%d.html' -PEPURL = 'pep-%04d.html' +PEPURL = '../pep-%04d.html' PEPCVSURL = ('https://hg.python.org/peps/file/tip/pep-%04d.txt') PEPDIRRUL = 'http://www.python.org/peps/' However this breaks the URLs while building/looking at the PEPs locally. (Note: I don't have a github account so I can't reopen the linked issue -- feel free to close this again once the issue has been reported to pydotorg.) ---------- nosy: +benjamin.peterson, ncoghlan status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 07:06:31 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 04 Feb 2015 06:06:31 +0000 Subject: [issue23389] pkgutil.find_loader raises an ImportError on PEP 420 implicit namespace packages In-Reply-To: <1422986140.16.0.155842945597.issue23389@psf.upfronthosting.co.za> Message-ID: <1423029991.12.0.188268042613.issue23389@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 07:08:26 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 04 Feb 2015 06:08:26 +0000 Subject: [issue23389] pkgutil.find_loader raises an ImportError on PEP 420 implicit namespace packages In-Reply-To: <1422986140.16.0.155842945597.issue23389@psf.upfronthosting.co.za> Message-ID: <1423030106.49.0.896591296079.issue23389@psf.upfronthosting.co.za> Eric Snow added the comment: Hmm. If I recall correctly, we set __spec__ for namespace packages... What's a quick way to consistently reproduce the ImportError? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 07:09:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Feb 2015 06:09:59 +0000 Subject: [issue23364] integer overflow in itertools.product In-Reply-To: <1422798904.11.0.859140376922.issue23364@psf.upfronthosting.co.za> Message-ID: <20150204060934.39296.52330@psf.io> Roundup Robot added the comment: New changeset 887526ebb013 by Serhiy Storchaka in branch '2.7': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/887526ebb013 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 07:09:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Feb 2015 06:09:59 +0000 Subject: [issue23365] integer overflow in itertools.combinations_with_replacement In-Reply-To: <1422798943.75.0.0941782409051.issue23365@psf.upfronthosting.co.za> Message-ID: <20150204060934.39296.68323@psf.io> Roundup Robot added the comment: New changeset 887526ebb013 by Serhiy Storchaka in branch '2.7': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/887526ebb013 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 07:09:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Feb 2015 06:09:59 +0000 Subject: [issue23366] integer overflow in itertools.combinations In-Reply-To: <1422798982.69.0.884454194506.issue23366@psf.upfronthosting.co.za> Message-ID: <20150204060934.39296.63384@psf.io> Roundup Robot added the comment: New changeset 887526ebb013 by Serhiy Storchaka in branch '2.7': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/887526ebb013 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 07:09:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Feb 2015 06:09:59 +0000 Subject: [issue23363] integer overflow in itertools.permutations In-Reply-To: <1422798853.28.0.166749700091.issue23363@psf.upfronthosting.co.za> Message-ID: <20150204060934.39296.47883@psf.io> Roundup Robot added the comment: New changeset 887526ebb013 by Serhiy Storchaka in branch '2.7': Issues #23363, #23364, #23365, #23366: Fixed itertools overflow tests. https://hg.python.org/cpython/rev/887526ebb013 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 07:10:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 06:10:39 +0000 Subject: [issue23363] integer overflow in itertools.permutations In-Reply-To: <1422798853.28.0.166749700091.issue23363@psf.upfronthosting.co.za> Message-ID: <1423030239.54.0.987567029975.issue23363@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Arfrever. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 07:14:46 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 04 Feb 2015 06:14:46 +0000 Subject: [issue22963] broken link in PEP 102 In-Reply-To: <1417204144.27.0.6150414989.issue22963@psf.upfronthosting.co.za> Message-ID: <1423030486.69.0.34186772045.issue22963@psf.upfronthosting.co.za> Berker Peksag added the comment: I've opened https://github.com/python/pythondotorg/issues/561 to track the same issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 08:33:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 07:33:53 +0000 Subject: [issue23392] Add tests for marshal FILE* API Message-ID: <1423035233.28.0.238042061902.issue23392@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Marshal C API functions that works with FILE* (PyMarshal_WriteLongToFile, PyMarshal_WriteObjectToFile, PyMarshal_ReadLongFromFile, PyMarshal_ReadShortFromFile, PyMarshal_ReadObjectFromFile, PyMarshal_ReadLastObjectFromFile) are not used now in CPython and are not tested. Proposed patch adds tests for them. ---------- assignee: serhiy.storchaka components: Tests files: test_marshal_file_api.patch keywords: patch messages: 235381 nosy: kristjan.jonsson, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add tests for marshal FILE* API type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38010/test_marshal_file_api.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 08:34:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 07:34:24 +0000 Subject: [issue23344] Faster marshalling In-Reply-To: <1422483726.85.0.28053556963.issue23344@psf.upfronthosting.co.za> Message-ID: <1423035264.04.0.407084711022.issue23344@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka dependencies: +Add tests for marshal FILE* API _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 09:17:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 08:17:41 +0000 Subject: [issue23383] Clean up bytes formatting In-Reply-To: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> Message-ID: <1423037861.92.0.284348907405.issue23383@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks to Martin's suggestions here is even more clean patch. ---------- Added file: http://bugs.python.org/file38011/bytes_format_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 10:49:49 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 04 Feb 2015 09:49:49 +0000 Subject: [issue23390] make profile-opt: test_distutils failure In-Reply-To: <1423007331.91.0.809486039107.issue23390@psf.upfronthosting.co.za> Message-ID: <1423043389.55.0.981712697471.issue23390@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 11:20:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Feb 2015 10:20:26 +0000 Subject: [issue23390] make profile-opt: test_distutils failure In-Reply-To: <1423007331.91.0.809486039107.issue23390@psf.upfronthosting.co.za> Message-ID: <20150204102019.106325.39904@psf.io> Roundup Robot added the comment: New changeset 8957ff9776bd by Gregory P. Smith in branch '3.4': Fixes issue23390: make profile-opt causes -fprofile-generate and related flags https://hg.python.org/cpython/rev/8957ff9776bd New changeset 9c46707e5526 by Gregory P. Smith in branch 'default': Fixes issue23390: make profile-opt causes -fprofile-generate and related flags https://hg.python.org/cpython/rev/9c46707e5526 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 11:31:08 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 04 Feb 2015 10:31:08 +0000 Subject: [issue23390] make profile-opt: test_distutils failure In-Reply-To: <1423007331.91.0.809486039107.issue23390@psf.upfronthosting.co.za> Message-ID: <1423045868.34.0.539955813134.issue23390@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 12:16:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 11:16:49 +0000 Subject: [issue20416] Marshal: special case int and float, don't use references In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1423048609.7.0.339445204269.issue20416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which adds separate dict for interned strings (otherwise they can be uninterned) and for bytes. It also slightly simplify the code. ---------- Added file: http://bugs.python.org/file38012/marshal_refs_by_value_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 12:30:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 11:30:45 +0000 Subject: [issue20416] Marshal: special case int and float, don't use references In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1423049445.89.0.0309317471776.issue20416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And here is alternative patch which uses a hashtable. Both patches have about the same performance for *.pyc files, but marshal_hashtable.patch is much faster for duplicated values. Marshalling [1000]*10**6, [1000.0]*10**6 and [1000.0j]*10**6 with version 3 an 4 is so fast as marshalling [1000]*10**6 with version 2 (i.e. 5 times faster than current implementation). data ver. dumps(ms) loads(ms) size(KiB) genData 2 99.9 188.9 4090.7 genData 3 148.2 189.1 4090.7 genData 4 121.4 177.4 3651.3 [1000]*10**6 2 97.7 131.6 4882.8 [1000]*10**6 3 95.1 63.1 4882.8 [1000]*10**6 4 95.1 64.4 4882.8 [1000.0]*10**6 2 172.9 153.5 8789.1 [1000.0]*10**6 3 97.4 61.9 4882.8 [1000.0]*10**6 4 95.7 61.6 4882.8 [1000.0j]*10**6 2 288.6 228.2 16601.6 [1000.0j]*10**6 3 94.9 61.6 4882.8 [1000.0j]*10**6 4 95.1 62.2 4882.8 20 pydecimals 2 88.0 111.4 3929.6 20 pydecimals 3 57.0 51.4 3368.5 20 pydecimals 4 46.6 39.9 3292.8 ---------- Added file: http://bugs.python.org/file38013/marshal_hashtable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 14:51:46 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 04 Feb 2015 13:51:46 +0000 Subject: [issue14203] PEP-3118: remove obsolete write-locks In-Reply-To: <1330972369.17.0.543217676638.issue14203@psf.upfronthosting.co.za> Message-ID: <1423057906.56.0.66708579599.issue14203@psf.upfronthosting.co.za> Stefan Krah added the comment: I think it's sufficient to test bytesiobuf_getbuffer() on Linux and FreeBSD. The test just checks that the exception is raised. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 15:32:49 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Wed, 04 Feb 2015 14:32:49 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1423060369.65.0.0674039624729.issue14965@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 16:17:16 2015 From: report at bugs.python.org (Ent) Date: Wed, 04 Feb 2015 15:17:16 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1423063036.4.0.785953511595.issue23255@psf.upfronthosting.co.za> Ent added the comment: No I think it's better if you put up a separate patch. That way any questions other reviewers will have, you will be better suited to answer them. Cheers! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 17:41:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 16:41:18 +0000 Subject: [issue19017] selectors: towards uniform EBADF handling In-Reply-To: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za> Message-ID: <1423068078.32.0.05231078548.issue19017@psf.upfronthosting.co.za> STINNER Victor added the comment: > To find an invalid FD when select() fails with EBAD, we can use something like: > http://ufwi.org/projects/nufw/repository/revisions/b4f66edc5d4dc837f75857f8bffe9015454fdebc/entry/src/nuauth/tls_nufw.c#L408 Oh, the link is dead. Copy/paste of the code: --- /* errno == EBADF */ int i; /* A client disconnects between FD_SET and select. * Will try to find it */ for (i=0; imx; ++i){ struct stat s; if (FD_ISSET(i, &context->tls_rx_set)){ if (fstat(i, &s)<0) { log_message(CRITICAL, DEBUG_AREA_USER, "Warning: %d is a bad file descriptor.", i); FD_CLR(i, &context->tls_rx_set); } } } continue; /* retry select */ --- In short: call fstat() if check if the FD is valid or not. O(n) complexity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 17:48:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 16:48:35 +0000 Subject: [issue19017] selectors: towards uniform EBADF handling In-Reply-To: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za> Message-ID: <1423068515.85.0.820069078035.issue19017@psf.upfronthosting.co.za> STINNER Victor added the comment: Guido wrote: "This still leaves case (1), where the FD is already bad when we register it. I am actually fine with sometimes raising and sometimes not; I don't want to pay the extra overhead of doing an fstat() or some other syscall just to verify that it is valid. (Although this would make the argument about wanting to choose a selector class that doesn't make extra syscalls less compelling. :-) And neither do I want to ignore the error in register() and pretend success." The asyncio has a debug mode which can execute expensive checks. These checks would not be acceptable in release mode since they are an impact on performances. In debug mode, asyncio can explicitly call fstat() before calling selector.register() or selector.modify(). This solution may be suggested in the documentation if someone wants a portable behaviour for all selector. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 18:32:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 17:32:21 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1423071141.85.0.984433301184.issue18932@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch: Issue #18932, selectors: Optimize the modify() method of selectors Optimize also register() and unregister() methods of KqueueSelector: only call kqueue.control() once. ---------- keywords: +patch Added file: http://bugs.python.org/file38014/selectors_optimize_modify.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 18:48:26 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 04 Feb 2015 17:48:26 +0000 Subject: [issue23389] pkgutil.find_loader raises an ImportError on PEP 420 implicit namespace packages In-Reply-To: <1422986140.16.0.155842945597.issue23389@psf.upfronthosting.co.za> Message-ID: <1423072106.43.0.104037097837.issue23389@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 18:49:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 17:49:18 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1423072158.69.0.724869474514.issue18932@psf.upfronthosting.co.za> STINNER Victor added the comment: I tested SelectSelector, PollSelector, EpollSelector on Linux. I ran tests on FreeBSD, so also tested KqueueSelector. I didn't test DevpollSelector, but the code should be identical to PollSelector (the API is the same). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 18:50:24 2015 From: report at bugs.python.org (Eli_B) Date: Wed, 04 Feb 2015 17:50:24 +0000 Subject: [issue17023] Subprocess does not find executable on Windows if it is PATH with quotes In-Reply-To: <1359032961.6.0.0734607018969.issue17023@psf.upfronthosting.co.za> Message-ID: <1423072224.16.0.30356510379.issue17023@psf.upfronthosting.co.za> Changes by Eli_B : ---------- nosy: +Eli_B _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 18:53:44 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 04 Feb 2015 17:53:44 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1423072424.24.0.177883254638.issue18932@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: _BaseSelectorImpl.modify() still calls unregister() and register(). To my understanding the whole point of this proposal was to avoid that in order to obtain the speedup and (possibly) avoid race conditions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 19:06:13 2015 From: report at bugs.python.org (Tim Golden) Date: Wed, 04 Feb 2015 18:06:13 +0000 Subject: [issue17023] Subprocess does not find executable on Windows if it is PATH with quotes In-Reply-To: <1359032961.6.0.0734607018969.issue17023@psf.upfronthosting.co.za> Message-ID: <1423073173.95.0.342665304165.issue17023@psf.upfronthosting.co.za> Tim Golden added the comment: Under the covers, subprocess is calling CreateProcess so there's really not very much we can do here, short of writing our own PATH-handling. As a matter of fact, passing shell=True will produce the desired effect. Since the only thing this does is to run the process under cmd.exe I assume that cmd.exe itself adds some kind of PATH handling of its own. I recommend closing as "won't fix". ---------- assignee: -> tim.golden components: +Windows nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 19:14:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 18:14:52 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1423073692.24.0.325973242959.issue22995@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 19:40:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 18:40:33 +0000 Subject: [issue23264] Add pickle support of dict views In-Reply-To: <1421568716.9.0.947546089999.issue23264@psf.upfronthosting.co.za> Message-ID: <1423075233.2.0.265312732973.issue23264@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Antoine. Do you have objections Raymond? I'm going to provide similar patch for MappingView. More robust tests in updated patch. ---------- assignee: -> serhiy.storchaka Added file: http://bugs.python.org/file38015/pickle_dictviews_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 20:16:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 19:16:40 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1423077400.72.0.629984296308.issue23376@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also contiguity tests in Modules/binascii.c and Modules/_ssl.c, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 20:25:15 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 04 Feb 2015 19:25:15 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1423072424.24.0.177883254638.issue18932@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Well, I'd like to see at least one benchmark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 20:45:04 2015 From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Gallou?=) Date: Wed, 04 Feb 2015 19:45:04 +0000 Subject: [issue23393] [Windows] Unable to link with Python in debug configuration Message-ID: <1423079104.29.0.130380017527.issue23393@psf.upfronthosting.co.za> New submission from S?bastien Gallou: Hi all, I installed Python (2.7.9) as binaries under Windows. I have trouble trying to compile my application embedding Python, in debug configuration. I have exactly the same problem as described here : http://www.cmake.org/pipermail/cmake/2013-January/053125.html The include file python.h selects automaticaly the library file to link with, but python27_d.lib (needed in debug configuration) is not provided by the installer. I don't find if this issue was already supported. Thanks, S?bastien Gallou ---------- components: Build, Library (Lib), Windows messages: 235397 nosy: sgallou, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: [Windows] Unable to link with Python in debug configuration type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 20:47:36 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 04 Feb 2015 19:47:36 +0000 Subject: [issue23393] [Windows] Unable to link with Python in debug configuration In-Reply-To: <1423079104.29.0.130380017527.issue23393@psf.upfronthosting.co.za> Message-ID: <1423079256.45.0.750134200101.issue23393@psf.upfronthosting.co.za> Steve Dower added the comment: It's not supported. You'll need to get the Python 2.7 source code and rebuild the binaries under Debug. Python 3.5 will probably have the option to download and install debug versions of the binaries, but Python 2.7 won't be getting this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 20:52:33 2015 From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Gallou?=) Date: Wed, 04 Feb 2015 19:52:33 +0000 Subject: [issue23393] [Windows] Unable to link with Python in debug configuration In-Reply-To: <1423079104.29.0.130380017527.issue23393@psf.upfronthosting.co.za> Message-ID: <1423079553.29.0.215485564439.issue23393@psf.upfronthosting.co.za> S?bastien Gallou added the comment: Thanks Steve for your quick answer. It's now clear for me. I will then apply this workaround : #ifdef PYTHON_USE_SOURCES #include #else #if defined WIN32 && defined _DEBUG #undef _DEBUG // Undef _DEBUG to use only release version of Python.lib. The debug version of Python.lib is not provided with the Windows installer version (https://www.python.org/downloads/windows/) #include #define _DEBUG #else #include #endif #endif // PYTHON_USE_SOURCES S?bastien Gallou ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 21:05:47 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 04 Feb 2015 20:05:47 +0000 Subject: [issue22963] broken link in PEP 102 In-Reply-To: <1417204144.27.0.6150414989.issue22963@psf.upfronthosting.co.za> Message-ID: <1423080347.98.0.171677693488.issue22963@psf.upfronthosting.co.za> Ezio Melotti added the comment: Ok, so I'm closing this again. Berker, can you add a link to this issue too on the pydotorg tracker? ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 21:25:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 20:25:57 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1423081557.24.0.833405690983.issue18932@psf.upfronthosting.co.za> STINNER Victor added the comment: Benchmark on Fedora 21 (Linux 3.18.3, glibc 2.20, Python 3.5 rev 7494f3972726). Original: haypo at selma$ ./python -m timeit -s 'import os, selectors; s=selectors.SelectSelector(); r,w=os.pipe(); s.register(r, selectors.EVENT_READ)' 's.modify(r, selectors.EVENT_WRITE); s.modify(r, selectors.EVENT_READ)' 10000 loops, best of 3: 43.7 usec per loop haypo at selma$ ./python -m timeit -s 'import os, selectors; s=selectors.PollSelector(); r,w=os.pipe(); s.register(r, selectors.EVENT_READ)' 's.modify(r, selectors.EVENT_WRITE); s.modify(r, selectors.EVENT_READ)' 10000 loops, best of 3: 45.1 usec per loop haypo at selma$ ./python -m timeit -s 'import os, selectors; s=selectors.EpollSelector(); r,w=os.pipe(); s.register(r, selectors.EVENT_READ)' 's.modify(r, selectors.EVENT_WRITE); s.modify(r, selectors.EVENT_READ)' 10000 loops, best of 3: 48.4 usec per loop Patched: haypo at selma$ ./python -m timeit -s 'import os, selectors; s=selectors.SelectSelector(); r,w=os.pipe(); s.register(r, selectors.EVENT_READ)' 's.modify(r, selectors.EVENT_WRITE); s.modify(r, selectors.EVENT_READ)' 10000 loops, best of 3: 37.2 usec per loop haypo at selma$ ./python -m timeit -s 'import os, selectors; s=selectors.PollSelector(); r,w=os.pipe(); s.register(r, selectors.EVENT_READ)' 's.modify(r, selectors.EVENT_WRITE); s.modify(r, selectors.EVENT_READ)' 10000 loops, best of 3: 40.5 usec per loop haypo at selma$ ./python -m timeit -s 'import os, selectors; s=selectors.EpollSelector(); r,w=os.pipe(); s.register(r, selectors.EVENT_READ)' 's.modify(r, selectors.EVENT_WRITE); s.modify(r, selectors.EVENT_READ)' 10000 loops, best of 3: 39.9 usec per loop * SelectSelector: 14% faster (-6.5 us) * PollSelector: 10% faster (-4.6 us) * EpollSelector: 18% faster (-8.5 us) -- > _BaseSelectorImpl.modify() still calls unregister() and register(). I chose to factorize code in modify() and only put the specific code in _modify(). The advantage is to pass directly oldkey and key to _modify(). We may even try to keep the selector consistent if _modify() fails. For example, start with unregister, and only register if _modify() succeed. -- In a previous (local) patch, the default implementation of _modify() was: self.unregister(fileobj) return self.register(fileobj, events, data) And each specialized _modify() started with: oldkey = self.unregister(fileobj) key = self.register(fileobj, events, data) Do you prefer this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 21:32:40 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 04 Feb 2015 20:32:40 +0000 Subject: [issue23393] [Windows] Unable to link with Python in debug configuration In-Reply-To: <1423079104.29.0.130380017527.issue23393@psf.upfronthosting.co.za> Message-ID: <1423081960.87.0.251076660074.issue23393@psf.upfronthosting.co.za> Steve Dower added the comment: You'll also need to change your project to use the release version of the C Runtime library and undefine _DEBUG throughout, otherwise you'll get conflicts in things like memory allocators and alignment. It's not quite as simple as choosing another lib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 21:58:02 2015 From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Gallou?=) Date: Wed, 04 Feb 2015 20:58:02 +0000 Subject: [issue23393] [Windows] Unable to link with Python in debug configuration In-Reply-To: <1423079104.29.0.130380017527.issue23393@psf.upfronthosting.co.za> Message-ID: <1423083482.26.0.262649860314.issue23393@psf.upfronthosting.co.za> S?bastien Gallou added the comment: So there is no mean to build my application in debug mode without rebuilding all Python ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 22:06:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 21:06:34 +0000 Subject: [issue22087] _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process In-Reply-To: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za> Message-ID: <1423083994.08.0.392740496312.issue22087@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue looks to be a duplicate of #21998. handle-mp_unix2.patch looks more to a workaround than a real issue. When I write asyncio code, I prefer to pass explicitly the loop, so get_event_loop() should never be called. IMO the methods of the event loop should detect the fork and handle the fork directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 22:22:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Feb 2015 21:22:13 +0000 Subject: [issue20289] Make cgi.FieldStorage a context manager In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za> Message-ID: <1423084933.57.0.15664447899.issue20289@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 22:42:16 2015 From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Trahan?=) Date: Wed, 04 Feb 2015 21:42:16 +0000 Subject: [issue23394] No garbage collection at end of main thread Message-ID: <1423086136.45.0.600991266786.issue23394@psf.upfronthosting.co.za> New submission from Fran?ois Trahan: When reaching the end of a script, there is no garbage collection done if another thread is running. If you have cyclic references between objects that would be elligible for collection under one of which a __del__ would terminate that thread, execution will hang at the end of the "main thread". We ended up in this situation; adding "gc.collect" at the end of our script solves the problem, but this is a library and it is not reasonnable to assume all our clients will properly ensure every execution path properly forces a garbage collection. Suggestion: at the end of a thread, or at least main thread, force a collection. ---------- components: Interpreter Core messages: 235406 nosy: Fran?ois.Trahan priority: normal severity: normal status: open title: No garbage collection at end of main thread versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 22:51:02 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 04 Feb 2015 21:51:02 +0000 Subject: [issue23393] [Windows] Unable to link with Python in debug configuration In-Reply-To: <1423079104.29.0.130380017527.issue23393@psf.upfronthosting.co.za> Message-ID: <1423086662.59.0.746263557549.issue23393@psf.upfronthosting.co.za> Steve Dower added the comment: Afraid not. The closest you can get is building in Release with full debug symbols and no optimisations, which should al lest get you decent debugging. However, you won't get the extra memory check patterns or assertions throughout your code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 22:53:38 2015 From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Gallou?=) Date: Wed, 04 Feb 2015 21:53:38 +0000 Subject: [issue23393] [Windows] Unable to link with Python in debug configuration In-Reply-To: <1423079104.29.0.130380017527.issue23393@psf.upfronthosting.co.za> Message-ID: <1423086818.63.0.912071417168.issue23393@psf.upfronthosting.co.za> S?bastien Gallou added the comment: Thanks Steve, I will try to build it (hope it will not be too difficult...). If I don't success, I will use your solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 23:16:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 22:16:22 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1423088182.67.0.402624410789.issue21998@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached at_fork.patch: detect fork and handle fork. * Add _at_fork() method to asyncio.BaseEventLoop * Add _detect_fork() method to asyncio.BaseEventLoop * Add _at_fork() method to selectors.BaseSelector I tried to minimize the number of calls to _detect_fork(): only when the self-pipe or the selector is used. I only tried test2.py. More tests using two processes running two event loops should be done, and non-regression tests should be written. The issue #22087 (multiprocessing) looks like a duplicate of this issue. ---------- Added file: http://bugs.python.org/file38016/at_fork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 23:18:46 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 22:18:46 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1423088326.97.0.299298376012.issue21998@psf.upfronthosting.co.za> STINNER Victor added the comment: close_self_pipe_after_selector.patch only fixes test2.py, it doesn't fix the general case: run the "same" event loop in two different event loops. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 23:19:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 22:19:32 +0000 Subject: [issue22087] asyncio: support multiprocessing In-Reply-To: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za> Message-ID: <1423088372.02.0.716995339057.issue22087@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: _UnixDefaultEventLoopPolicy should either create a new loop or explicilty fail when get_event_loop() is called from a multiprocessing child process -> asyncio: support multiprocessing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 4 23:58:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Feb 2015 22:58:05 +0000 Subject: [issue22087] asyncio: support multiprocessing In-Reply-To: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za> Message-ID: <1423090685.14.0.879674485289.issue22087@psf.upfronthosting.co.za> STINNER Victor added the comment: See also the https://pypi.python.org/pypi/mpworker project ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 00:49:33 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 04 Feb 2015 23:49:33 +0000 Subject: [issue23264] Add pickle support of dict views In-Reply-To: <1421568716.9.0.947546089999.issue23264@psf.upfronthosting.co.za> Message-ID: <1423093773.58.0.309979913258.issue23264@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 00:50:50 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 04 Feb 2015 23:50:50 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN Message-ID: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> New submission from Thomas Kluyver: In tracking down an obscure error we were seeing, we boiled it down to this test case for thread.interrupt_main(): import signal, threading, _thread, time signal.signal(signal.SIGINT, signal.SIG_DFL) # or SIG_IGN def thread_run(): _thread.interrupt_main() t = threading.Thread(target=thread_run) t.start() time.sleep(10) This fails with an error message "TypeError: 'int' object is not callable", and a traceback completely disconnected from the cause of the error, presumably because it's not coming from the usual Python stack. The problem appears to be that interrupt_main sets (in the C code) Handlers[SIGINT].tripped, which is only expected to occur when the handler is a Python function. When PyErr_CheckSignals() runs, it tries to call Handlers[SIGINT].func as a Python function, but it's a Python integer, causing the error. I think the fix for this is to check what Handlers[sig_num].func is, either in trip_signal() before setting Handlers[sig_num].tripped, or in PyErr_CheckSignals before calling it. I can work on a patch if desired, but I'm not brilliant at C. ---------- components: Library (Lib) messages: 235412 nosy: minrk, takluyver priority: normal severity: normal status: open title: _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 00:56:28 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 04 Feb 2015 23:56:28 +0000 Subject: [issue23394] No garbage collection at end of main thread In-Reply-To: <1423086136.45.0.600991266786.issue23394@psf.upfronthosting.co.za> Message-ID: <1423094188.25.0.968601930168.issue23394@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can you post a simple reproducer so that we can more easily see what you are talking about? Thank you. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 00:57:05 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 04 Feb 2015 23:57:05 +0000 Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za> Message-ID: <1423094225.66.0.577976959359.issue23395@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo, neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 02:12:24 2015 From: report at bugs.python.org (John Boersma) Date: Thu, 05 Feb 2015 01:12:24 +0000 Subject: [issue23396] Wrong print for 2.7.9 Message-ID: <1423098744.16.0.128886256638.issue23396@psf.upfronthosting.co.za> New submission from John Boersma: In the tutorial for 2.7.9, in the section on quotes and the escape character, there is the following example text: >>> '"Isn\'t," she said.' '"Isn\'t," she said.' >>> print '"Isn\'t," she said.' "Isn't," she said. >>> s = 'First line.\nSecond line.' # \n means newline >>> s # without print(), \n is included in the output 'First line.\nSecond line.' >>> print s # with print, \n produces a new line First line. Second line. Note the print() in a comment. Isn't that Python 3 syntax? Should just be print for 2.7, I believe. ---------- assignee: docs at python components: Documentation messages: 235414 nosy: docs at python, johnboersma priority: normal severity: normal status: open title: Wrong print for 2.7.9 type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 02:13:58 2015 From: report at bugs.python.org (John Boersma) Date: Thu, 05 Feb 2015 01:13:58 +0000 Subject: [issue23396] Wrong print for 2.7.9 In-Reply-To: <1423098744.16.0.128886256638.issue23396@psf.upfronthosting.co.za> Message-ID: <1423098838.24.0.585226772.issue23396@psf.upfronthosting.co.za> John Boersma added the comment: To clarify - this is in tutorial section 3.1.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 02:52:11 2015 From: report at bugs.python.org (Piotr Jurkiewicz) Date: Thu, 05 Feb 2015 01:52:11 +0000 Subject: [issue23351] socket.settimeout(5.0) does not have any effect In-Reply-To: <1422581292.34.0.901742947923.issue23351@psf.upfronthosting.co.za> Message-ID: <1423101131.61.0.348655194093.issue23351@psf.upfronthosting.co.za> Piotr Jurkiewicz added the comment: Does not work on Debian 7 Wheezy, kernel 3.2.65. $ python test.py ('sending ', 0) took 0.000s ('sending ', 1) took 0.000s ('sending ', 2) took 0.000s ('sending ', 3) took 0.000s ('sending ', 4) took 0.000s ('sending ', 5) took 0.000s ('sending ', 6) took 0.000s ('sending ', 7) took 0.000s ('sending ', 8) took 0.000s ('sending ', 9) took 0.000s ('sending ', 10) took 0.000s ('sending ', 11) took 0.000s Traceback (most recent call last): File "test.py", line 17, in s.sendto("hello", SOCKNAME) socket.error: [Errno 11] Resource temporarily unavailable $ uname -a Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 04:07:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Feb 2015 03:07:06 +0000 Subject: [issue23396] Wrong print for 2.7.9 In-Reply-To: <1423098744.16.0.128886256638.issue23396@psf.upfronthosting.co.za> Message-ID: <20150205030700.106379.50468@psf.io> Roundup Robot added the comment: New changeset 2bb5fa752bfc by Benjamin Peterson in branch '2.7': remove parenthesis from print statement (closes #23396) https://hg.python.org/cpython/rev/2bb5fa752bfc ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 07:21:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 05 Feb 2015 06:21:25 +0000 Subject: [issue20289] Make cgi.FieldStorage a context manager In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za> Message-ID: <1423117285.74.0.815586313239.issue20289@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's an updated patch. Thank you Serhiy. ---------- Added file: http://bugs.python.org/file38017/issue20289_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 07:25:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Feb 2015 06:25:45 +0000 Subject: [issue23345] test_ssl fails on OS X 10.10.2 with latest patch level of OpenSSL libs In-Reply-To: <1422497052.81.0.264375405718.issue23345@psf.upfronthosting.co.za> Message-ID: <20150205062538.39276.16806@psf.io> Roundup Robot added the comment: New changeset 49f07942fbd7 by Ned Deily in branch '2.7': Issue #23345: Prevent test_ssl failures with large OpenSSL patch level https://hg.python.org/cpython/rev/49f07942fbd7 New changeset 52932cd7f003 by Ned Deily in branch '3.4': Issue #23345: Prevent test_ssl failures with large OpenSSL patch level https://hg.python.org/cpython/rev/52932cd7f003 New changeset 62b322b82f00 by Ned Deily in branch 'default': Issue #23345: merge from 3.4 https://hg.python.org/cpython/rev/62b322b82f00 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 07:28:13 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 05 Feb 2015 06:28:13 +0000 Subject: [issue23345] test_ssl fails on OS X 10.10.2 with latest patch level of OpenSSL libs In-Reply-To: <1422497052.81.0.264375405718.issue23345@psf.upfronthosting.co.za> Message-ID: <1423117693.36.0.155550254584.issue23345@psf.upfronthosting.co.za> Ned Deily added the comment: Fixed for 2.7.10, 3.4.3, and 3.5.0. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 08:27:02 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 05 Feb 2015 07:27:02 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1423121222.19.0.789700885802.issue14910@psf.upfronthosting.co.za> Berker Peksag added the comment: The patch LGTM. In Doc/library/argparse.rst: - add_help=True) + allow_abbrev=True, add_help=True) should be add_help=True, allow_abbrev=True) I'll add a release note and commit it. Thanks! ---------- assignee: -> berker.peksag nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 08:37:20 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 05 Feb 2015 07:37:20 +0000 Subject: [issue23351] socket.settimeout(5.0) does not have any effect In-Reply-To: <1422581292.34.0.901742947923.issue23351@psf.upfronthosting.co.za> Message-ID: <1423121840.63.0.875034383008.issue23351@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: It's a kernel bug closing (working fine on my Debian wheezy with a more recent kernel BTW). ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 09:24:45 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 05 Feb 2015 08:24:45 +0000 Subject: [issue23397] PEP 431 implementation Message-ID: <1423124685.79.0.871732052041.issue23397@psf.upfronthosting.co.za> New submission from Berker Peksag: I have an outdated and WIP patch to implement PEP 431 on GitHub: https://github.com/berkerpeksag/cpython Hopefully, I will complete my work before beta 1. ---------- assignee: berker.peksag components: Library (Lib) messages: 235423 nosy: berker.peksag priority: normal severity: normal stage: needs patch status: open title: PEP 431 implementation type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 09:36:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Feb 2015 08:36:11 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1423125371.36.0.0946944938431.issue23285@psf.upfronthosting.co.za> STINNER Victor added the comment: Would it be possible to push the latest patch right now, and fix remaining issues (if there are known issues?), before Python 3.4 alpha 1? According to the PEP 478, the alpha 1 is scheduled for this sunday (February 8, 2015). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 10:01:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Feb 2015 09:01:53 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1423126913.81.0.0503220485714.issue18932@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch with a less surprising _modify() method: - the default implementation simply calls unregister() + register(), as before - drop SelectSelector._modify(): calling unregister() + register() is just fine ---------- Added file: http://bugs.python.org/file38018/selectors_optimize_modify-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 10:07:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Feb 2015 09:07:34 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1423127254.54.0.50965407827.issue18932@psf.upfronthosting.co.za> STINNER Victor added the comment: > - drop SelectSelector._modify(): calling unregister() + register() is just fine I checked with strace: PollSelector.modify() doesn't require any syscall, so I propose to also drop it (to just call unregister + register). What do you think? I would like to reduce the number of syscalls, calling a C function of the glibc is cheap. > This is a follow up of issue 16853 (see comment http://bugs.python.org/issue16853#msg196984). "(...) the problem with unregister() + register() vs a real modify (e.g. EPOLL_CTL_MOD) is that it's subject to a race condition, if an event fires during the short window where the FD isn't registered anymore." The race condition only occurs with selectors which have a state machine in the kernel: epoll, kqueue, devpoll. SelectSelector and PollSelector are state-less (in the kernel, the state is build for a single syscall and then destroyed). Am I right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 11:41:09 2015 From: report at bugs.python.org (paul) Date: Thu, 05 Feb 2015 10:41:09 +0000 Subject: [issue23361] integer overflow in winapi_createprocess In-Reply-To: <1422798703.49.0.874007534993.issue23361@psf.upfronthosting.co.za> Message-ID: <1423132869.37.0.0119427942809.issue23361@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 11:49:27 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 05 Feb 2015 10:49:27 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423133367.11.0.381711403903.issue17911@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 for having the base __init__ API be the exception triple and then a TracebackException.from_exception() class method as an alternate constructor. However, the redundancy between TracebackException.__init__() and TracebackException.from_exc_tuple() feels very strange to me. It leaves the __init__ working-but-undocumented and isn't a pattern I can recall seeing anywhere else in the standard library. Would it be possible to just add the from_exception() class method and leave the documented (and only) API for building from a triple being the normal constructor call? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 12:03:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Feb 2015 11:03:50 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1423134230.3.0.29035962074.issue21998@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch: - drop PollSelector._at_fork(): PollSelector is not shared with the parent process - _at_fork() of BaseEventLoop and SelectorEventLoop now do nothing by default: only _UnixSelectorEventLoop._at_fork() handle the fork, nothing is needed on Windows - patch written for Python 3.5, not for Tulip (different directories) ---------- Added file: http://bugs.python.org/file38019/at_fork-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 12:21:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Feb 2015 11:21:43 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <1423135303.16.0.454278902908.issue22765@psf.upfronthosting.co.za> STINNER Victor added the comment: > New changeset 5b5a581d91c8 by Serhiy Storchaka in branch '3.4': > Issue #22765: Fixed test_gdb failures. Supressed unexpected gdb output. > https://hg.python.org/cpython/rev/5b5a581d91c8 Since this change, test_gdb fails on "AMD64 OpenIndiana 3.x": http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/9176/ See also issue #23381.. ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 12:25:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Feb 2015 11:25:58 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <1423135558.61.0.810429503746.issue22765@psf.upfronthosting.co.za> STINNER Victor added the comment: A workaround is to check (once) that the command "set print entry-values no" and "set print address off" are supported. Gdb provides its version in the Python API as a string: gdb.VERSION (ex: 'Fedora 7.8.2-38.fc21'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 13:07:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 12:07:28 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <1423138048.13.0.80796740554.issue22765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which adds command 'set print entry-values no' only for gdb version >= 7.4. ---------- Added file: http://bugs.python.org/file38020/test_gdb_entry_values.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 13:32:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 12:32:57 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1423139577.03.0.501037679792.issue22079@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 13:39:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 12:39:46 +0000 Subject: [issue18982] Add tests for CLI of the calendar module In-Reply-To: <1378674520.21.0.168914844213.issue18982@psf.upfronthosting.co.za> Message-ID: <1423139986.82.0.263561687064.issue18982@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks for your review Berker. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 13:52:51 2015 From: report at bugs.python.org (=?utf-8?b?U8O4cmVuIEzDuHZib3Jn?=) Date: Thu, 05 Feb 2015 12:52:51 +0000 Subject: [issue22941] IPv4Interface arithmetic changes subnet mask In-Reply-To: <1416933717.58.0.234544639586.issue22941@psf.upfronthosting.co.za> Message-ID: <1423140770.99.0.710527799709.issue22941@psf.upfronthosting.co.za> S?ren L?vborg added the comment: I take it the silence means that the patch is neither obviously good nor obviously bad. :-) It all comes down to a judgment call: is this a bug, or expected (but undocumented) behavior? In PEP 387 lingo: Is this a "reasonable bug fix"? Or is it a "design mistake", thus calling for a FutureWarning first, and the actual change later? >>> ipaddress.IPv4Interface('1.2.3.4/16') + 1 __main__:1: FutureWarning: Arithmetic on IPv4Interface objects will change in Python 3.6. If you rely on the current behavior, change 'interface + n' to 'IPv4Interface(interface.ip + n, 32)' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 13:55:44 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Feb 2015 12:55:44 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1423140944.75.0.384729714564.issue23285@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Would it be possible to push the latest patch right now It's ok for me. Please watch the buildbots :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 14:19:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Feb 2015 13:19:51 +0000 Subject: [issue18982] Add tests for CLI of the calendar module In-Reply-To: <1378674520.21.0.168914844213.issue18982@psf.upfronthosting.co.za> Message-ID: <20150205131942.34400.58646@psf.io> Roundup Robot added the comment: New changeset 28a9da0842aa by Serhiy Storchaka in branch '3.4': Issue #18982: Add tests for CLI of the calendar module. https://hg.python.org/cpython/rev/28a9da0842aa New changeset e057da873673 by Serhiy Storchaka in branch 'default': Issue #18982: Add tests for CLI of the calendar module. https://hg.python.org/cpython/rev/e057da873673 New changeset 50a5c262b2e6 by Serhiy Storchaka in branch '2.7': Issue #18982: Add tests for CLI of the calendar module. https://hg.python.org/cpython/rev/50a5c262b2e6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 14:29:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 13:29:32 +0000 Subject: [issue20289] Make cgi.FieldStorage a context manager In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za> Message-ID: <1423142972.05.0.883596606867.issue20289@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 17:04:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Feb 2015 16:04:16 +0000 Subject: [issue18982] Add tests for CLI of the calendar module In-Reply-To: <1378674520.21.0.168914844213.issue18982@psf.upfronthosting.co.za> Message-ID: <20150205160410.96078.5438@psf.io> Roundup Robot added the comment: New changeset f2991b52157e by Serhiy Storchaka in branch '2.7': Issue #18982: Fixed newlines in calendar CLI tests on Windows. https://hg.python.org/cpython/rev/f2991b52157e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 17:55:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 16:55:30 +0000 Subject: [issue18982] Add tests for CLI of the calendar module In-Reply-To: <1378674520.21.0.168914844213.issue18982@psf.upfronthosting.co.za> Message-ID: <1423155330.51.0.626052546233.issue18982@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 18:46:37 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 05 Feb 2015 17:46:37 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1423158397.81.0.440752855385.issue18932@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I mean something like this (for epoll), as in avoiding to call unregister() / register() at all: diff -r 017e7391ab58 Lib/selectors.py --- a/Lib/selectors.py Wed Feb 04 08:37:02 2015 -0800 +++ b/Lib/selectors.py Thu Feb 05 18:42:26 2015 +0100 @@ -412,6 +412,23 @@ pass return key + def modify(self, fileobj, events, data=None): + try: + key = self._fd_to_key[self._fileobj_lookup(fileobj)] + except KeyError: + raise KeyError("{!r} is not registered".format(fileobj)) from None + if data != key.data: + key = key._replace(data=data) + self._fd_to_key[key.fd] = key + if events != key.events: + epoll_events = 0 + if events & EVENT_READ: + epoll_events |= select.POLLIN + if events & EVENT_WRITE: + epoll_events |= select.POLLOUT + self._epoll.modify(key.fd, epoll_events) + return key + def select(self, timeout=None): if timeout is None: timeout = -1 Before the patch: ~/svn/python/3.5$ ./python -m timeit -s 'import os, selectors; s=selectors.EpollSelector(); r,w=os.pipe(); s.register(r, selectors.EVENT_READ)' 's.modify(r, selectors.EVENT_WRITE); s.modify(r, selectors.EVENT_READ)' 100000 loops, best of 3: 14.7 usec per loop After the patch: ~/svn/python/3.5$ ./python -m timeit -s 'import os, selectors; s=selectors.EpollSelector(); r,w=os.pipe(); s.register(r, selectors.EVENT_READ)' 's.modify(r, selectors.EVENT_WRITE); s.modify(r, selectors.EVENT_READ)' 100000 loops, best of 3: 3.07 usec per loop That's equal to about a 4.5x (+450%) speedup if I'm not mistaken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 19:29:54 2015 From: report at bugs.python.org (Sergiy) Date: Thu, 05 Feb 2015 18:29:54 +0000 Subject: [issue23398] calendar.monthrange for February 2015 Message-ID: <1423160994.09.0.552874281605.issue23398@psf.upfronthosting.co.za> New submission from Sergiy: >>>print(calendar.monthrange(2015,2)) (6, 28) February has only 5 weeks. ---------- components: Extension Modules messages: 235440 nosy: skarpovsky priority: normal severity: normal status: open title: calendar.monthrange for February 2015 type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 19:32:03 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Feb 2015 18:32:03 +0000 Subject: [issue23397] PEP 431 implementation In-Reply-To: <1423124685.79.0.871732052041.issue23397@psf.upfronthosting.co.za> Message-ID: <1423161123.73.0.296888731599.issue23397@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That would be great! ---------- nosy: +barry, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 19:37:25 2015 From: report at bugs.python.org (Geoffrey Spear) Date: Thu, 05 Feb 2015 18:37:25 +0000 Subject: [issue23398] calendar.monthrange for February 2015 In-Reply-To: <1423160994.09.0.552874281605.issue23398@psf.upfronthosting.co.za> Message-ID: <1423161445.19.0.993703993123.issue23398@psf.upfronthosting.co.za> Geoffrey Spear added the comment: "Returns weekday of first day of the month and number of days in month, for the specified year and month.". The 6 means February began on a Sunday, not that there are 6 weeks in the month. ---------- nosy: +geoffreyspear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 19:44:56 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 05 Feb 2015 18:44:56 +0000 Subject: [issue23398] calendar.monthrange for February 2015 In-Reply-To: <1423160994.09.0.552874281605.issue23398@psf.upfronthosting.co.za> Message-ID: <1423161896.92.0.355968643812.issue23398@psf.upfronthosting.co.za> Ethan Furman added the comment: https://docs.python.org/3/library/calendar.html#calendar.monthrange ---------- nosy: +ethan.furman resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 19:45:49 2015 From: report at bugs.python.org (Robert Collins) Date: Thu, 05 Feb 2015 18:45:49 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423161949.21.0.800359996386.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: I can certainly do that; I was aiming to make it fair I guess, given Antoines strong feelings on this matter. As long as I'm not piggy-in-the-middle, I don't have a care in this regard :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 20:01:02 2015 From: report at bugs.python.org (Eldar Abusalimov) Date: Thu, 05 Feb 2015 19:01:02 +0000 Subject: [issue22735] Fix various crashes exposed through mro() customization In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za> Message-ID: <1423162862.85.0.539862867234.issue22735@psf.upfronthosting.co.za> Eldar Abusalimov added the comment: I feel a bit uneasy, but... any news on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 20:09:23 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Feb 2015 19:09:23 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423163363.94.0.811030189395.issue17911@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I just posted some review comments. I also realized that it posted some older comments that I hadn't submitted before... some of them may be obsolete, sorry :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 20:27:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 19:27:01 +0000 Subject: [issue17753] test_zipfile: requires write access to test and email.test In-Reply-To: <1366109637.36.0.807884734436.issue17753@psf.upfronthosting.co.za> Message-ID: <1423164421.8.0.762935453051.issue17753@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which skips tests if there are no write access to the installed location. ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 2.7 Added file: http://bugs.python.org/file38021/issue17753.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 20:27:28 2015 From: report at bugs.python.org (Anthony Sottile) Date: Thu, 05 Feb 2015 19:27:28 +0000 Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline string expressions In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za> Message-ID: <1423164448.94.0.48037316687.issue16806@psf.upfronthosting.co.za> Changes by Anthony Sottile : ---------- nosy: +asottile _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 20:30:51 2015 From: report at bugs.python.org (Anthony Sottile) Date: Thu, 05 Feb 2015 19:30:51 +0000 Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline string expressions In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za> Message-ID: <1423164651.52.0.2125290317.issue16806@psf.upfronthosting.co.za> Anthony Sottile added the comment: Any updates on this? I'm running into this as well (still a problem in 3.4) ```$ python3.4 Python 3.4.2 (default, Oct 11 2014, 17:59:27) [GCC 4.4.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ast >>> ast.parse("""'''foo\n'''""").body[0].value.col_offset -1 ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 20:33:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 19:33:27 +0000 Subject: [issue10631] ZipFile and current directory change In-Reply-To: <1291567761.41.0.659026181219.issue10631@psf.upfronthosting.co.za> Message-ID: <1423164807.27.0.246990552414.issue10631@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed in issue14099 for 3.5. Do you think that this solution should be backported Martin? An alternative solution of this issue would be to convert relative path to absolute path in ZipFile constructor. ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 20:36:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 19:36:38 +0000 Subject: [issue23306] Within zipfile, use of zlib.crc32 raises OverflowError at argument-parsing time on large strings In-Reply-To: <1422056966.81.0.518971767948.issue23306@psf.upfronthosting.co.za> Message-ID: <1423164998.89.0.15148909908.issue23306@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 20:50:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 19:50:49 +0000 Subject: [issue11152] pb in zipfile module In-Reply-To: <1297178536.07.0.390050074188.issue11152@psf.upfronthosting.co.za> Message-ID: <1423165849.51.0.356069103435.issue11152@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as this bug was fixed in issue1710703. ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 20:52:39 2015 From: report at bugs.python.org (Vinson Lee) Date: Thu, 05 Feb 2015 19:52:39 +0000 Subject: [issue23381] Python 2.7.9+ test_gdb regression on Ubuntu 10.04 In-Reply-To: <1422922493.9.0.93892499408.issue23381@psf.upfronthosting.co.za> Message-ID: <1423165959.68.0.866684749121.issue23381@psf.upfronthosting.co.za> Changes by Vinson Lee : ---------- keywords: +patch Added file: http://bugs.python.org/file38022/0001-Issue-23881-Only-use-entry-values-with-gdb-7.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 21:51:37 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 05 Feb 2015 20:51:37 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1423140944.75.0.384729714564.issue23285@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Antoine Pitrou added the comment: > >> Would it be possible to push the latest patch right now > > It's ok for me. Please watch the buildbots :) Cool, I'll push on Friday evening or Saturday. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 21:59:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Feb 2015 20:59:21 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1423158397.81.0.440752855385.issue18932@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2015-02-05 18:46 GMT+01:00 Giampaolo Rodola' : > + def modify(self, fileobj, events, data=None): > + ... > + if events != key.events: You should update the SelectorKey in the case, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 22:20:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 21:20:11 +0000 Subject: [issue17189] Add zip64 support to shutil In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za> Message-ID: <1423171211.5.0.421260018144.issue17189@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: -Use allowZip64=True by default resolution: -> out of date superseder: -> Use allowZip64=True by default _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 22:20:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 21:20:26 +0000 Subject: [issue17189] Add zip64 support to shutil In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za> Message-ID: <1423171226.33.0.727602657974.issue17189@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 22:24:35 2015 From: report at bugs.python.org (eryksun) Date: Thu, 05 Feb 2015 21:24:35 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1423171475.68.0.314282398217.issue14099@psf.upfronthosting.co.za> eryksun added the comment: The changeset from 03 Dec is in the Windows 2.7.9 release. Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import zipfile >>> zipfile._SharedFile ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 22:27:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Feb 2015 21:27:06 +0000 Subject: [issue21717] Exclusive mode for ZipFile and TarFile In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za> Message-ID: <1423171626.44.0.678790235049.issue21717@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 23:18:10 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 05 Feb 2015 22:18:10 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1423163363.94.0.811030189395.issue17911@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I think in this case, the fact that it's easier to decompose an exception into the corresponding triple rather than vice-versa, together with the fact that other exception state manipulation APIs like exc_info() and __exit__() methods work with triples, means it makes sense to accept the triple as the base constuctor API, and then have the convenience method to destructure a caught exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 5 23:19:29 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Feb 2015 22:19:29 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: Message-ID: <54D3EC6F.20000@free.fr> Antoine Pitrou added the comment: The solution of having two constructor classmethods actually seems nice and symmetric to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 01:03:01 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 06 Feb 2015 00:03:01 +0000 Subject: [issue23399] venv should create relative symlinks where possible Message-ID: <1423180981.46.0.156182357728.issue23399@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: There is a subtle behavior difference between virtualenv and pyvenv. When you create a venv with virtualenv, the symbolic links files /bin are relative, while they are absolute with pyvenv. This means that virtual environments created with virtualenv can be relocated (modulo the #! lines of the script, but let's not worry about that for now), but virtual environments created with pyvenv cannot be relocated. With pyvenv, you also have /lib64 pointing to an absolute path. AFAICT, there's no good reason why the symlink targets must be absolute paths. Relative paths work just fine for virtualenv and they should work fine for pyvenv. This patch changes the lib64 and /bin/* symlinks to be relative. There should be no change when symlinks are disabled or are unavailable. One remaining question is whether /bin/python itself should be relative. In virtualenv, even with something like `-p /usr/bin/python3.4` you still get a relative link. /bin/python points outside of the venv, so the question is whether the $PATH-dependent behavior of virtualenv is worthwhile or not. My patch does not change this symlink. ---------- assignee: vinay.sajip components: Library (Lib) files: venv.patch keywords: patch messages: 235457 nosy: barry, dstufft, vinay.sajip priority: normal severity: normal stage: patch review status: open title: venv should create relative symlinks where possible type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38023/venv.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 02:37:17 2015 From: report at bugs.python.org (Ben Hoyt) Date: Fri, 06 Feb 2015 01:37:17 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423186637.36.0.30622180159.issue22524@psf.upfronthosting.co.za> Ben Hoyt added the comment: Victor, I'd love to push forward with this (I doubt it's going to make alpha 1 on February 8, but hopefully alpha 2 on March 8). It seems pretty settled that we need to use the all-C version I've created, especially for Linux. Can you please review scandir-2.patch? It's on Rietveld here: http://bugs.python.org/review/22524/#ps13104 You can see what changed between scandir-1.patch and scandir-2.patch more easily here: https://github.com/benhoyt/scandir/commit/d4e2d7083319ed8988aef6ed02d670fb36a00a33 Also, here is just the scandir C code in its own file: https://github.com/benhoyt/scandir/blob/d4e2d7083319ed8988aef6ed02d670fb36a00a33/posixmodule_scandir_main.c One other open question is: should it go into CPython's posixmodule.c as I have it in the patch, or should I try to separate it out? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 04:05:42 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 06 Feb 2015 03:05:42 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1423191942.76.0.565497477442.issue18932@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Yes, it appears so. I would suggest to come up with a patch which overrides modify() for all those selectors which can benefit from it (poll, epoll, kqueue) and refactor register() / unregister() (for select) in a separate issue / patch. Also, I suppose a couple of tests should be added (if not there already) in order to make sure that 'events' and 'data' arguments get actually changed in different situations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 04:08:46 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 06 Feb 2015 03:08:46 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1423192126.75.0.27703132109.issue18932@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- stage: -> needs patch type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 04:17:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Feb 2015 03:17:13 +0000 Subject: [issue23212] Update Windows and OS X installer copies of OpenSSL to 1.0.1l In-Reply-To: <1420833910.43.0.203396056169.issue23212@psf.upfronthosting.co.za> Message-ID: <20150206031710.25853.32727@psf.io> Roundup Robot added the comment: New changeset 7b74c65758ca by Ned Deily in branch '2.7': Issue #23212: Update OS X installer build OpenSSL to 1.0.1l. https://hg.python.org/cpython/rev/7b74c65758ca New changeset 1ddf68f118c7 by Ned Deily in branch '3.4': Issue #23212: Update OS X installer build OpenSSL to 1.0.1l. https://hg.python.org/cpython/rev/1ddf68f118c7 New changeset aeba7274d68a by Ned Deily in branch 'default': Issue #23212: merge from 3.4 https://hg.python.org/cpython/rev/aeba7274d68a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 04:19:58 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 06 Feb 2015 03:19:58 +0000 Subject: [issue23212] Update Windows and OS X installer copies of OpenSSL to 1.0.1l In-Reply-To: <1420833910.43.0.203396056169.issue23212@psf.upfronthosting.co.za> Message-ID: <1423192798.86.0.930419101248.issue23212@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 04:31:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Feb 2015 03:31:03 +0000 Subject: [issue22735] Fix various crashes exposed through mro() customization In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za> Message-ID: <20150206033055.34404.56124@psf.io> Roundup Robot added the comment: New changeset 6384c0cd3b2d by Benjamin Peterson in branch '3.4': fix many custom mro() edge cases and improve code quality (#22735) https://hg.python.org/cpython/rev/6384c0cd3b2d New changeset 75fd0bd89eef by Benjamin Peterson in branch 'default': merge 3.4 (#22735) https://hg.python.org/cpython/rev/75fd0bd89eef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 05:01:12 2015 From: report at bugs.python.org (Daniil Bondarev) Date: Fri, 06 Feb 2015 04:01:12 +0000 Subject: [issue2786] Names in traceback should have class names, if they're methods In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za> Message-ID: <1423195272.62.0.492133475187.issue2786@psf.upfronthosting.co.za> Daniil Bondarev added the comment: As long as you think It fits into your issue, I'm ok with adding this patch to it (: it's different files, so no conflicts. Should I just add this patch to your ticket? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 07:12:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Feb 2015 06:12:49 +0000 Subject: [issue23260] Update Windows installer In-Reply-To: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> Message-ID: <20150206061242.34382.16330@psf.io> Roundup Robot added the comment: New changeset e7dbef447157 by Steve Dower in branch 'default': Issue #23260: Update Windows installer https://hg.python.org/cpython/rev/e7dbef447157 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 07:13:21 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 06 Feb 2015 06:13:21 +0000 Subject: [issue23260] Update Windows installer In-Reply-To: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> Message-ID: <1423203201.01.0.225508960773.issue23260@psf.upfronthosting.co.za> Steve Dower added the comment: Got about as many reviews as I expected, but the builds have been going fine and I want this checked in before alpha, so in it goes :) ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 08:02:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Feb 2015 07:02:08 +0000 Subject: [issue23392] Add tests for marshal FILE* API In-Reply-To: <1423035233.28.0.238042061902.issue23392@psf.upfronthosting.co.za> Message-ID: <20150206070142.106309.46568@psf.io> Roundup Robot added the comment: New changeset e55f955659bc by Serhiy Storchaka in branch '2.7': Issue #23392: Added tests for marshal C API that works with FILE*. https://hg.python.org/cpython/rev/e55f955659bc New changeset 05153851d1d6 by Serhiy Storchaka in branch '3.4': Issue #23392: Added tests for marshal C API that works with FILE*. https://hg.python.org/cpython/rev/05153851d1d6 New changeset 7f22813496de by Serhiy Storchaka in branch 'default': Issue #23392: Added tests for marshal C API that works with FILE*. https://hg.python.org/cpython/rev/7f22813496de ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 08:02:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Feb 2015 07:02:08 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <20150206070142.106309.19265@psf.io> Roundup Robot added the comment: New changeset 30e6c8caa5b9 by Serhiy Storchaka in branch '3.4': Issue #23881: Only use entry-values with gdb 7.4 in tests. https://hg.python.org/cpython/rev/30e6c8caa5b9 New changeset 981e108039f1 by Serhiy Storchaka in branch 'default': Issue #23881: Only use entry-values with gdb 7.4 in tests. https://hg.python.org/cpython/rev/981e108039f1 New changeset cee39701b280 by Serhiy Storchaka in branch '2.7': Issue #23881: Only use entry-values with gdb 7.4 in tests. https://hg.python.org/cpython/rev/cee39701b280 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 08:05:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 07:05:04 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <1423206304.21.0.25110831689.issue22765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Actually this is #23381, not #23881. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 08:08:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 07:08:51 +0000 Subject: [issue23381] Python 2.7.9+ test_gdb regression on Ubuntu 10.04 In-Reply-To: <1422922493.9.0.93892499408.issue23381@psf.upfronthosting.co.za> Message-ID: <1423206531.68.0.201105639443.issue23381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I provided similar patch in issue22765, but your patch looks more clear. Committed in 30e6c8caa5b9, 981e108039f1, and cee39701b280. Thanks for your patch Vinson. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 08:09:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 07:09:08 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <1423206548.85.0.675636829521.issue22765@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 08:11:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 07:11:58 +0000 Subject: [issue20416] Marshal: performance regression with versions 3 and 4 In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1423206718.72.0.262162350454.issue20416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What are your thoughts Victor? ---------- title: Marshal: special case int and float, don't use references -> Marshal: performance regression with versions 3 and 4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 08:12:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 07:12:50 +0000 Subject: [issue23392] Add tests for marshal FILE* API In-Reply-To: <1423035233.28.0.238042061902.issue23392@psf.upfronthosting.co.za> Message-ID: <1423206770.62.0.825698515412.issue23392@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 08:47:02 2015 From: report at bugs.python.org (Vinson Lee) Date: Fri, 06 Feb 2015 07:47:02 +0000 Subject: [issue19884] Importing readline produces erroneous output In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za> Message-ID: <1423208822.49.0.714922986411.issue19884@psf.upfronthosting.co.za> Changes by Vinson Lee : ---------- nosy: +vlee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 09:22:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 06 Feb 2015 08:22:03 +0000 Subject: [issue20289] Make cgi.FieldStorage a context manager In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za> Message-ID: <1423210923.47.0.697092302167.issue20289@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review, Serhiy! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 09:22:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Feb 2015 08:22:22 +0000 Subject: [issue20289] Make cgi.FieldStorage a context manager In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za> Message-ID: <20150206082113.106335.84966@psf.io> Roundup Robot added the comment: New changeset 367f5e98ffbb by Berker Peksag in branch 'default': Issue #20289: cgi.FieldStorage() now supports the context management protocol. https://hg.python.org/cpython/rev/367f5e98ffbb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 09:34:55 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 06 Feb 2015 08:34:55 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <54D3EC6F.20000@free.fr> Message-ID: Nick Coghlan added the comment: It's genuinely user hostile, as the "from_exc_tuple" version is entirely redundant, and folks using pydoc to discover the API won't know they "shouldn't" use the constructor directly. That means both forms will get used, but only one will be documented. When people ask why a second spelling for the lower level API was added, "to make it look like it exists at the same level as the higher level convenience API" isn't going to be a satisfying explanation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 10:00:34 2015 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 06 Feb 2015 09:00:34 +0000 Subject: [issue23399] venv should create relative symlinks where possible In-Reply-To: <1423180981.46.0.156182357728.issue23399@psf.upfronthosting.co.za> Message-ID: <1423213234.46.0.545685010055.issue23399@psf.upfronthosting.co.za> Vinay Sajip added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 10:03:19 2015 From: report at bugs.python.org (Ole Streicher) Date: Fri, 06 Feb 2015 09:03:19 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented Message-ID: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> New submission from Ole Streicher: On Debian Hurd, there is no sem_open implementation. When I try there to create a Queue, I get different errors, depending on the Python version: import multiprocessing q = multiprocessing.Queue() gives on Python 2.7.9: maxsize = 0 def Queue(maxsize=0): ''' Returns a queue object ''' > from multiprocessing.queues import Queue /usr/lib/python2.7/multiprocessing/__init__.py:217: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __all__ = ['Queue', 'SimpleQueue', 'JoinableQueue'] import sys import os import threading import collections import time import atexit import weakref from Queue import Empty, Full import _multiprocessing from multiprocessing import Pipe > from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, Condition /usr/lib/python2.7/multiprocessing/queues.py:48: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 'Lock', 'RLock', 'Semaphore', 'BoundedSemaphore', 'Condition', 'Event' ] import threading import os import sys from time import time as _time, sleep as _sleep import _multiprocessing from multiprocessing.process import current_process from multiprocessing.util import Finalize, register_after_fork, debug from multiprocessing.forking import assert_spawning, Popen # Try to import the mp.synchronize module cleanly, if it fails # raise ImportError for platforms lacking a working sem_open implementation. # See issue 3770 try: from _multiprocessing import SemLock except (ImportError): raise ImportError("This platform lacks a functioning sem_open" + " implementation, therefore, the required" + " synchronization primitives needed will not" + > " function, see issue 3770.") E ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770. /usr/lib/python2.7/multiprocessing/synchronize.py:59: ImportError and on 3.4.2: self = , maxsize = 0 def Queue(self, maxsize=0): '''Returns a queue object''' from .queues import Queue > return Queue(maxsize, ctx=self.get_context()) /usr/lib/python3.4/multiprocessing/context.py:101: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = , maxsize = 0 def __init__(self, maxsize=0, *, ctx): if maxsize <= 0: > maxsize = _multiprocessing.SemLock.SEM_VALUE_MAX E AttributeError: 'module' object has no attribute 'SemLock' /usr/lib/python3.4/multiprocessing/queues.py:38: AttributeError Both traces are actually copied from Debian build logs: 2.7.9: https://buildd.debian.org/status/fetch.php?pkg=python-astropy&arch=hurd-i386&ver=1.0~rc1-1&stamp=1422724845 3.4.2: https://buildd.debian.org/status/fetch.php?pkg=python-astropy&arch=hurd-i386&ver=1.0~rc1-2&stamp=1423153281 Neither for 2.7.9 nor for 3.4.2 this behaviour is documented. Also, I would expect to have a NotImplementedError and not an ImportError or an AttributeError in such a case. Please: * document the behaviour of multiprocessing.Queue() in the case of an absent sem_open for both Python2 and Python3 * Consider raising NotImplementedError or being consistent in some other way. ---------- components: Library (Lib) messages: 235474 nosy: olebole priority: normal severity: normal status: open title: Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 10:58:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 09:58:55 +0000 Subject: [issue23401] Add pickle support of Mapping views Message-ID: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds pickle support of general Mapping views. See also issue23264. ---------- components: Library (Lib) messages: 235475 nosy: alexandre.vassalotti, pitrou, rhettinger, serhiy.storchaka, stutzbach priority: normal severity: normal stage: patch review status: open title: Add pickle support of Mapping views type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 10:59:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 09:59:54 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1423216794.55.0.0885507155866.issue23401@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file38024/pickle_mapping_views.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 11:01:52 2015 From: report at bugs.python.org (Matthias Urlichs) Date: Fri, 06 Feb 2015 10:01:52 +0000 Subject: [issue2786] Names in traceback should have class names, if they're methods In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za> Message-ID: <1423216912.66.0.834341726547.issue2786@psf.upfronthosting.co.za> Matthias Urlichs added the comment: Please do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 11:59:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 10:59:02 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1423220342.09.0.607152258634.issue23401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are many ways to pickle e.g. Mapping keys: 1) Default implementation (as an instances of Python class MappingKey). This is implementation depended and exposes private variable _mapping. Changing implementation of the keys() method will break compatibility. 2) As `self.__class__, (self._mapping,)`. It depends on implementation of keys() as MappingKey or MappingKey subclass. It doesn't very subclass friendly if keys() is more complex or MappingKey subclass requires additional parameters. 3) As `self._mapping.__class__.keys, (self._mapping,)`. Implementation agnostic, perhaps more efficient than option 4 because self._mapping.__class__.keys may be shared. But needs protocol 4. 4) As `self._mapping.keys, ()`. Implementation agnostic. pickle_mapping_views.patch implements option 4, the patch in issue23264 implements option 3 (it works for dict with all protocols, but needs protocol 4 for dict subclasses). Perhaps implementations should be unified (use option 3 with protocol 4 and option 3 otherwise). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 12:22:27 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 06 Feb 2015 11:22:27 +0000 Subject: [issue21717] Exclusive mode for ZipFile and TarFile In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za> Message-ID: <1423221747.24.0.630085785523.issue21717@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's an updated patch. Thanks Serhiy. ---------- Added file: http://bugs.python.org/file38025/issue21717_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 13:39:25 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Feb 2015 12:39:25 +0000 Subject: [issue20416] Marshal: performance regression with versions 3 and 4 In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1423226365.39.0.782112726042.issue20416@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can you post the results of your hashtable patch with marshalbench.py? PS: we don't care about versions older than 4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 13:43:39 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Feb 2015 12:43:39 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: Message-ID: <54D4B6F7.4050504@free.fr> Antoine Pitrou added the comment: Le 06/02/2015 09:34, Nick Coghlan a ?crit : > > It's genuinely user hostile, as the "from_exc_tuple" version is entirely > redundant, and folks using pydoc to discover the API won't know they > "shouldn't" use the constructor directly. Using pydoc isn't generally a successful way of discovering an API. It shows you too many details that don't matter. Besides our docstrings are much terser and less informative than the Sphinx doc. pydoc is useful mostly as a Python-specific "man" command: you know something exists, just want to remember the details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 14:00:17 2015 From: report at bugs.python.org (Matthew Atkinson) Date: Fri, 06 Feb 2015 13:00:17 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1423227617.12.0.464645144201.issue11352@psf.upfronthosting.co.za> Matthew Atkinson added the comment: Hi I've modified Pierre's patch to apply to the latest 3.5 and 3.4, and made the most of the simple changes suggested in http://bugs.python.org/review/11352/#ps4792 . I've also added all the non internal parameters to the FieldStorage constructor, and descriptions of them. Thanks, Matt ---------- nosy: +mutley89 Added file: http://bugs.python.org/file38026/cgi-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 14:29:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 13:29:32 +0000 Subject: [issue21717] Exclusive mode for ZipFile and TarFile In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za> Message-ID: <1423229372.11.0.1188385722.issue21717@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added more comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 14:31:41 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 06 Feb 2015 13:31:41 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423229501.23.0.469429869729.issue17911@psf.upfronthosting.co.za> Nick Coghlan added the comment: dir() will get me TracebackException as a name, help(traceback.TracebackException) will get me its signature. IDEs with autocomplete and signature tooltips will do the same. There is nothing in those usage sequences to say "don't use __init__, use this redundant class method with the same signature instead". I agree providing a "directly from an exception" constructor is essential for cases where you're working with a caught exception at the Python level. I don't agree with the idea of duplicating the required low level API under a different name so it doesn't *look* like a lower level API in the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 14:52:32 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 06 Feb 2015 13:52:32 +0000 Subject: [issue22735] Fix various crashes exposed through mro() customization In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za> Message-ID: <1423230752.86.0.162385209543.issue22735@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for the very high quality patch. The way it was split made it much easier to review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 15:11:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 14:11:15 +0000 Subject: [issue20416] Marshal: performance regression with versions 3 and 4 In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1423231875.67.0.948182127014.issue20416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are new results with corrected marshalbench.py (more precise and with recalculated total size): Without the patch: ver. dumps loads size 746.5 19971.2 0 669.1 1149.2 26202.9 1 682.0 1130.1 26202.9 2 652.0 1134.8 26202.4 3 920.8 757.9 21316.7 4 771.2 691.4 19971.2 With marshal3_numbers.patch: 3 894.6 778.4 21321.6 4 733.1 704.2 19976.2 With marshal_refs_by_value_3.patch: 3 687.6 777.7 21310.3 4 535.5 701.5 19966.3 With marshal_hashtable.patch: 3 656.0 764.2 21316.7 4 512.9 696.6 19971.2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 16:55:03 2015 From: report at bugs.python.org (Eldar Abusalimov) Date: Fri, 06 Feb 2015 15:55:03 +0000 Subject: [issue22735] Fix various crashes exposed through mro() customization In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za> Message-ID: <1423238103.17.0.222993334657.issue22735@psf.upfronthosting.co.za> Eldar Abusalimov added the comment: You're welcome, and thank you too for reviewing and merging it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 17:32:27 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 06 Feb 2015 16:32:27 +0000 Subject: [issue23128] Key presses are doubled in Tkinter dialog invoked from window close handler with Cocoa Tk In-Reply-To: <1419870862.78.0.0503102610416.issue23128@psf.upfronthosting.co.za> Message-ID: <1423240347.72.0.354110354361.issue23128@psf.upfronthosting.co.za> Ned Deily added the comment: The test case appears to only fail with OS X Cocoa Tk (tested with Tk 8.5.17 and 8.6.3); it does not fail with the older OS X Carbon Tk 8.4.20 nor with X11 Tk 8.6.3. It also fails similarly with Python 3.4.x. FWIW, there have been other reported problems with Tkinter SimpleDialog functions using Cocoa Tk, for example Issue16023, and a number of other issues unique to Cocoa Tk. These kinds of problems are usually not simple to analyze, requiring tracing events through Tkinter and Tk and possibly lower-layer OS X APIs. It often helps to eliminate Python and Tkinter from the equation by trying to reproduce the problem with equivalent Tcl code in the Tcl/Tk wish shell if anyone feels up to it. ---------- stage: -> needs patch title: Key presses are doubled in Tkinter dialog invoked from window close handler (OS X only) -> Key presses are doubled in Tkinter dialog invoked from window close handler with Cocoa Tk versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 17:37:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 16:37:47 +0000 Subject: [issue21717] Exclusive mode for ZipFile and TarFile In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za> Message-ID: <1423240667.42.0.338282805327.issue21717@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch for zipfile. ---------- Added file: http://bugs.python.org/file38027/zipfile_mode_x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 18:01:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Feb 2015 17:01:48 +0000 Subject: [issue23399] venv should create relative symlinks where possible In-Reply-To: <1423180981.46.0.156182357728.issue23399@psf.upfronthosting.co.za> Message-ID: <20150206170126.39298.51655@psf.io> Roundup Robot added the comment: New changeset 6b8d95c12eaf by Barry Warsaw in branch '3.4': Issue #23399: pyvenv creates relative symlinks where possible. https://hg.python.org/cpython/rev/6b8d95c12eaf New changeset 9e6f79495e0b by Barry Warsaw in branch 'default': Issue #23399: pyvenv creates relative symlinks where possible. https://hg.python.org/cpython/rev/9e6f79495e0b New changeset 7a82b1539401 by Barry Warsaw in branch '3.4': Issue #23399: pyvenv creates relative symlinks where possible. https://hg.python.org/cpython/rev/7a82b1539401 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 18:04:11 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 06 Feb 2015 17:04:11 +0000 Subject: [issue23399] venv should create relative symlinks where possible In-Reply-To: <1423180981.46.0.156182357728.issue23399@psf.upfronthosting.co.za> Message-ID: <1423242251.54.0.826184379008.issue23399@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 18:33:51 2015 From: report at bugs.python.org (Chris Rebert) Date: Fri, 06 Feb 2015 17:33:51 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1423244031.49.0.470452177925.issue23342@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 19:21:40 2015 From: report at bugs.python.org (Adam) Date: Fri, 06 Feb 2015 18:21:40 +0000 Subject: [issue23402] dynload_shlib does not close ldl handles when the interpreter is shut down Message-ID: <1423246900.58.0.18702391948.issue23402@psf.upfronthosting.co.za> New submission from Adam: I think dynload_shlib (and maybe some of the other non-ldl dynamic library loaders?) should close the libraries when the interpreter is shut down. Currently the handles are not ever closed and in ldl's case sometimes leaked. The reason I desire this behavior is I have Python opening a shared library that I also open (all within the same process), and I want to be able to reload the library at runtime (via dlclose() + dlopen()) by shutting down the Python interpreter, dlclose()/dlopen(), and re-starting Python on the other side, however having the hanging reference to the library within the interpreter is preventing my dlclose() call from unloading the library. I have attached a patch for dynload_shlib.c that tracks all handles returned by dlopen() and will close them properly when the interpreter is shut down. ---------- components: Interpreter Core files: python-dlopen.diff keywords: patch messages: 235490 nosy: Adam priority: normal severity: normal status: open title: dynload_shlib does not close ldl handles when the interpreter is shut down type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file38028/python-dlopen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 19:32:56 2015 From: report at bugs.python.org (Alecz) Date: Fri, 06 Feb 2015 18:32:56 +0000 Subject: [issue7936] sys.argv contains only scriptname In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za> Message-ID: <1423247576.02.0.670180511342.issue7936@psf.upfronthosting.co.za> Alecz added the comment: I ran into this issue by doing the following steps, though I did not try to reproduce: 1 - install Python 3.4 2 - have windows Always Open .py files with Python 3 - install Python 2.7 Then I encountered issues where all .py scripts were opened with Python 2.7. After some unsuccessful attempts I decided to uninstall Python 2.7 4 - remove Python 2.7 At this point, I had to update the file associations because Windows could not find Python 2.7 anymore 5 - update file associations The issue is obviously that in at least a few places in the registry, the ..\shell\open\command has a value of ..\python.exe "%1" In my case it was under all roots: HKEY_CLASSES_ROOT\py_auto_file HKEY_LOCAL_MACHINE HKEY_USERS I corrected only the one under HKEY_USERS by adding %* and it resolved the issue. ---------- nosy: +Alecz versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 19:47:38 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 06 Feb 2015 18:47:38 +0000 Subject: [issue7936] sys.argv contains only scriptname In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za> Message-ID: <1423248458.5.0.236015430431.issue7936@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Alecz are you aware of the Python launcher, see https://www.python.org/dev/peps/pep-0397/ and https://docs.python.org/3/using/windows.html#python-launcher-for-windows ? The easiest way to sort out 3.4 would have been to download the msi file and use the repair option. Having said that I've no idea whether or not this issue can be sorted out, or is already sorted in 3.5. @Steve, Zach or Tim, over to you :) ---------- components: +Windows -Library (Lib) nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware versions: +Python 3.5 -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 19:57:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 18:57:34 +0000 Subject: [issue23401] Add pickle support of Mapping views In-Reply-To: <1423216735.87.0.773240969368.issue23401@psf.upfronthosting.co.za> Message-ID: <1423249054.74.0.293007856897.issue23401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, and yet one option: 5) As a list or a tuple. `copyreg.__newobj__, (list,), None, iter(self._mapping.keys())` or `copyreg.__newobj__, (tuple, tuple(self._mapping))`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 21:09:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 20:09:25 +0000 Subject: [issue10717] Multiprocessing module cannot call instance methods across processes In-Reply-To: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za> Message-ID: <1423253365.16.0.344001628553.issue10717@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this issue should be closed as "won't fix". In Python 3 both Pickler implementations have dispatch_table, but in Python 2 there is no way to use private dispatch table. The solution is to migrate to Python 3. ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 21:31:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 20:31:18 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1423254678.09.0.741531519659.issue15535@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is left to do with this issue? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 21:40:15 2015 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 06 Feb 2015 20:40:15 +0000 Subject: [issue20413] Errors in documentation of standard codec error handlers In-Reply-To: <1390855266.06.0.0688884977578.issue20413@psf.upfronthosting.co.za> Message-ID: <1423255215.4.0.08591414016.issue20413@psf.upfronthosting.co.za> Matthew Barnett added the comment: The docs for Python 3.5.0a0 still say "Unicode Private Use Area". ---------- nosy: +mrabarnett versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 22:11:44 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 06 Feb 2015 21:11:44 +0000 Subject: [issue18620] multiprocessing page leaves out important part of Pool example In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za> Message-ID: <1423257104.72.0.935581386583.issue18620@psf.upfronthosting.co.za> Davin Potts added the comment: Attached are proposed patches for 2.7, 3.4, and default (3.5) branches. In these patches, the 2 examples in the documentation that showcase the use of pool.apply_async have been modified to specifically highlight that a single invocation of apply_async will only lead to a single process doing any work (not all of the pool's processes). Specifically, in the first code example: * In the 3.x branches, the example is expanded slightly to demonstrate that only a single process is used by a single apply_async call and that to accomplish similar to the mapping examples just above it, multiple apply_async calls are necessary. * Also in the 3.x branches, the code deliberately causes an exception to be raised which will terminate the execution of this example when anyone attempts to run it. Rather than provide an example which terminates prematurely, the exception is now caught and a message displayed to demonstrate the exception did indeed occur, permitting the example to run through to a successful exit. * In the 2.7 branch, this first example is much smaller than what is in use in the 3.x branches -- I've expanded it to cover the same information as is being shared in the 3.x branches now. Specifically, in the second code example: * In the 3.x branches, the only change is to the comment to the right of the apply_async call which emphasizes that only a single process is being used. Also, for clarity, the reference to the exception being raised in the last line was changed to highlight that it's an exception defined in the multiprocessing library (multiprocessing.TimeoutError). * The 2.7 branch is the same -- there were no other differences on this example between branches. These updated examples have been tested with the latest from 2.7, 3.4, and default/3.5 branches on OSX 10.10 and Windows 7. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file38029/issue18620_py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 22:13:45 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 06 Feb 2015 21:13:45 +0000 Subject: [issue18620] multiprocessing page leaves out important part of Pool example In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za> Message-ID: <1423257225.76.0.513230417637.issue18620@psf.upfronthosting.co.za> Changes by Davin Potts : Added file: http://bugs.python.org/file38030/issue18620_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 22:14:09 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 06 Feb 2015 21:14:09 +0000 Subject: [issue18620] multiprocessing page leaves out important part of Pool example In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za> Message-ID: <1423257249.34.0.629401866328.issue18620@psf.upfronthosting.co.za> Changes by Davin Potts : Added file: http://bugs.python.org/file38031/issue18620_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 22:28:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 21:28:18 +0000 Subject: [issue23403] Use pickle protocol 4 by default? Message-ID: <1423258098.35.0.366066771775.issue23403@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Why not use pickle protocol 4 by default? It allows to pickle some objects which are not pickleable with lower protocols and is more efficient. ---------- components: Library (Lib) messages: 235498 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Use pickle protocol 4 by default? type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 22:43:51 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Feb 2015 21:43:51 +0000 Subject: [issue23403] Use pickle protocol 4 by default? In-Reply-To: <1423258098.35.0.366066771775.issue23403@psf.upfronthosting.co.za> Message-ID: <1423259031.76.0.755751596683.issue23403@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Because pickles will not be compatible with Python < 3.4 anymore. People who want maximum efficiency without compatibility can pass the right protocol manually. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 22:44:08 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 06 Feb 2015 21:44:08 +0000 Subject: [issue20413] Errors in documentation of standard codec error handlers In-Reply-To: <1390855266.06.0.0688884977578.issue20413@psf.upfronthosting.co.za> Message-ID: <1423259048.46.0.514458591799.issue20413@psf.upfronthosting.co.za> Martin Panter added the comment: I changed ?code point in the Unicode Private Use Area? to ?individual surrogate code? in the ?codecs? module documentation for Issue 19548. So perhaps (a) still needs addressing, but (b) and (c) are hopefully already fixed. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 23:12:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 22:12:31 +0000 Subject: [issue23403] Use pickle protocol 4 by default? In-Reply-To: <1423258098.35.0.366066771775.issue23403@psf.upfronthosting.co.za> Message-ID: <1423260751.43.0.73706125802.issue23403@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Multiprocessing uses default protocol and there is no simple (without hacking the stdlib) way to pass the right protocol manually. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 23:19:14 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Feb 2015 22:19:14 +0000 Subject: [issue23403] Use pickle protocol 4 by default? In-Reply-To: <1423258098.35.0.366066771775.issue23403@psf.upfronthosting.co.za> Message-ID: <1423261154.33.0.0199959693397.issue23403@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Multiprocessing uses default protocol AFAIK, this is so you can interact with processes using another version of Python. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 23:27:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 06 Feb 2015 22:27:25 +0000 Subject: [issue4727] copyreg doesn't support keyword only arguments in __new__ In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za> Message-ID: <1423261645.82.0.925749057434.issue4727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. ---------- keywords: +patch nosy: +serhiy.storchaka stage: needs patch -> patch review versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file38032/copy_getnewargs_ex.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 23:40:33 2015 From: report at bugs.python.org (Erik Bray) Date: Fri, 06 Feb 2015 22:40:33 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <1423262433.53.0.169110170696.issue23400@psf.upfronthosting.co.za> Changes by Erik Bray : ---------- nosy: +erik.bray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 23:43:28 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 06 Feb 2015 22:43:28 +0000 Subject: [issue23403] Use pickle protocol 4 by default? In-Reply-To: <1423258098.35.0.366066771775.issue23403@psf.upfronthosting.co.za> Message-ID: <1423262608.46.0.905663206792.issue23403@psf.upfronthosting.co.za> Josh Rosenberg added the comment: multiprocessing spawns the other processes itself from the same executable used to launch the main process. It's not subprocess. How would a different version of Python get involved? ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 6 23:46:05 2015 From: report at bugs.python.org (Vinson Lee) Date: Fri, 06 Feb 2015 22:46:05 +0000 Subject: [issue23404] Python 3.5 does not build with Python 2.6. Message-ID: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> New submission from Vinson Lee: Is there a minimum Python requirement to build Python? Python 3.5 does not build with Python 2.6. Python 3.4, Python 3.3, and Python 2.7 build with Python 2.6 so this is recent change in build requirements. For example, this build failure occurs on CentOS 6. python ./Parser/asdl_c.py -h Include ./Parser/Python.asdl Traceback (most recent call last): File "./Parser/asdl_c.py", line 6, in import asdl File "Parser/asdl.py", line 36 builtin_types = {'identifier', 'string', 'bytes', 'int', 'object', 'singleton'} ^ SyntaxError: invalid syntax ---------- components: Build messages: 235505 nosy: vlee priority: normal severity: normal status: open title: Python 3.5 does not build with Python 2.6. type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 01:01:07 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 07 Feb 2015 00:01:07 +0000 Subject: [issue20413] Errors in documentation of standard codec error handlers In-Reply-To: <1390855266.06.0.0688884977578.issue20413@psf.upfronthosting.co.za> Message-ID: <1423267267.86.0.268809880216.issue20413@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, February 2014, many of my plans went in rather different directions than expected that month, and this was one of them :) As Martin noted, he already fixed (b) and (c), but we missed that the list of error handlers was also duplicated in the builtin open() docs. That duplication is likely worthwhile from a docs usability perspective, but we should: 1. Bring it in line with Martin's recent fixes to the codecs module docs 2. Add a comment in the error handler docs noting that the open() docs may need to be updated to reflect changes to error handler semantics ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 02:39:40 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Feb 2015 01:39:40 +0000 Subject: [issue23403] Use pickle protocol 4 by default? In-Reply-To: <1423258098.35.0.366066771775.issue23403@psf.upfronthosting.co.za> Message-ID: <1423273180.42.0.994463133522.issue23403@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It is possible to have independent processes communicate together, although that's not the most widely-used feature. See: https://docs.python.org/3/library/multiprocessing.html#multiprocessing-listeners-clients Also: https://docs.python.org/3/library/multiprocessing.html#managers ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 03:44:56 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 07 Feb 2015 02:44:56 +0000 Subject: [issue23404] Python 3.5 does not build with Python 2.6. In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1423277096.29.0.922542709363.issue23404@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Looks like this revision, part of #22823, changed it: https://hg.python.org/cpython/rev/4480506137ed ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 03:51:31 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 07 Feb 2015 02:51:31 +0000 Subject: [issue23404] Python 3.5 does not build with Python 2.6. In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1423277491.8.0.810374466201.issue23404@psf.upfronthosting.co.za> Josh Rosenberg added the comment: To answer your question: Since asdl uses set literals (introduced in 2.7 and 3.0), that appears to put an effective minimum version requirement of 2.7 to build 3.5. Whether that was the intent is unclear (they were changing a lot of places from set([a, b, c]) to {a, b, c}; causing problems building Python was probably not the intent, but 2.6 is well out of support at this point). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 04:21:27 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 07 Feb 2015 03:21:27 +0000 Subject: [issue23404] Python 3.5 does not build with Python 2.6. In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1423279287.76.0.0331626135629.issue23404@psf.upfronthosting.co.za> Ned Deily added the comment: Try using "make touch" before "make". Because hg does not preserve precise time stamps when creating working directories, some build steps are run unnecessarily after an initial checkout. 'make touch' updates the file time stamps so that these steps are skipped and a "bootstrap" Python is not needed. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 04:23:14 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 07 Feb 2015 03:23:14 +0000 Subject: [issue23404] Python 3.5 does not build with Python 2.6. In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1423279394.89.0.984657699941.issue23404@psf.upfronthosting.co.za> Ned Deily added the comment: https://docs.python.org/devguide/setup.html#avoiding-re-creating-auto-generated-files ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 04:25:15 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 07 Feb 2015 03:25:15 +0000 Subject: [issue23404] Python 3.5 does not build with Python 2.6. In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1423279515.89.0.850343419286.issue23404@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 04:48:46 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 07 Feb 2015 03:48:46 +0000 Subject: [issue23117] Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall In-Reply-To: <1419634984.21.0.96201874002.issue23117@psf.upfronthosting.co.za> Message-ID: <1423280926.96.0.307485029669.issue23117@psf.upfronthosting.co.za> Ned Deily added the comment: Using code signing on OS X sounds like a good idea but does require careful analysis to ensure it is being used correctly. However, in your example, you are using and signing the Apple-supplied system Python. It is not advisable to modify system resources like that. You should open an issue with Apple to request the system Pythons be signed (https://bugreport.apple.com/). I'll keep this issue open for further investigation of signing of Pythons supplied by python.org installers for OS X. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 05:15:31 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 07 Feb 2015 04:15:31 +0000 Subject: [issue23403] Use pickle protocol 4 by default? In-Reply-To: <1423258098.35.0.366066771775.issue23403@psf.upfronthosting.co.za> Message-ID: <1423282531.68.0.418334648503.issue23403@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 07:17:20 2015 From: report at bugs.python.org (Vinson Lee) Date: Sat, 07 Feb 2015 06:17:20 +0000 Subject: [issue23404] Python 3.5 does not build with Python 2.6. In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1423289840.2.0.298138573877.issue23404@psf.upfronthosting.co.za> Vinson Lee added the comment: I am building from a git copy of the source repository. "make touch" before "make" does not work for me. $ make touch cd .; \ hg --config extensions.touch=Tools/hg/hgtouch.py touch -v abort: There is no Mercurial repository here (.hg not found)! I've attached a patch that addresses the Python 3.5 build issue for me. The patch contains two syntax construct changes to Parser/asdl.py. Please consider applying this patch upstream. ---------- keywords: +patch status: closed -> open Added file: http://bugs.python.org/file38033/0001-Issue-23404-Do-not-use-Python-2.7-constructs-in-Pars.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 07:34:43 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 07 Feb 2015 06:34:43 +0000 Subject: [issue23404] 'make touch' does not work with git clones of the source repository In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1423290883.33.0.894114231645.issue23404@psf.upfronthosting.co.za> Ned Deily added the comment: Unfortunately, those syntax differences aren't the only problems you could run into so making these syntax changes isn't really a general solution, IMO. 'make touch' is the documented and supported way to ensure that the unnecessary build steps are not run. But, as you discovered, 'make touch' only works with an hg copy of the repo; it was not designed for git clones. To fully support git clones, there would need to be a git equivalent of the hg scripts called by 'make touch'. This would be a worthwhile project for someone interested in git support to work on and would be considered for inclusion in the repo. ---------- components: +Devguide nosy: +ezio.melotti resolution: not a bug -> stage: resolved -> needs patch title: Python 3.5 does not build with Python 2.6. -> 'make touch' does not work with git clones of the source repository type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 07:52:52 2015 From: report at bugs.python.org (Vinson Lee) Date: Sat, 07 Feb 2015 06:52:52 +0000 Subject: [issue23404] 'make touch' does not work with git clones of the source repository In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1423291972.64.0.865903533193.issue23404@psf.upfronthosting.co.za> Vinson Lee added the comment: With the supplied patch on CentOS 6 , "make" passes and "make test" passes with the exception of test_readline that is Issue19884. 372 tests OK. 1 test failed: test_readline 7 tests altered the execution environment: test_calendar test_distutils test_float test_locale test_strptime test_types test_warnings 11 tests skipped: test_devpoll test_gdb test_kqueue test_msilib test_ossaudiodev test_startfile test_tk test_ttk_guionly test_winreg test_winsound test_zipfile64 Re-running failed tests in verbose mode Re-running test 'test_readline' in verbose mode testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok test_write_read_append (test.test_readline.TestHistoryManipulation) ... ok test_init (test.test_readline.TestReadline) ... FAIL ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 08:08:18 2015 From: report at bugs.python.org (Vinson Lee) Date: Sat, 07 Feb 2015 07:08:18 +0000 Subject: [issue23404] 'make touch' does not work with git clones of the source repository In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1423292898.7.0.306078980856.issue23404@psf.upfronthosting.co.za> Vinson Lee added the comment: I tried a hg copy of the repository. "make touch" worked for me. ./configure make touch make ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 09:23:30 2015 From: report at bugs.python.org (Daniil Bondarev) Date: Sat, 07 Feb 2015 08:23:30 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423297410.77.0.159135688375.issue17911@psf.upfronthosting.co.za> Daniil Bondarev added the comment: As suggested adding patch from http://bugs.python.org/issue2786 which prints qualnames in function call exceptions. e.g: >>> class A: ... def __init__(self): ... pass >>> A(1) Traceback (most recent call last): File "", line 1, in TypeError: A.__init__() takes 1 positional argument but 2 were given ---------- nosy: +xonatius Added file: http://bugs.python.org/file38034/qualname_in_exceptions.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 11:48:02 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 07 Feb 2015 10:48:02 +0000 Subject: [issue23405] Tools/freeze "make" gets missing file error with unix shared builds Message-ID: <1423306082.41.0.550476230992.issue23405@psf.upfronthosting.co.za> New submission from Ned Deily: While investigating another freeze-related issue, I found that Tools/freeze seems to not work when used with an installed shared unix build. The symptom is that the linkage step in the freeze-produced Makefile fails with: gcc -pthread -Xlinker -export-dynamic config.o frozen.o M___future__.o [...] M_zipfile.o /py/3x/unix/root/lib/python3.4/config-3.4dm/libpython3.4dm.so -lpthread -ldl -lutil -lm -o hello gcc: error: /py/3x/unix/root/f/../lib/python3.4/config-3.4dm/libpython3.4dm.so: No such file or directory Makefile:505: recipe for target 'hello' failed make: *** [hello] Error 1 The problem is that the freeze linkage step is looking for the python library with a shared library extension (in this case, '.so') in the config-3.xmm directory but the library is installed as a static archive ('.a') there: ./lib/python3.4/config-3.4dm/libpython3.4dm.a I'm unfamiliar with freeze and its history but it looks like the problem was introduced by the changes for Issue11824, in particular this: - libs = [os.path.join(binlib, 'libpython$(VERSION).a')] + libs = [os.path.join(binlib, '$(LDLIBRARY)')] The Python Makefile target "libainstall" installs the Python library in the config* dir: @if test -d $(LIBRARY); then :; else \ if test "$(PYTHONFRAMEWORKDIR)" = no-framework; then \ if test "$(SHLIB_SUFFIX)" = .dll; then \ $(INSTALL_DATA) $(LDLIBRARY) $(DESTDIR)$(LIBPL) ; \ else \ $(INSTALL_DATA) $(LIBRARY) $(DESTDIR)$(LIBPL)/$(LIBRARY) ; \ $(RANLIB) $(DESTDIR)$(LIBPL)/$(LIBRARY) ; \ fi; \ else \ echo Skip install of $(LIBRARY) - use make frameworkinstall; \ fi; \ fi So, if I understand the cases correctly, for non-".dll" cases, the library is installed in the config* directory as file name $LIBRARY. But the changed code in the freeze-generated Makefile looks for the library as $LDLIBRARY. For static Python builds, $LIBRARY and $LDLIBRARY are (always?) the same, but for shared builds, they are (usually) not, for example: LDLIBRARY = "libpython3.4dm.so" LIBRARY = "libpython3.4dm.a" I'm not sure what the complete solution should be but clearly what is there now is not right for shared unix builds. ---------- components: Demos and Tools messages: 235518 nosy: lemburg, loewis, meador.inge, ned.deily priority: normal severity: normal stage: needs patch status: open title: Tools/freeze "make" gets missing file error with unix shared builds versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 11:57:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Feb 2015 10:57:48 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <20150207105745.108393.96270@psf.io> Roundup Robot added the comment: New changeset 751910294200 by Vinay Sajip in branch 'default': Closes #23357: Updated documentation on creating venvs. https://hg.python.org/cpython/rev/751910294200 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 13:55:26 2015 From: report at bugs.python.org (Abraham Smith) Date: Sat, 07 Feb 2015 12:55:26 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior Message-ID: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> New submission from Abraham Smith: Some students were working on matrix routines for practice. The following code: >>> L = [ [0]*3 ]*3 >>> for i in range(3): ... for j in range(3): ... if i==j: L[i][j]=1 was expected to return [[1,0,0],[0,1,0],[0,0,1]] but it returned [[1,1,1],[1,1,1],[1,1,1]] because the list [0]*3 was being interned silently, so all three rows were the same memory! To see this, I did >>> map(id, L) [139634871681464, 139634871681464, 139634871681464] On the other hand >>> M=[ [ 0 for i in range(3) ] for j in range(3) ] does not intern: >>> map(id, L) [139634871631672, 139634871681608, 139634871681680] so the above loop works as expected. This is true in both python 2.7 and 3.4. This is very confusing to users! If this intern behavior with [0]*3 is intended, it should be documented more clearly, because this is something that new students of python might encounter right away when playing with the language's list methods. I didn't see any reference to interning in the discussion of lists in the standard library reference. Moreover, I also could not find any reference to the automatic interning of mutable objects, such as lists. Personally, I cannot see any reason to silently and automatically intern a mutable object; however, if this behavior is really desired, it should be documented. ---------- assignee: docs at python components: Documentation messages: 235520 nosy: Abraham.Smith, docs at python priority: normal severity: normal status: open title: interning and list comprehension leads to unexpected behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 13:59:11 2015 From: report at bugs.python.org (Abraham Smith) Date: Sat, 07 Feb 2015 12:59:11 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1423313951.05.0.84342964966.issue23406@psf.upfronthosting.co.za> Abraham Smith added the comment: (Obviously, there's a copy/paste mistake in the second case; it should read map(id, M).) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 14:07:57 2015 From: report at bugs.python.org (Karl Richter) Date: Sat, 07 Feb 2015 13:07:57 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> Message-ID: <1423314477.22.0.394127066764.issue23174@psf.upfronthosting.co.za> Karl Richter added the comment: For example, it should be clear why `shelve.open(tempfile.mkstemp()[1])` fails with the mentioned exception and `shelve.open("/tmp/bla")` fails. I still haven't figured out the constraints to create a working `shelve.Shelve` at all. It should be clear why `shelve.open("/tmp/tmphTTQLd")` fails and `shelve.open("/tmp/tmphTTQLda")` succeeds. There has to be something unrelated to extensions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 14:10:34 2015 From: report at bugs.python.org (Georg Brandl) Date: Sat, 07 Feb 2015 13:10:34 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1423314634.57.0.785233327604.issue23406@psf.upfronthosting.co.za> Georg Brandl added the comment: There is no interning going on. Multiplying lists just copies references. This is not so surprising if you consider that the case may be simple for nested lists, but what about ``[a] * 3`` with some arbitrary object "a"? Copying (or even deep copying) that object is usually not wanted, and impossible in general. This is also documented here (see especially note 2 below the table): https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unicode-list-tuple-bytearray-buffer-xrange You're right though that this might be good to mention in the tutorial, as it comes up every now and then. I'll leave the issue open to discuss that. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 14:20:24 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 07 Feb 2015 13:20:24 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1423315224.84.0.0963274643597.issue23406@psf.upfronthosting.co.za> Steven D'Aprano added the comment: This is already a FAQ: https://docs.python.org/2/faq/programming.html#how-do-i-create-a-multidimensional-list I guess this bites every beginning Python programmer, but it's a natural, and desirable, consequence of Python's object model and the fact that * does not copy the list items. ---------- nosy: +steven.daprano resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 14:29:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Feb 2015 13:29:32 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <20150207132929.51378.6431@psf.io> Roundup Robot added the comment: New changeset 5b63010be19e by Charles-Fran?ois Natali in branch 'default': Issue #23285: PEP 475 -- Retry system calls failing with EINTR. https://hg.python.org/cpython/rev/5b63010be19e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 14:37:06 2015 From: report at bugs.python.org (Abraham Smith) Date: Sat, 07 Feb 2015 13:37:06 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1423316226.64.0.0375582141005.issue23406@psf.upfronthosting.co.za> Abraham Smith added the comment: Thanks for the helpful responses and correcting my misunderstanding. Regarding improved documentation, I see now that the table at https://docs.python.org/2/library/stdtypes.html#id2 indeed says "shallow copies"; however, the footnote seems to bury the lede. Perhaps the footnote should be expanded to either link to the FAQ entry or provide an abbreviated version of it. The FAQ entry is actually very good, but I would guess that most readers (like me) skip the FAQs and jump straight to the library reference. Internet users have been trained for 20 years to believe that FAQs are full of useless, snarky answers to questions at a much shallower level, like "what do I do with a .tar.gz file?". The fact that Python's FAQ is extremely well-written and helpful is a pleasant surprise, but a surprise none-the-less. ---------- resolution: not a bug -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 14:58:17 2015 From: report at bugs.python.org (Karl Richter) Date: Sat, 07 Feb 2015 13:58:17 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> Message-ID: <1423317497.47.0.61265471169.issue23174@psf.upfronthosting.co.za> Karl Richter added the comment: After checking the code, I think that it'd make more sense to document `whichdb.py`. It needs to be enhanced with references to criteria for the determination of the database type. Currently there're only function comments and the fact that some variables are named magic speaks for itself, i.e. it's ok for the implementation of the module to be a black box, but the requirements for the input, i.e. the potential database file, which is per se not part of the black box, needs to be specified. Then just link that in the `shelve` docs stating that `shelve.open` is basically a wrapper around `whichdb`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 16:29:18 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 07 Feb 2015 15:29:18 +0000 Subject: [issue21502] freeze.py not working properly with OS X framework builds In-Reply-To: <1400026292.27.0.150943565159.issue21502@psf.upfronthosting.co.za> Message-ID: <1423322958.76.0.15384517616.issue21502@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, I've finally gotten around to taking a longer look at this and it seems that freeze support is kind of a mess. First, it looks like some of the issues you ran into were fixed in 3.4.1 (changes associated with Issue11824 and Issue16047). Unfortunately, one of them introduced a new problem that I've documented in Issue23405 (and which can be worked around by editing the freeze Makefile to use $(LIBRARY) instead of $(LDLIBRARY)). But there appear to be still more basic problems when trying to use freeze with OS X framework builds such as provided by the python.org installers for OS X. 1. freeze makes use of the LINKFORSHARED configuration variable when building the frozen executable. For OS X non-framework Python builds, it typically looks like this: LINKFORSHARED="-Wl,-stack_size,1000000 -framework CoreFoundation" For framework builds, it also includes the relative framework file path: LINKFORSHARED="-Wl,-stack_size,1000000 -framework CoreFoundation Python.framework/Versions/3.4/Python" The path is not useful as-is outside of the Python build itself and, by having a path here, the OS X framework configuration seems to be an exception to most other platforms, causing problems here with freeze and elsewhere (there have been other complaints about this usage). As noted, one can workaround this problem by editing the freeze-produced Makefile. But that leads to another problem. 2. Unlike for non-shared and shared Python builds, OS X Python framework builds do not include the Python library as a static archive file in the config-* directory (or anywhere else for that matter). Instead, symbolic links are created in the directory to the framework shared library. shared build $ ls -l ./lib/python3.4/config-3.4dm/lib* -rw-r-----+ 1 nad pyd 9514552 Feb 7 16:57 libpython3.4dm.a framework build $ ls -l ./lib/python3.4/config-3.4dm/lib* lrwxr-x--- 1 nad pyd 21 Feb 7 17:41 libpython3.4.a -> ../../../Python lrwxr-x--- 1 nad pyd 21 Feb 7 17:41 libpython3.4.dylib -> ../../../Python lrwxr-x--- 1 nad pyd 21 Feb 7 17:41 libpython3.4dm.a -> ../../../Python lrwxr-x--- 1 nad pyd 21 Feb 7 17:41 libpython3.4dm.dylib -> ../../../Python This difference causes problems when linking the frozen executable: because the framework build configuration presents a dynamic shared lib, the resulting executable has a runtime dependency on the shared lib: % otool -L hello hello: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1152.0.0) /Library/Frameworks/Python.framework/Versions/3.4/Python (compatibility version 3.4.0, current version 3.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) and the frozen executable cannot be run on another system which does not have a compatible version of Python installed. I don't know of an easy freeze build workaround for this. I think the correct solution for freeze is to always only provide the static library in the config* directory for all Python build configurations. But I'm not sure whether there are any compelling reasons to provide shared lib links as well for other users of the config* directory (e.g. for embedding Python); if so, the static and dynamic libs may have to have distinct names. Ronald, do you have other thoughts on this? At the moment, I think the safest solution for using freeze on OS X is to use a non-shared, non-framework build of Python, which probably means building Python 3.4 yourself. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 16:33:26 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 07 Feb 2015 15:33:26 +0000 Subject: [issue21502] freeze.py not working properly with OS X framework builds In-Reply-To: <1400026292.27.0.150943565159.issue21502@psf.upfronthosting.co.za> Message-ID: <1423323206.01.0.400714604619.issue21502@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 19:26:13 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 07 Feb 2015 18:26:13 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <1423333573.64.0.561003252169.issue23400@psf.upfronthosting.co.za> Davin Potts added the comment: Having installed a fresh copy of Debian Hurd into a VM, I am able to reproduce the described issue using this 2-line snippet of code: import multiprocessing q = multiprocessing.Queue() It was possible to reproduce the issue both using the builds of 2.7.9 and 3.4.2 that came with Debian Hurd and with clean builds of each from the Python source code for those releases. Although already described in the original issue report, I'm taking the venerable astropy package out of the picture with this bare-bones provocation of the issue here. So running the above code snippet with 2.7.9 produces an ImportError and with 3.4.2 produces an AttributeError (details of error message are as previously described). I agree that the behavior should be consistent between 2.7 and 3.x -- I'm leaning towards the consistent use of ImportError because that is what's used when threading support isn't available on a platform (i.e. 'import thread' or 'import threading' fails with an ImportError there). As to where this should be documented in the documentation itself so that readers have a hope of finding it... that requires a bit more thought but I agree that it should be noted in the documentation. Thinking in pragmatic terms, most folks will probably not read the docs and instead notice it at the time of the failing import so the error message should be clear and consistent there. It does not look like there is a working implementation of sem_open() on Debian Hurd yet -- is that correct? Otherwise there's another more attractive potential fix for this. ---------- nosy: +davin stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 21:35:40 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 07 Feb 2015 20:35:40 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <1423341340.0.0.35406942085.issue23400@psf.upfronthosting.co.za> Davin Potts added the comment: Apologies -- it was already pointed out that there is no sem_open implementation on Hurd. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 21:59:23 2015 From: report at bugs.python.org (Craig Holmquist) Date: Sat, 07 Feb 2015 20:59:23 +0000 Subject: [issue23407] os.walk always follows Windows junctions Message-ID: <1423342763.81.0.179122512075.issue23407@psf.upfronthosting.co.za> New submission from Craig Holmquist: os.walk follows Windows junctions even if followlinks is False: >>> import os >>> appdata = os.environ['LOCALAPPDATA'] >>> for root, dirs, files in os.walk(appdata, followlinks=False): ... print(root) C:\Users\Test\AppData\Local C:\Users\Test\AppData\Local\Apple C:\Users\Test\AppData\Local\Apple\Apple Software Update C:\Users\Test\AppData\Local\Apple Computer C:\Users\Test\AppData\Local\Apple Computer\iTunes C:\Users\Test\AppData\Local\Application Data C:\Users\Test\AppData\Local\Application Data\Apple C:\Users\Test\AppData\Local\Application Data\Apple\Apple Software Update C:\Users\Test\AppData\Local\Application Data\Apple Computer C:\Users\Test\AppData\Local\Application Data\Apple Computer\iTunes C:\Users\Test\AppData\Local\Application Data\Application Data C:\Users\Test\AppData\Local\Application Data\Application Data\Apple C:\Users\Test\AppData\Local\Application Data\Application Data\Apple\Apple Software Update C:\Users\Test\AppData\Local\Application Data\Application Data\Apple Computer C:\Users\Test\AppData\Local\Application Data\Application Data\Apple Computer\iTunes C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Apple C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Apple\Apple Software Update C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Apple Computer C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Apple Computer\iTunes C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Application Data [...] For directory symbolic links, os.walk seems to have the correct behavior. However, Windows 7 (at least) employs junctions instead of symlinks in situations like the default user profile layout, i.e. the "Application Data" junction shown above. I also noticed that, for junctions, os.path.islink returns False but os.stat and os.lstat return different results. ---------- components: Library (Lib) messages: 235531 nosy: craigh priority: normal severity: normal status: open title: os.walk always follows Windows junctions type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 7 22:43:16 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 07 Feb 2015 21:43:16 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1423345396.38.0.272279772132.issue23285@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 00:34:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Feb 2015 23:34:38 +0000 Subject: [issue22364] Improve some re error messages using regex for hints In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1423352078.1.0.649580556871.issue22364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which unify and improves re error messages. Added tests for all parsing errors. Now error message always points on the start of affected component, i.e. on the start of bad escape, group name or unterminated subpattern. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file38035/re_errors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 00:36:37 2015 From: report at bugs.python.org (eryksun) Date: Sat, 07 Feb 2015 23:36:37 +0000 Subject: [issue23407] os.walk always follows Windows junctions In-Reply-To: <1423342763.81.0.179122512075.issue23407@psf.upfronthosting.co.za> Message-ID: <1423352197.62.0.262781162113.issue23407@psf.upfronthosting.co.za> eryksun added the comment: To check for a link on Windows, os.walk calls ntpath.islink, which calls os.lstat. Currently the os.lstat implementation only sets S_IFLNK for symbolic links. attribute_data_to_stat could also check for junctions (IO_REPARSE_TAG_MOUNT_POINT). For consistency, os.readlink should also read junctions (rdb->MountPointReparseBuffer). islink https://hg.python.org/cpython/file/7b493dbf944b/Lib/ntpath.py#l239 attribute_data_to_stat https://hg.python.org/cpython/file/7b493dbf944b/Modules/posixmodule.c#l1515 win_readlink https://hg.python.org/cpython/file/7b493dbf944b/Modules/posixmodule.c#l10056 REPARSE_DATA_BUFFER https://hg.python.org/cpython/file/7b493dbf944b/Modules/winreparse.h#l11 ---------- components: +Windows nosy: +eryksun, steve.dower, tim.golden, zach.ware versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 00:37:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Feb 2015 23:37:38 +0000 Subject: [issue22364] Improve some re error messages using regex for hints In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1423352258.68.0.497575999283.issue22364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: re_errors_diff.txt contains differences for all tested error messages. ---------- Added file: http://bugs.python.org/file38036/re_errors_diff.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 00:48:23 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 07 Feb 2015 23:48:23 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1423352903.09.0.640493615619.issue21354@psf.upfronthosting.co.za> Larry Hastings added the comment: Still not fixed! This has been marked as "release blocker" for most of a year. Should I just apply the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 00:50:48 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 07 Feb 2015 23:50:48 +0000 Subject: [issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32 In-Reply-To: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za> Message-ID: <1423353048.06.0.113282225859.issue22634@psf.upfronthosting.co.za> Larry Hastings added the comment: What does "-m32" mean? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 01:03:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Feb 2015 00:03:02 +0000 Subject: [issue22634] importing _ctypes failed: undefined symbol: ffi_call_win32 In-Reply-To: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za> Message-ID: <1423353782.61.0.854583086596.issue22634@psf.upfronthosting.co.za> Antoine Pitrou added the comment: "-m32" means "compile a 32-bit build though I'm on a 64-bit platform". I'm not sure why Matthias says this is "getting what you deserve", since everytime I've tried, "-m32" worked properly for building Python. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 01:03:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Feb 2015 00:03:16 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1423353796.47.0.244968307612.issue21354@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Perhaps Steve can confirm that the patch is right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 01:37:53 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 08 Feb 2015 00:37:53 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1423355873.17.0.397343950242.issue21354@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I'm sorry. The patch is correct from my perspective if we want to make bdist_install just working. Or as an option I can restore PyCFunction_New function declaration. What do you prefer? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 02:52:57 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 08 Feb 2015 01:52:57 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1423360377.49.0.586381211941.issue21354@psf.upfronthosting.co.za> Steve Dower added the comment: As Andrew says, the patch is fine for the bug, but the PyCFunction_New function is certainly part of the stable ABI and needs to be restored. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 02:57:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 01:57:22 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1423360642.81.0.584496332018.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: If it would help the review process, I could simplify my patch by dropping the addition of the HTTPConnection.closed flag, so that it just adds the ConnectionClosed exception. Looking forwards, I?m wondering if it might be better to add something like a HTTPConnection.check_remote_closed() method instead of that flag anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 03:45:29 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 02:45:29 +0000 Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments disappeared In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za> Message-ID: <1423363529.11.0.811105622961.issue23391@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch to redocument the constructor arguments. I am assuming that they were only removed by accident. The constructor arguments are already tested in ExceptionTests.testAttributes() at Lib/test/test_exceptions.py:248. I did not restore the bit about more than three arguments being reflected in the ?args? attribute, since this is not the current behaviour, and does not seem very important: >>> OSError(1, 2, 3, 4).args (1, 2) ---------- keywords: +patch Added file: http://bugs.python.org/file38037/os-error-args.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 04:02:36 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 03:02:36 +0000 Subject: [issue12304] expose signalfd(2) in the signal module In-Reply-To: <1307660456.9.0.497118052372.issue12304@psf.upfronthosting.co.za> Message-ID: <1423364556.45.0.236622446951.issue12304@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 04:05:30 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 03:05:30 +0000 Subject: [issue18885] handle EINTR in the stdlib In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za> Message-ID: <1423364730.51.0.72116280992.issue18885@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 04:36:56 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 03:36:56 +0000 Subject: [issue18885] handle EINTR in the stdlib In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za> Message-ID: <1423366616.25.0.969063284215.issue18885@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 23285 for the PEP ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 04:38:18 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 03:38:18 +0000 Subject: [issue20611] socket.create_connection() doesn't handle EINTR properly In-Reply-To: <1392218032.12.0.645790882431.issue20611@psf.upfronthosting.co.za> Message-ID: <1423366698.33.0.0288972592195.issue20611@psf.upfronthosting.co.za> Martin Panter added the comment: See also PEP 475 and Issue 23285 for the general fix in Python 3 ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 05:11:30 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 08 Feb 2015 04:11:30 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1423368690.17.0.187478529714.issue15795@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 05:43:30 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 04:43:30 +0000 Subject: [issue13637] binascii.a2b_* functions could accept unicode strings In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za> Message-ID: <1423370610.75.0.468857402808.issue13637@psf.upfronthosting.co.za> Martin Panter added the comment: The error fix patch looks good. I updated the doc patch as fix_doc_binascii_unhexlify.v2.patch, which also clarifies a2b_qp(), and restores the description of Python 3.2 not allowing text strings. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python Added file: http://bugs.python.org/file38038/fix_doc_binascii_unhexlify.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 05:49:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 08 Feb 2015 04:49:29 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <20150208044927.50327.88784@psf.io> Roundup Robot added the comment: New changeset 000bbdf0ea76 by Ned Deily in branch 'default': Issue #23285: Install new test directory. https://hg.python.org/cpython/rev/000bbdf0ea76 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 06:07:23 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 05:07:23 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1423372043.91.0.422963306889.issue21793@psf.upfronthosting.co.za> Martin Panter added the comment: Currently the log output includes the new HTTPStatus codes. I don?t care much for the log output, but perhaps this wasn?t part of the plan? Before: $ python3.4 -m http.server Serving HTTP on 0.0.0.0 port 8000 ... 127.0.0.1 - - [08/Feb/2015 05:05:28] "GET / HTTP/1.1" 200 - After: $ ./python -m http.server Serving HTTP on 0.0.0.0 port 8000 ... 127.0.0.1 - - [08/Feb/2015 05:05:40] "GET / HTTP/1.1" HTTPStatus.OK - ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 06:08:12 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 08 Feb 2015 05:08:12 +0000 Subject: [issue20680] Pickle socket enums by names In-Reply-To: <1392758039.35.0.851373733794.issue20680@psf.upfronthosting.co.za> Message-ID: <1423372092.35.0.547625608307.issue20680@psf.upfronthosting.co.za> Ethan Furman added the comment: To make sure I understand correctly: On platform ABC the value 1 could mean SOCK_STREAM but on platform XYZ SOCK_STREAM is value 32? Assuming the need to pickle socket types is not new, then people have been doing it, possibly with painful workarounds, on the integer values until now, and suddenly changing the pickle of a socket type from an integer into a string is going to break code. Or am I missing something? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 08:07:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Feb 2015 07:07:20 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1423379240.93.0.474208148296.issue21793@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 08:31:04 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 08 Feb 2015 07:31:04 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1423380664.23.0.837771691549.issue23353@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 08:34:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Feb 2015 07:34:17 +0000 Subject: [issue20680] Pickle socket enums by names In-Reply-To: <1392758039.35.0.851373733794.issue20680@psf.upfronthosting.co.za> Message-ID: <1423380857.12.0.561575585412.issue20680@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't see how it can break code. If people use workaround that were not broken by changing SOCK_STREAM from int to enum, it shouldn't break by changing pickle representation of SOCK_STREAM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 09:56:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Feb 2015 08:56:57 +0000 Subject: [issue23096] Implementation-depended pickling floats with protocol 0 In-Reply-To: <1419149433.29.0.802482425543.issue23096@psf.upfronthosting.co.za> Message-ID: <1423385817.78.0.407256355342.issue23096@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. ---------- keywords: +patch stage: -> patch review versions: -Python 2.7, Python 3.4 Added file: http://bugs.python.org/file38039/pickle_float_repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 10:05:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Feb 2015 09:05:46 +0000 Subject: [issue23408] Pickle tests use incorrect test data Message-ID: <1423386346.84.0.92397011471.issue23408@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Pickle tests use incorrect test data for protocols 0-2. This data is not compatible with Python 2 because refers to Python 3 modules builtins and copyreg (instead of __builtin__ and copy_reg). Proposed patch fixes this (data was regenerated by pythontester). Allso corrected dissassembly dumps. ---------- components: Tests files: test_pickle_data.patch keywords: patch messages: 235551 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Pickle tests use incorrect test data type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38040/test_pickle_data.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 11:13:14 2015 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 08 Feb 2015 10:13:14 +0000 Subject: [issue17896] Move Windows external libs from \..\ to \externals In-Reply-To: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za> Message-ID: <1423390394.73.0.307306320216.issue17896@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I noticed this issue today when trying to make the 3.4.3rc1 build; this broke Tools/msi.py, which fails to find the license files and the tcltk files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 11:21:17 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 10:21:17 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes Message-ID: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> New submission from Martin Panter: [Padding to avoid Error: 'utf8' codec can't decode bytes in position 189-190: invalid continuation byte] This is a patch to document two attributes of http.server.BaseHTTPRequestHandler: ?close_connection? and ?requestline?. Normally these are set by the handle_one_request() method, but when overriding that method, you need to know to set these attributes. ---------- assignee: docs at python components: Documentation messages: 235554 nosy: docs at python, vadmium priority: normal severity: normal status: open title: Document more BaseHTTPRequestHandler attributes type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 11:22:07 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 10:22:07 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes In-Reply-To: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> Message-ID: <1423390927.07.0.411986891146.issue23410@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- keywords: +patch Added file: http://bugs.python.org/file38042/http-attributes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 11:43:16 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 10:43:16 +0000 Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za> Message-ID: <1423392196.77.0.751796066492.issue3213@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 12:11:01 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 08 Feb 2015 11:11:01 +0000 Subject: [issue11734] Add half-float (16-bit) support to struct module In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za> Message-ID: <1423393861.57.0.330918952234.issue11734@psf.upfronthosting.co.za> Mark Dickinson added the comment: Refreshed and updated patch, cleaning up some style issues, fixing a failure to return -1 on exception in np_halffloat, and removing some endianness-determining casty expressions in favour of using PY_LITTLE_ENDIAN. ---------- Added file: http://bugs.python.org/file38043/cpython-struct-float16-v7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 12:38:46 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 11:38:46 +0000 Subject: [issue23411] Update urllib.parse.__all__ Message-ID: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> New submission from Martin Panter: +"DefragResult", "ParseResult", "SplitResult", +"DefragResultBytes", "ParseResultBytes", "SplitResultBytes"] Also adds test case. ---------- components: Library (Lib) files: urllib.parse-all.patch keywords: patch messages: 235556 nosy: vadmium priority: normal severity: normal status: open title: Update urllib.parse.__all__ type: behavior Added file: http://bugs.python.org/file38044/urllib.parse-all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 12:43:07 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 11:43:07 +0000 Subject: [issue23411] Update urllib.parse.__all__ In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> Message-ID: <1423395787.67.0.512751472173.issue23411@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file38045/urllib.parse-all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 12:43:17 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 08 Feb 2015 11:43:17 +0000 Subject: [issue23411] Update urllib.parse.__all__ In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> Message-ID: <1423395797.05.0.134716986072.issue23411@psf.upfronthosting.co.za> Changes by Martin Panter : Removed file: http://bugs.python.org/file38044/urllib.parse-all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 13:53:07 2015 From: report at bugs.python.org (Tim Golden) Date: Sun, 08 Feb 2015 12:53:07 +0000 Subject: [issue17023] Subprocess does not find executable on Windows if it is PATH with quotes In-Reply-To: <1359032961.6.0.0734607018969.issue17023@psf.upfronthosting.co.za> Message-ID: <1423399987.7.0.392794653135.issue17023@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 16:43:35 2015 From: report at bugs.python.org (Richard Dymond) Date: Sun, 08 Feb 2015 15:43:35 +0000 Subject: [issue23412] importlib sometimes fails to import a recently created module Message-ID: <1423410215.95.0.524604601959.issue23412@psf.upfronthosting.co.za> New submission from Richard Dymond: importlib.import_module() sometimes fails to import a module that has just been written to the filesystem, aborting with an ImportError. Example output when executing the attached file with Python 3.3 or 3.4: Wrote tmpwbzb35.py Successfully imported tmpwbzb35 Wrote tmp34c6qs.py Traceback (most recent call last): File "importerror.py", line 12, in importlib.import_module(modname) File "/home/rjd/Python/Python3.3/lib/python3.3/importlib/__init__.py", line 88, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1577, in _gcd_import File "", line 1558, in _find_and_load File "", line 1522, in _find_and_load_unlocked ImportError: No module named 'tmp34c6qs' I have been unable to reproduce this behaviour with Python 2.7 or Python 3.2. ---------- files: importerror.py messages: 235557 nosy: rjdymond priority: normal severity: normal status: open title: importlib sometimes fails to import a recently created module type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file38046/importerror.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 16:54:32 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 08 Feb 2015 15:54:32 +0000 Subject: [issue23411] Update urllib.parse.__all__ In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> Message-ID: <1423410872.55.0.075954893044.issue23411@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the tests. Reviewed the patch and looks good to me. ---------- nosy: +orsenthil stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 16:56:01 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 08 Feb 2015 15:56:01 +0000 Subject: [issue23397] PEP 431 implementation In-Reply-To: <1423124685.79.0.871732052041.issue23397@psf.upfronthosting.co.za> Message-ID: <1423410961.44.0.638718999326.issue23397@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +lregebro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 17:03:43 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 08 Feb 2015 16:03:43 +0000 Subject: [issue23412] importlib sometimes fails to import a recently created module In-Reply-To: <1423410215.95.0.524604601959.issue23412@psf.upfronthosting.co.za> Message-ID: <1423411423.06.0.0492790414415.issue23412@psf.upfronthosting.co.za> SilentGhost added the comment: Looks like some sort of race condition. Sleeping for a second before import_module seem to solve the problem. ---------- components: +Interpreter Core nosy: +SilentGhost, brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 17:22:02 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 08 Feb 2015 16:22:02 +0000 Subject: [issue23412] importlib sometimes fails to import a recently created module In-Reply-To: <1423410215.95.0.524604601959.issue23412@psf.upfronthosting.co.za> Message-ID: <1423412522.34.0.599552581608.issue23412@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 18:40:39 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 08 Feb 2015 17:40:39 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1423417239.18.0.63704743332.issue21793@psf.upfronthosting.co.za> Ethan Furman added the comment: Without having looked at the code I would guess the fix is as simple as changing a %s to a %d. Having said that, it would be nice if the name was also in the log -- something like: 127.0.0.1 - - [08/Feb/2015 05:05:28] "GET / HTTP/1.1" 200 (OK) - ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 18:43:39 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 08 Feb 2015 17:43:39 +0000 Subject: [issue20680] Pickle socket enums by names In-Reply-To: <1392758039.35.0.851373733794.issue20680@psf.upfronthosting.co.za> Message-ID: <1423417419.84.0.129037832224.issue20680@psf.upfronthosting.co.za> Ethan Furman added the comment: An IntEnum is just a fancy int. You can add them, subtract them, multiply them, all that kind of thing. If you attempt to unpickle a 3.4 _PickleByNameIntEnum on a 3.3 system, what's going to happen? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 18:53:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Feb 2015 17:53:23 +0000 Subject: [issue20680] Pickle socket enums by names In-Reply-To: <1423417419.84.0.129037832224.issue20680@psf.upfronthosting.co.za> Message-ID: <1699706.dGMkZHxU3L@raxxla> Serhiy Storchaka added the comment: > If you attempt to unpickle a 3.4 _PickleByNameIntEnum on a 3.3 system, > what's going to happen? The same as if you attempt to unpickle a 3.4 IntEnum on a 3.3 system -- AttributeError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 19:34:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Feb 2015 18:34:51 +0000 Subject: [issue23103] Reduce memory usage for ipaddress object instances In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1423420491.72.0.802121924106.issue23103@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Synchronized with tip. ---------- Added file: http://bugs.python.org/file38047/ipaddress_lightweight_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 20:13:12 2015 From: report at bugs.python.org (Martynas Brijunas) Date: Sun, 08 Feb 2015 19:13:12 +0000 Subject: [issue23413] Incorrect division result Message-ID: <1423422792.29.0.39296794097.issue23413@psf.upfronthosting.co.za> New submission from Martynas Brijunas: Dear Python team, when dividing 3 by 7, I expect to get the following result: 0.428571428571428571428571428571428571428571428571428571428571... What I am getting in the Python interpreter is this: >>> 3 / 7 0.42857142857142855 Which in my opinion is incorrect. ---------- messages: 235564 nosy: Martynas.Brijunas priority: normal severity: normal status: open title: Incorrect division result type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 20:15:57 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 08 Feb 2015 19:15:57 +0000 Subject: [issue23413] Incorrect division result In-Reply-To: <1423422792.29.0.39296794097.issue23413@psf.upfronthosting.co.za> Message-ID: <1423422957.12.0.244072589209.issue23413@psf.upfronthosting.co.za> Benjamin Peterson added the comment: https://docs.python.org/3/tutorial/floatingpoint.html ---------- nosy: +benjamin.peterson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 21:07:49 2015 From: report at bugs.python.org (John Malmberg) Date: Sun, 08 Feb 2015 20:07:49 +0000 Subject: [issue10320] printf %qd is nonstandard In-Reply-To: <1288946289.37.0.37131892978.issue10320@psf.upfronthosting.co.za> Message-ID: <1423426069.38.0.906969579714.issue10320@psf.upfronthosting.co.za> John Malmberg added the comment: OpenVMS needs %lld or "%" PY_FORMAT_LONG_LONG "d" in order to build the _ctypes module. ---------- nosy: +John.Malmberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 21:19:41 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 08 Feb 2015 20:19:41 +0000 Subject: [issue10320] printf %qd is nonstandard In-Reply-To: <1288946289.37.0.37131892978.issue10320@psf.upfronthosting.co.za> Message-ID: <1423426781.33.0.0228799517127.issue10320@psf.upfronthosting.co.za> Mark Lawrence added the comment: As VMS is not supported I doubt that people here are too bothered about what is needed to build the _ctypes module on it. ---------- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 22:38:58 2015 From: report at bugs.python.org (mattip) Date: Sun, 08 Feb 2015 21:38:58 +0000 Subject: [issue23414] seek(count, whence) accepts bogus whence on windows, python2.7 Message-ID: <1423431538.2.0.390923477638.issue23414@psf.upfronthosting.co.za> New submission from mattip: f=open('abc.txt', 'w+') f.seek(0, 42) does not raise an exception on windows, python2.7 ---------- components: Windows messages: 235568 nosy: mattip, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: seek(count, whence) accepts bogus whence on windows, python2.7 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 22:59:50 2015 From: report at bugs.python.org (Robert Collins) Date: Sun, 08 Feb 2015 21:59:50 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423432790.09.0.465837735048.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: Sorry xonatius I wasn't clear: AFAICT your patch is going to require changes to the traceback tests, and this issue is changing the implementation substantially: I was suggesting that you make sure your patch applies on top of this issue, not that you merge them :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 23:01:35 2015 From: report at bugs.python.org (Robert Collins) Date: Sun, 08 Feb 2015 22:01:35 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423432895.22.0.9648165701.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: Nick, Antoine - I'm now stuck between you. Options going forward: - I can JFDI realising you won't both be happy :) - you two can reach consensus! I could cripple __init__ by switching to __new__, but I think thats massive overcomplication and not needed. I can of course add more text to the pydoc prose saying 'do not use __init__' if that would address Nicks concern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 23:13:04 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 08 Feb 2015 22:13:04 +0000 Subject: [issue23415] add-to-pydotorg does not support .exe installers for Windows Message-ID: <1423433584.82.0.0803149544554.issue23415@psf.upfronthosting.co.za> New submission from Larry Hastings: Steve is using new technology to make the installers for Windows. He generates four installers now: * .exe for Win32 * -amd64.exe for Win64 * -webinstall.exe for Win32 web-based installers * -amd64-webinstall.exe for Win64 web-based installers add-to-pydotorg does not recognize these. I attempted to hack it up to add support for them. All I did was modify the "file_descriptions" structure, adding new lines for each of the four new types. I believe my edits worked fine, but it failed to add three of the four installers. The first .exe it processed worked (the plain ".exe", the Win32 non-web-based installer). But the last three failed with the error message: Sorry, this request could not be processed. Please try again later. ---------- assignee: georg.brandl components: Build messages: 235571 nosy: georg.brandl, larry, steve.dower priority: normal severity: normal stage: needs patch status: open title: add-to-pydotorg does not support .exe installers for Windows type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 23:38:09 2015 From: report at bugs.python.org (eryksun) Date: Sun, 08 Feb 2015 22:38:09 +0000 Subject: [issue23414] seek(count, whence) accepts bogus whence on windows, python2.7 In-Reply-To: <1423431538.2.0.390923477638.issue23414@psf.upfronthosting.co.za> Message-ID: <1423435089.71.0.184594354032.issue23414@psf.upfronthosting.co.za> eryksun added the comment: The whence argument is used in a switch statement that handles SEEK_END and SEEK_CUR. It doesn't raise an error for an invalid whence value. It just falls through to the fsetpos call. _portable_fseek https://hg.python.org/cpython/file/648dcafa7e5f/Objects/fileobject.c#l692 0:000> k 3 Child-SP RetAddr Call Site 00000000`0021fa68 00000000`1e0ac84f MSVCR90!fsetpos 00000000`0021fa70 00000000`1e0aeea3 python27!_portable_fseek+0x6f 00000000`0021faa0 00000000`1e0c3d09 python27!file_seek+0x123 Why does it manually handle whence and call fgetpos/fsetpos instead of calling _fseeki64? fseek, _fseeki64 https://msdn.microsoft.com/en-us/library/75yw9bf3%28v=vs.90%29.aspx ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 23:41:20 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 08 Feb 2015 22:41:20 +0000 Subject: [issue23415] add-to-pydotorg does not support .exe installers for Windows In-Reply-To: <1423433584.82.0.0803149544554.issue23415@psf.upfronthosting.co.za> Message-ID: <1423435280.75.0.376699785981.issue23415@psf.upfronthosting.co.za> Larry Hastings added the comment: I should add, adding the files by hand worked fine. (Which means that if you experiment with the script, when it blows away the files and re-adds them, you'll be blowing away the files I added by hand. So if you do so, it's up to you to ensure the files are restored when you're done... one way or another.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 8 23:42:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 08 Feb 2015 22:42:43 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1423432895.22.0.9648165701.issue17911@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Escalating to python-dev for API design feedback is the usual path forward if we reach an impasse in the tracker comments. I'll make one more attempt at persuading Antoine here though: the fact that we're being tempted to add "do not use this API the way you would normally expect to use a Python API, even though it works exactly as you might expect" to the docs is a big red flag for me :) There's a split between the "low level API that exposes implementation details" (the exception state triple) and "high level API that hides them" in the current patch, and Antoine is entirely correct that we previously omitted the latter. It doesn't follow for me that we should also hide the fact that the higher level convenience API is implemented in terms of the lower level more implementation oriented one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 00:11:17 2015 From: report at bugs.python.org (Etienne Robillard) Date: Sun, 08 Feb 2015 23:11:17 +0000 Subject: [issue22235] httplib: TypeError with file() object in ssl.py In-Reply-To: <1408543105.82.0.290860786236.issue22235@psf.upfronthosting.co.za> Message-ID: <1423437077.66.0.544307291711.issue22235@psf.upfronthosting.co.za> Etienne Robillard added the comment: problem is fixed with python 2.7.9. it seem ssl.py module has been greatly improved with this release. Thanks! ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 00:13:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Feb 2015 23:13:21 +0000 Subject: [issue20680] Pickle socket enums by names In-Reply-To: <1392758039.35.0.851373733794.issue20680@psf.upfronthosting.co.za> Message-ID: <1423437201.19.0.378077406909.issue20680@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For the socket module constants there is even better way, which supports forward compatibility, i.e. SOCK_STREAM pickled in 3.5 could be unpickled on 3.3 (replacing ints with enums breaks forward compatibility). Here is a patch. ---------- Added file: http://bugs.python.org/file38048/socket_enums_pickle_by_name_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 01:02:28 2015 From: report at bugs.python.org (Etienne Robillard) Date: Mon, 09 Feb 2015 00:02:28 +0000 Subject: [issue22235] httplib: TypeError with file() object in ssl.py In-Reply-To: <1408543105.82.0.290860786236.issue22235@psf.upfronthosting.co.za> Message-ID: <1423440148.35.0.245302387569.issue22235@psf.upfronthosting.co.za> Etienne Robillard added the comment: hg push worked like a charm... but for some reasons i get another error trying to install things with setuptools: erob at nguns:~/Desktop/pyaml-14.12.10$ sudo python setup.py install --prefix=/usr/local Processing dependencies for pyaml==14.12.10 Searching for PyYAML Reading http://pypi.python.org/simple/PyYAML/ Download error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) -- Some packages may not be found! Couldn't find index page for 'PyYAML' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://pypi.python.org/simple/ Download error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) -- Some packages may not be found! No local packages or download links found for PyYAML Is setuptools still working with this ssl.py module ? ---------- resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 01:10:27 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 00:10:27 +0000 Subject: [issue3647] urlparse - relative url parsing and joins to be RFC3986 compliance In-Reply-To: <1219409676.71.0.379802173537.issue3647@psf.upfronthosting.co.za> Message-ID: <1423440627.4.0.352254416512.issue3647@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 01:11:10 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Feb 2015 00:11:10 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1423432895.22.0.9648165701.issue17911@psf.upfronthosting.co.za> Message-ID: <54D7FB1B.7010701@free.fr> Antoine Pitrou added the comment: You can also switch back to a single constructor, taking either an exception instance or an exception triple. That way everyone is happy - except perhaps if you are ideologically opposed to polymorphic signatures :-) Switching to python-dev would probably be overkill for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 01:17:34 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 00:17:34 +0000 Subject: [issue5843] Normalization error in urlunparse In-Reply-To: <1240686759.57.0.0410680082249.issue5843@psf.upfronthosting.co.za> Message-ID: <1423441054.31.0.976301360953.issue5843@psf.upfronthosting.co.za> Martin Panter added the comment: Looks like this duplicates Issue 22852, which has a patch, although its author had second thoughts on the implementation ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 01:37:07 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 00:37:07 +0000 Subject: [issue12955] urllib.request example should use "with ... as:" In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za> Message-ID: <1423442227.39.0.453542617828.issue12955@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 22755 is about the example arms race for contextlib.closing(). ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 02:22:17 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 01:22:17 +0000 Subject: [issue12955] urllib.request example should use "with ... as:" In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za> Message-ID: <1423444937.6.0.576881580862.issue12955@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch to change the urlopen() examples to use context managers where appropriate. There were also a few examples of handling HTTPError which I didn?t touch, because the whole file object versus exception object thing is probably a separate can of worms. ---------- keywords: +patch Added file: http://bugs.python.org/file38049/urlopen-with.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 03:32:28 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 02:32:28 +0000 Subject: [issue22852] urllib.parse wrongly strips empty #fragment In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za> Message-ID: <1423449147.99.0.474556511986.issue22852@psf.upfronthosting.co.za> Martin Panter added the comment: I also liked the idea of returning None to distinguish a missing URL component from an empty-but-present component, and it would make them more consistent with the ?username? and ?password? fields. But I agree it would break backwards compabitility too much. The idea of ?has_fragment? etc flags might work. The ParseResult etc class signatures could be expanded like this: SplitResult(scheme, netloc, path, query, fragment, *, has_netloc=None, has_query=None, has_fragment=None) >>> url1 = SplitResult("http", "localhost", "/path", query="", fragment="") >>> url1.has_netloc True >>> url1.has_fragment False >>> url2 = SplitResult("http", "localhost", "/path", query="", fragment="", has_fragment=True) >>> url2.has_fragment True >>> url2.has_query False >>> url2.geturl() "http://localhost/path#" Is it also worth adding ?has_params? for urlparse()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 04:27:49 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 03:27:49 +0000 Subject: [issue10697] host and port attributes not documented well in function urllib.parse.urlparse and urlsplit In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za> Message-ID: <1423452469.0.0.908095948727.issue10697@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t understand where the work needs to be done for this one. Even in the 3.1 and 2.7 documentation, the urlparse() and urlsplit() entries both list ?port? as one of the returned attributes, and urlparse() has example code for it. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 05:03:57 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 04:03:57 +0000 Subject: [issue23416] Make urllib.parse.SplitResult etc arguments optional Message-ID: <1423454637.96.0.780742641159.issue23416@psf.upfronthosting.co.za> New submission from Martin Panter: This would be a simple API enhancement and would allow easier building of URLs, like >>> SplitResult("rtp", address, query=urlencode(query)).geturl() "rtp://localhost:5004?rtcpport=5005" It seems the best way to do this at the moment is annoyingly verbose: SplitResult("rtp", address, path="", query=urlencode(query), fragment="").geturl() The way hinted by the documentation can leave an ugly empty query string: >>> query = () >>> "rtp://%s?%s" % (address, urlencode(query)) "rtp://localhost:5004?" This enhancement would also allow easy parsing of usernames, ports, etc: >>> SplitResult(netloc="[::1]:0").hostname "::1" >>> SplitResult(netloc="[::1]:0").port 0 Looking at the code, I think this could be implemented by adding an explicit constructor to each of the concrete classes, with arguments defaulting to "" or b"" as appropriate. ---------- components: Library (Lib) messages: 235584 nosy: vadmium priority: normal severity: normal status: open title: Make urllib.parse.SplitResult etc arguments optional type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 05:13:13 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 04:13:13 +0000 Subject: [issue15009] urlsplit can't round-trip relative-host urls. In-Reply-To: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za> Message-ID: <1423455193.32.0.942311442569.issue15009@psf.upfronthosting.co.za> Martin Panter added the comment: Fixing Issue 22852 or Issue 5843 should help fixing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 05:24:32 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 04:24:32 +0000 Subject: [issue18140] urlparse.urlsplit confused to fragment when password include # In-Reply-To: <1370425503.35.0.436511643169.issue18140@psf.upfronthosting.co.za> Message-ID: <1423455872.34.0.00297207519037.issue18140@psf.upfronthosting.co.za> Martin Panter added the comment: Possibly related: Issue 23328. I would have thought any special characters in the password etc field should be encoded. Where do such unencoded URLs come from? It seems that this would change the behaviour of parsing a URL such as http://host/path/with/unencoded/@/character Is one of these scenarios more valid than the other? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 05:38:52 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 04:38:52 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1423456732.26.0.156099864395.issue23328@psf.upfronthosting.co.za> Martin Panter added the comment: Related: Issue 18140. The slash character is meant to be a reserved character in URLs, so why hasn?t it been encoded? Where does the environment variable come from? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 06:10:46 2015 From: report at bugs.python.org (Andy Reitz) Date: Mon, 09 Feb 2015 05:10:46 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1423458646.36.0.0567809964915.issue23328@psf.upfronthosting.co.za> Andy Reitz added the comment: The proxy credentials are supplied by our sysadmin. My understanding is that the http_proxy env variable doesn't require URI encoding. In addition, the same credentials work fine with curl. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 06:28:18 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 09 Feb 2015 05:28:18 +0000 Subject: [issue21429] Input.output error with multiprocessing In-Reply-To: <1399220691.1.0.523621963732.issue21429@psf.upfronthosting.co.za> Message-ID: <1423459698.62.0.606159483339.issue21429@psf.upfronthosting.co.za> Davin Potts added the comment: The provided links to the relevant code are unfortunately pointing at the master branch's copy of those files and not a specific version of the code making it that much harder to now discern where the issue arises. (A number of things have changed in the master branch since this issue was first reported.) Can Mikaela or Valentin or others provide a minimal piece of code that can still reproduce the issue? Without more information, it appears it will be very difficult to try to reproduce or effectively investigate this issue further. If the issue is no longer reproducible, such an update would also very much be appreciated. ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 06:44:16 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 05:44:16 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1423460656.01.0.909280228351.issue23328@psf.upfronthosting.co.za> Martin Panter added the comment: The relevant code looks like it is _parse_proxy() at Lib/urllib/request.py:693. It has custom code to search for a slash (/), so it wouldn?t be hard to make it search after the last at (@) symbol. (I previously assumed it would use urlsplit() or similar, which would be harder to adjust.) Even Curl seems to require an @ symbol in the username or password to be encoded, i.e. the following doesn?t work, so you still need to encode the fields in general to work with Curl. http_proxy=http://a at x:b at localhost curl . . . http_proxy=http://a:b at x@localhost curl . . . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 06:50:04 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 09 Feb 2015 05:50:04 +0000 Subject: [issue23072] 2.7.9 multiprocessing compile conflict In-Reply-To: <1418794673.39.0.221318823729.issue23072@psf.upfronthosting.co.za> Message-ID: <1423461004.97.0.0811068444582.issue23072@psf.upfronthosting.co.za> Davin Potts added the comment: It's a little unclear if one or more of the following is true: (1) you are having trouble getting the multiprocessing module to build properly on Solaris 2.8; (2) you are having trouble getting your own code to build in a similar way to the multiprocessing module; (3) you have indeed found a workaround that works for your situation; (4) you are requesting a change to the multiprocessing module to better support builds on Solaris 2.8. Could you help clarify? If you have found a workaround that would better support builds on Solaris 2.8 then might you also be able to propose a patch? If not, could you clarify what steps are required to reproduce the issue? ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 07:03:01 2015 From: report at bugs.python.org (George Schizas) Date: Mon, 09 Feb 2015 06:03:01 +0000 Subject: [issue23417] Windows 8.1 and Windows Server 2012 R2 are not displayed properly Message-ID: <1423461781.68.0.225997431705.issue23417@psf.upfronthosting.co.za> New submission from George Schizas: Python on Windows can now can understand that it's on Windows 8.1 and Windows Server 2012 R2, but platform.py hasn't been updated, and claims it's on "post2012Server": >>> import platform >>> print(platform.win32_ver()) ('post2012Server', '6.3.9600', '', 'Multiprocessor Free') The function win32_ver (which most of the platform library relies upon) should be changed, to include Windows 8.1 and Windows Server 2012 R2. I've attached a patch file that does that ---------- components: Library (Lib), Windows files: Python 3.5a1 - platform.py.patch keywords: patch messages: 235592 nosy: gschizas, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows 8.1 and Windows Server 2012 R2 are not displayed properly type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file38050/Python 3.5a1 - platform.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 07:30:10 2015 From: report at bugs.python.org (Georg Brandl) Date: Mon, 09 Feb 2015 06:30:10 +0000 Subject: [issue23415] add-to-pydotorg does not support .exe installers for Windows In-Reply-To: <1423433584.82.0.0803149544554.issue23415@psf.upfronthosting.co.za> Message-ID: <1423463410.05.0.257113436193.issue23415@psf.upfronthosting.co.za> Georg Brandl added the comment: Can you attach the diff you made? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 08:03:43 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 07:03:43 +0000 Subject: [issue23418] Keep http.server.__all__ up to date Message-ID: <1423465423.93.0.840073300907.issue23418@psf.upfronthosting.co.za> New submission from Martin Panter: Here is a patch that adds the Simple/CGIHTTPRequestHandler classes to __all__, and a test case that should help keep it up to date in the future. ---------- components: Library (Lib) files: http.server-all.patch keywords: patch messages: 235594 nosy: vadmium priority: normal severity: normal status: open title: Keep http.server.__all__ up to date type: behavior Added file: http://bugs.python.org/file38051/http.server-all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 08:05:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Feb 2015 07:05:13 +0000 Subject: [issue17896] Move Windows external libs from \..\ to \externals In-Reply-To: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za> Message-ID: <20150209070437.51380.6190@psf.io> Roundup Robot added the comment: New changeset 7d22dbf3a0dc by Martin v. L?wis in branch '3.4': Issue #17896: Update msi.py to new externals dir. https://hg.python.org/cpython/rev/7d22dbf3a0dc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 09:13:42 2015 From: report at bugs.python.org (Mikhail Korobov) Date: Mon, 09 Feb 2015 08:13:42 +0000 Subject: [issue22003] BytesIO copy-on-write In-Reply-To: <1405635937.15.0.406925083031.issue22003@psf.upfronthosting.co.za> Message-ID: <1423469622.67.0.817985112172.issue22003@psf.upfronthosting.co.za> Mikhail Korobov added the comment: Shouldn't this fix be mentioned in https://docs.python.org/3.5/whatsnew/3.5.html#optimizations ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 09:22:24 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 09 Feb 2015 08:22:24 +0000 Subject: [issue23418] Keep http.server.__all__ up to date In-Reply-To: <1423465423.93.0.840073300907.issue23418@psf.upfronthosting.co.za> Message-ID: <1423470144.22.0.136837652714.issue23418@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. ---------- nosy: +berker.peksag stage: -> commit review versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 10:17:39 2015 From: report at bugs.python.org (Ilya Kulakov) Date: Mon, 09 Feb 2015 09:17:39 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1423473459.28.0.344717753524.issue22273@psf.upfronthosting.co.za> Ilya Kulakov added the comment: The structure hack does not work on Windows 8, x64. ---------- nosy: +Ilya.Kulakov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 11:22:10 2015 From: report at bugs.python.org (Alexei Romanov) Date: Mon, 09 Feb 2015 10:22:10 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1423477330.56.0.313996078191.issue22273@psf.upfronthosting.co.za> Changes by Alexei Romanov : ---------- nosy: +alexei.romanov versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 11:48:57 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 10:48:57 +0000 Subject: [issue1429] FD leak in SocketServer when request handler throws exception In-Reply-To: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za> Message-ID: <1423478937.65.0.462276025661.issue1429@psf.upfronthosting.co.za> Martin Panter added the comment: I think calling shutdown_request(), or at least close_request(), should be done regardless of whether handle_error() fails or not. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 12:00:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Feb 2015 11:00:44 +0000 Subject: [issue23419] Faster default __reduce__ for classes without __init__ Message-ID: <1423479644.09.0.947345755494.issue23419@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes faster default __reduce__ implementation for the case when there is no non-trivial __init__ defined (e.g. for named tuples). In this case __reduce__ will return (cls, newargs) instead of (copyreg.__newobj__, (cls,) + newargs). >>> pickletools.dis(pickletools.optimize(pickle.dumps(turtle.Vec2D(12, 34), 3))) Before: 0: \x80 PROTO 3 2: c GLOBAL 'turtle Vec2D' 16: K BININT1 12 18: K BININT1 34 20: \x86 TUPLE2 21: \x81 NEWOBJ 22: . STOP After: 0: \x80 PROTO 3 2: c GLOBAL 'turtle Vec2D' 16: K BININT1 12 18: K BININT1 34 20: \x86 TUPLE2 21: R REDUCE 22: . STOP Pickled size is the same, but pickling is faster. The benefit is in avoiding of importing copyreg.__newobj__ and allocating new tuple (cls,) + newargs. Microbenchmarks results: $ ./python -m timeit -s "import pickle; from turtle import Vec2D; a = [Vec2D(i, i+0.1) for i in range(1000)]" -- "pickle.dumps(a)" Before: 100 loops, best of 3: 16.3 msec per loop After: 100 loops, best of 3: 15.2 msec per loop $ ./python -m timeit -s "import copy; from turtle import Vec2D; a = [Vec2D(i, i+0.1) for i in range(1000)]" -- "copy.deepcopy(a)" Before: 10 loops, best of 3: 96.6 msec per loop After: 10 loops, best of 3: 88.7 msec per loop ---------- components: Interpreter Core files: object_reduce_no_init.patch keywords: patch messages: 235600 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Faster default __reduce__ for classes without __init__ type: performance versions: Python 3.5 Added file: http://bugs.python.org/file38052/object_reduce_no_init.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 12:51:56 2015 From: report at bugs.python.org (Robert Kuska) Date: Mon, 09 Feb 2015 11:51:56 +0000 Subject: [issue23249] test_win32 fails on aarch64 In-Reply-To: <1421401283.38.0.406623425658.issue23249@psf.upfronthosting.co.za> Message-ID: <1423482716.36.0.0937263745612.issue23249@psf.upfronthosting.co.za> Robert Kuska added the comment: Sorry for the late answer, I forgot about this issue. 3.2.1 doesn't contain required fix(sorry for the misleading suggestion 'or update bundled libffi' from report) but master branch at upstream repo (https://github.com/atgreen/libffi) does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 13:05:42 2015 From: report at bugs.python.org (Robert Kuska) Date: Mon, 09 Feb 2015 12:05:42 +0000 Subject: [issue23420] python -m cProfile -s fails with non informative message Message-ID: <1423483542.47.0.873331461969.issue23420@psf.upfronthosting.co.za> New submission from Robert Kuska: Originaly reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1160640 I've forgotten to add the sort value to the -s option of cProfile which results in a traceback instead of user friendly error message. In the example below hello.py just prints a "Hello World": $ python -m cProfile -s hello.py Traceback (most recent call last): File "/usr/lib64/python2.6/runpy.py", line 122, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib64/python2.6/runpy.py", line 34, in _run_code exec code in run_globals File "/usr/lib64/python2.6/cProfile.py", line 190, in main() File "/usr/lib64/python2.6/cProfile.py", line 185, in main parser.print_usage() File "/usr/lib64/python2.6/optparse.py", line 1597, in print_usage print >>file, self.get_usage() File "/usr/lib64/python2.6/optparse.py", line 1583, in get_usage self.expand_prog_name(self.usage)) File "/usr/lib64/python2.6/optparse.py", line 1560, in expand_prog_name return s.replace("%prog", self.get_prog_name()) File "/usr/lib64/python2.6/optparse.py", line 1555, in get_prog_name return os.path.basename(sys.argv[0]) IndexError: list index out of range Tested with python2.7, python3.4 with the same result. Attached patch adds `choices` for sort option of cProfile. > $ python -m cProfile -s sdds.py Usage: cProfile.py [-o output_file_path] [-s sort] scriptfile [arg] ... cProfile.py: error: option -s: invalid choice: 'sdds.py' (choose from 'cumulative', 'module', 'ncalls', 'pcalls', 'file', 'line', 'name', 'calls', 'stdname', 'nfl', 'filename', 'cumtime', 'time', 'tottime') ---------- components: Extension Modules files: sort-choices.patch keywords: patch messages: 235602 nosy: rkuska priority: normal severity: normal status: open title: python -m cProfile -s fails with non informative message type: enhancement versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file38053/sort-choices.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 13:12:52 2015 From: report at bugs.python.org (Robert Kuska) Date: Mon, 09 Feb 2015 12:12:52 +0000 Subject: [issue23420] python -m cProfile -s fails with non informative message In-Reply-To: <1423483542.47.0.873331461969.issue23420@psf.upfronthosting.co.za> Message-ID: <1423483972.15.0.420173415344.issue23420@psf.upfronthosting.co.za> Changes by Robert Kuska : Added file: http://bugs.python.org/file38054/sort-choices.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 13:44:00 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 09 Feb 2015 12:44:00 +0000 Subject: [issue4773] HTTPMessage not documented and has inconsistent API across Py2/Py3 In-Reply-To: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za> Message-ID: <1423485840.55.0.424627033884.issue4773@psf.upfronthosting.co.za> Martin Panter added the comment: Jeremy?s patch appears to have been merged in revision 9eceb618274a. A documentation entry for the HTTPMessage class was also added in 2009, pointing back to email.message.Message. So is there anything left to do for this issue? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 13:51:05 2015 From: report at bugs.python.org (Robert Kuska) Date: Mon, 09 Feb 2015 12:51:05 +0000 Subject: [issue23420] python -m cProfile -s fails with non informative message In-Reply-To: <1423483542.47.0.873331461969.issue23420@psf.upfronthosting.co.za> Message-ID: <1423486265.45.0.154567914272.issue23420@psf.upfronthosting.co.za> Changes by Robert Kuska : Added file: http://bugs.python.org/file38055/sort-choices.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 14:03:37 2015 From: report at bugs.python.org (wdv4758h) Date: Mon, 09 Feb 2015 13:03:37 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms Message-ID: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> New submission from wdv4758h: The command "python -m tarfile -c test.tar.bz2 test/" should create a file that is compressed by bzip2, but actually the detection of compression algorithm that should be used is broken (for gz, xz, bz2). fix it by prepending a dot to the keys of the dictionary ---------- components: Library (Lib) files: fix_compressions_dict.patch hgrepos: 297 keywords: patch messages: 235604 nosy: wdv4758h priority: normal severity: normal status: open title: tarfile module does not correctly choose compression algorithms type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file38056/fix_compressions_dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 14:07:30 2015 From: report at bugs.python.org (Etienne Robillard) Date: Mon, 09 Feb 2015 13:07:30 +0000 Subject: [issue22235] httplib: TypeError with file() object in ssl.py In-Reply-To: <1408543105.82.0.290860786236.issue22235@psf.upfronthosting.co.za> Message-ID: <1423487250.07.0.258942774578.issue22235@psf.upfronthosting.co.za> Etienne Robillard added the comment: sometimes urllib break at different packages, with "SSL: CERTIFICATE_VERIFY_FAILED" message. It seem related to the new ssl.py backport and pip. sudo python setup.py install --prefix=/usr/local Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.10.tar.gz Traceback (most recent call last): File "setup.py", line 31, in distribute_setup.use_setuptools() File "/home/steiner/Desktop/feedcache-1.4.1/distribute_setup.py", line 145, in use_setuptools return _do_download(version, download_base, to_dir, download_delay) File "/home/steiner/Desktop/feedcache-1.4.1/distribute_setup.py", line 124, in _do_download to_dir, download_delay) File "/home/steiner/Desktop/feedcache-1.4.1/distribute_setup.py", line 193, in download_setuptools src = urlopen(url) File "/usr/local/lib/python2.7/urllib2.py", line 154, in urlopen return opener.open(url, data, timeout) File "/usr/local/lib/python2.7/urllib2.py", line 437, in open response = meth(req, response) File "/usr/local/lib/python2.7/urllib2.py", line 550, in http_response 'http', request, response, code, msg, hdrs) File "/usr/local/lib/python2.7/urllib2.py", line 469, in error result = self._call_chain(*args) File "/usr/local/lib/python2.7/urllib2.py", line 409, in _call_chain result = func(*args) File "/usr/local/lib/python2.7/urllib2.py", line 656, in http_error_302 return self.parent.open(new, timeout=req.timeout) File "/usr/local/lib/python2.7/urllib2.py", line 431, in open response = self._open(req, data) File "/usr/local/lib/python2.7/urllib2.py", line 449, in _open '_open', req) File "/usr/local/lib/python2.7/urllib2.py", line 409, in _call_chain result = func(*args) File "/usr/local/lib/python2.7/urllib2.py", line 1240, in https_open context=self._context) File "/usr/local/lib/python2.7/urllib2.py", line 1197, in do_open raise URLError(err) urllib2.URLError: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 14:13:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Feb 2015 13:13:14 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423487594.52.0.942725592461.issue23421@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patch. Could you provide tests? ---------- nosy: +berker.peksag, serhiy.storchaka stage: -> test needed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 14:21:25 2015 From: report at bugs.python.org (paul) Date: Mon, 09 Feb 2015 13:21:25 +0000 Subject: [issue23361] integer overflow in winapi_createprocess In-Reply-To: <1422798703.49.0.874007534993.issue23361@psf.upfronthosting.co.za> Message-ID: <1423488085.1.0.934328188137.issue23361@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 14:28:34 2015 From: report at bugs.python.org (=?utf-8?b?6Kix6YKx57+U?=) Date: Mon, 09 Feb 2015 13:28:34 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423488514.34.0.642024394403.issue23421@psf.upfronthosting.co.za> ??? added the comment: yes just wanna know is there a standard way to get file type by libmagic ? ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 14:30:47 2015 From: report at bugs.python.org (=?utf-8?b?6Kix6YKx57+U?=) Date: Mon, 09 Feb 2015 13:30:47 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423488647.46.0.903138966649.issue23421@psf.upfronthosting.co.za> Changes by ??? : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 15:06:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Feb 2015 14:06:06 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423490766.51.0.850282651169.issue23421@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No need to use libmagic. tarfile.TarFile.gzopen() should fail if the file is not gzipped tar file. There CLI tests in Lib/test/test_tarfile.py. New test should create tar file with file name that ends with the '.gz' extension and check that it can be open and read with gzopen(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 15:10:12 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 09 Feb 2015 14:10:12 +0000 Subject: [issue23417] Windows 8.1 and Windows Server 2012 R2 are not displayed properly In-Reply-To: <1423461781.68.0.225997431705.issue23417@psf.upfronthosting.co.za> Message-ID: <1423491012.89.0.0269997167338.issue23417@psf.upfronthosting.co.za> Steve Dower added the comment: We're already tracking this at #19143, where I've got a future proofed version of the function. Thanks for the prod though, I'll try and get some action going again. ---------- resolution: -> duplicate status: open -> closed superseder: -> Finding the Windows version getting messier (detect windows 8.1?) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 15:13:18 2015 From: report at bugs.python.org (=?utf-8?b?6Kix6YKx57+U?=) Date: Mon, 09 Feb 2015 14:13:18 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423491198.25.0.372775992826.issue23421@psf.upfronthosting.co.za> ??? added the comment: Oh, I can use it. thx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 15:14:04 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 09 Feb 2015 14:14:04 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1423491244.74.0.591034544546.issue19143@psf.upfronthosting.co.za> Steve Dower added the comment: (Was reminded about this by #23417) Any word on the back compat issues in platform.py? Can we make the version in 3.5 only work with Vista+, or do I need to handle XP in case someone takes the file onto an earlier Python version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 15:40:14 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 09 Feb 2015 14:40:14 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1423491244.74.0.591034544546.issue19143@psf.upfronthosting.co.za> Message-ID: <54D8C6CB.4050701@egenix.com> Marc-Andre Lemburg added the comment: On 09.02.2015 15:14, Steve Dower wrote: > > Steve Dower added the comment: > > (Was reminded about this by #23417) > > Any word on the back compat issues in platform.py? Can we make the version in 3.5 only work with Vista+, or do I need to handle XP in case someone takes the file onto an earlier Python version? platform.py has to work on as many platforms as possible (by design), so as long as Python still runs on Windows XP, we cannot leave that version behind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 16:17:30 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 09 Feb 2015 15:17:30 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1423495050.7.0.284288615996.issue19143@psf.upfronthosting.co.za> Steve Dower added the comment: Including the one shipped in the stdlib? Python 3.5 no longer supports XP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 16:38:09 2015 From: report at bugs.python.org (Daniel Harding) Date: Mon, 09 Feb 2015 15:38:09 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1423496289.2.0.986031375836.issue9949@psf.upfronthosting.co.za> Daniel Harding added the comment: @Zach - thanks for the review. Sorry that it has taken a few months to pick this issue back up. Anyway, here is an updated patch. It is pretty different than the previous patch, to the point that I would consider it a completely new patch. Anyway, here's a basic rundown of what the patch contains: Two functions in Modules/posixmodule.c were modified to handle bytes objects as well as str objects: win_readlink and _getfinalpathname. This was necessary to allow os.path.realpath() to continue returning bytes when supplied with bytes. I know you said in your review that you didn't care about this because using bytes paths on Windows is deprecated, but I think it still important to maintain backwards compatibility. A new implementation of realpath() was added to Lib\ntpath.py, used when _getfinalpathname is available (when _getfinalpathname is not available, realpath remains a synonym for abspath, as it was previously). The logic here has been completely reworked and is roughly modeled on the realpath implementation from Lib\posixpath.py. A number of tests were added to Lib\test\test_ntpath.py for realpath() functionality. Three of the tests were based on realpath() tests from test_posixpath.py, but one is completely new: test_realpath_broken_symlinks. A note about improved Windows support was added to the documentation for realpath(), but no other doc changes have been made. Anyway, feedback is welcome - I'd love to get this code in sufficient shape to see a working realpath() implementation for Windows land in Python. ---------- Added file: http://bugs.python.org/file38057/issue9949-v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 16:45:08 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 09 Feb 2015 15:45:08 +0000 Subject: [issue23422] Clarify docs for importlib.import_module() Message-ID: <1423496708.39.0.508635169879.issue23422@psf.upfronthosting.co.za> New submission from Brett Cannon: * Link to the function from importlib.__import__() * Link to importlib.invalidate_caches() * Linkify mention in docs for importlib.util.find_spec() ---------- assignee: brett.cannon components: Documentation messages: 235616 nosy: brett.cannon priority: low severity: normal status: open title: Clarify docs for importlib.import_module() versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 16:45:49 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 09 Feb 2015 15:45:49 +0000 Subject: [issue23412] importlib sometimes fails to import a recently created module In-Reply-To: <1423410215.95.0.524604601959.issue23412@psf.upfronthosting.co.za> Message-ID: <1423496749.96.0.399713096563.issue23412@psf.upfronthosting.co.za> Brett Cannon added the comment: Because stat results are cached for performance reasons, it's possible to write to the file system and then try to read/import from it before the modification time for the directory even picks up that there was a change. For this reason there is importlib.invalidate_caches(): https://docs.python.org/3/library/importlib.html#importlib.invalidate_caches . I have opened http://bugs.python.org/issue23422 to track that the docs for importlib.import_module() point out invalidate_caches(). ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 16:52:15 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 09 Feb 2015 15:52:15 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1423497135.9.0.932884690659.issue19143@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Steve just in case you didn't know the rules are given here https://www.python.org/dev/peps/pep-0011/#microsoft-windows. I find it a nuisance that you have to follow an external link to get the status of Python, but maybe it's the lesser of two evils? An aside, at some point the fourth paragraph will need changing to reflect that VS 2015 and later versions will be maintaining backward compatibility. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 16:57:14 2015 From: report at bugs.python.org (David Wilson) Date: Mon, 09 Feb 2015 15:57:14 +0000 Subject: [issue22003] BytesIO copy-on-write In-Reply-To: <1405635937.15.0.406925083031.issue22003@psf.upfronthosting.co.za> Message-ID: <1423497434.54.0.498059935978.issue22003@psf.upfronthosting.co.za> David Wilson added the comment: Attached trivial patch for whatsnew.rst. ---------- Added file: http://bugs.python.org/file38058/whatsnew.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 17:30:33 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 09 Feb 2015 16:30:33 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1423495050.7.0.284288615996.issue19143@psf.upfronthosting.co.za> Message-ID: <54D8E0A6.1060409@egenix.com> Marc-Andre Lemburg added the comment: On 09.02.2015 16:17, Steve Dower wrote: > > Steve Dower added the comment: > > Including the one shipped in the stdlib? Python 3.5 no longer supports XP. We normally have the platform.py module support multiple Python versions (at least that's how we did this in Python 2). The reason is that we'd like to make it possible to easily backport the module to earlier versions. This has generally not been a major problem, so if possible, let's keep it that way for Python 3 as well. Thanks, -- Marc-Andre Lemburg eGenix.com ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 17:39:57 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 09 Feb 2015 16:39:57 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1423499997.89.0.676751664025.issue19143@psf.upfronthosting.co.za> Steve Dower added the comment: @Marc-Andre: Okay, I'll make it easier to backport. You're listed as maintainer - would you like me to post updates here and let you merge them in? @Mark - yep, I'm aware of that. That's how I know that 3.5 doesn't support XP anymore :) (I think we're even past the 3 years on keeping old project files around for VS 2008, which is good since they're already gone from tip.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 18:40:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Feb 2015 17:40:04 +0000 Subject: [issue1776674] glob.glob inconsistent Message-ID: <1423503604.0.0.354803510687.issue1776674@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 18:41:38 2015 From: report at bugs.python.org (=?utf-8?b?6Kix6YKx57+U?=) Date: Mon, 09 Feb 2015 17:41:38 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423503698.53.0.76486877101.issue23421@psf.upfronthosting.co.za> ??? added the comment: Here is the tests. ---------- hgrepos: +298 Added file: http://bugs.python.org/file38059/add_tarfile_cli_filetype_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 18:51:30 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 09 Feb 2015 17:51:30 +0000 Subject: [issue23415] add-to-pydotorg does not support .exe installers for Windows In-Reply-To: <1423433584.82.0.0803149544554.issue23415@psf.upfronthosting.co.za> Message-ID: <1423504290.87.0.318648668774.issue23415@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached for your reading pleasure. ---------- keywords: +patch Added file: http://bugs.python.org/file38060/larry.add-to-pydotorg.exe.support.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 18:53:03 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 09 Feb 2015 17:53:03 +0000 Subject: [issue12738] Bug in multiprocessing.JoinableQueue() implementation on Ubuntu 11.04 In-Reply-To: <1313108742.86.0.818410001029.issue12738@psf.upfronthosting.co.za> Message-ID: <1423504383.52.0.791435495237.issue12738@psf.upfronthosting.co.za> Davin Potts added the comment: Thank you for the provided test case but because it depends upon compiled code (the libsvm.so.2 file you supplied) it: (1) makes me wonder if the issue might not arise from an issue inside the supplied library (perhaps it was not rebuilt properly on your Ubuntu 11.04 system after migrating to it from OpenSUSE 11.4 -- the timestamp on the libsvm.so.2 file appears to support this suspicion); (2) does not give us a reasonably concise test case to be able to debug and begin to try to understand. Would it be possible to supply a simpler demonstration of the issue that perhaps only involves Python code? I realize this issue is quite stale now and that you (Michael) have already reported discovering a workaround. ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 19:34:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Feb 2015 18:34:36 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423506876.38.0.882938276872.issue23421@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In general LGTM, but I have added few nitpicks on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 19:34:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Feb 2015 18:34:49 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423506889.23.0.650818066522.issue23421@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 20:39:39 2015 From: report at bugs.python.org (Mark Baker) Date: Mon, 09 Feb 2015 19:39:39 +0000 Subject: [issue23423] XPath Support in ElementTree doc omission Message-ID: <1423510779.4.0.551912157105.issue23423@psf.upfronthosting.co.za> New submission from Mark Baker: The list of XPath supported features in section 20.5.2.2. "Supported XPath syntax" on page https://docs.python.org/3.4/library/xml.etree.elementtree.html does not list the use of a predicate based on an element value (it only list predicates based on an attribute value. However, testing in 3.4 shows that a predicate based on an element value also works. >>> import xml.etree.ElementTree as etree >>> x = 'bing' >>> y = etree.XML(x) # Find by attribute value >>> z = y.find('bar/baz[@y="bang"]') >>> print(z) # Find by element value >>> z = y.find('bar/[baz="bing"]') >>> print(z) # Find fails with incorrect element value >>> z = y.find('bar/[baz="bong"]') >>> z >>> print(z) None Below the line that says: [tag] Selects all elements that have a child named tag. Only immediate children are supported. It should say something like: [tag="value"] Selects all elements that have a child named tag with the given value. Only immediate children are supported. ---------- assignee: docs at python components: Documentation messages: 235627 nosy: docs at python, mbakeranalecta priority: normal severity: normal status: open title: XPath Support in ElementTree doc omission type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 21:19:54 2015 From: report at bugs.python.org (Panagiotis Issaris) Date: Mon, 09 Feb 2015 20:19:54 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1423513194.69.0.318969205812.issue23328@psf.upfronthosting.co.za> Panagiotis Issaris added the comment: RFC3986 seems to state that a '/' character should be encoded: """... reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" ... The user information, if present, is followed by a commercial at-sign ("@") that delimits it from the host. userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) """ ---------- nosy: +Panagiotis.Issaris _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 21:37:19 2015 From: report at bugs.python.org (Grzegorz Abramczyk) Date: Mon, 09 Feb 2015 20:37:19 +0000 Subject: [issue23424] Unicode character ends interactive session Message-ID: <1423514239.73.0.0631467799432.issue23424@psf.upfronthosting.co.za> New submission from Grzegorz Abramczyk: Inputing some Unicode characters (like '??????...') causes interactive session to abort. When console session is set to use UTF-8 code page (65001) after diacritic character appears in string the session abruptly ends. Looking into debug output it looks like some cleanup is performed but there are no error messages indicating what caused problem. Problem spotted on Windows 10 (technical preview) but I may try to replicate it on some released operating system. --- C:\>chcp 1250 Active code page: 1250 C:\>python -i Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> '?' '?' >>> exit() C:\>chcp 65001 Active code page: 65001 C:\>python -i Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> '?' C:\ ---------- components: Unicode, Windows files: -v.txt messages: 235629 nosy: AGrzes, ezio.melotti, haypo, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Unicode character ends interactive session type: crash versions: Python 3.4 Added file: http://bugs.python.org/file38061/-v.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 21:55:10 2015 From: report at bugs.python.org (albertjan) Date: Mon, 09 Feb 2015 20:55:10 +0000 Subject: [issue23425] Windows getlocale unix-like with french, german, portuguese, spanish Message-ID: <1423515310.7.0.637877209066.issue23425@psf.upfronthosting.co.za> New submission from albertjan: getlocale() is supposed to (?) return a locale two-tuple in a platform-specific notation. However, in *Windows* 7 64, with Python 3.4, 3.3 and 2.7 a *unix-like*, abbreviated, lang_territory notation is used for french, german, portuguese, spanish. In other words: In these four cases, the output of setlocale is not equal to ".".join(locale.getlocale()) ## Code that demonstrates the differences from __future__ import print_function import locale import collections import pprint languages = ("chinese czech danish dutch english finnish french german greek " "hungarian icelandic italian japanese korean norwegian polish " "portuguese russian slovak spanish swedish turkish") d = collections.defaultdict(list) t = collections.namedtuple("Locale", "lang setlocale getlocale") for language in languages.split(): sloc = locale.setlocale(locale.LC_ALL, language) gloc = locale.getlocale() record = t(language, sloc, gloc) if gloc[0][2] == "_": d["unix-like"].append(record) else: d["windows-like"].append(record) pprint.pprint(dict(d)) ## output n:\>C:\Miniconda3\python.exe N:\temp\loc.py ------------------------------------------------------------- {'unix-like': [Locale(lang='french', setlocale='French_France.1252', getlocale=('fr_FR', 'cp1252')), Locale(lang='german', setlocale='German_Germany.1252', getlocale=('de_DE', 'cp1252')), Locale(lang='portuguese', setlocale='Portuguese_Brazil.1252', getlocale=('pt_BR', 'cp1252')), Locale(lang='spanish', setlocale='Spanish_Spain.1252', getlocale=('es_ES', 'cp1252'))], ------------------------------------------------------------- 'windows-like': [Locale(lang='chinese', setlocale="Chinese (Simplified)_People's Republic of China.936", getlocale=("Chinese (Simplified)_People's Republic of China", '936')), Locale(lang='czech', setlocale='Czech_Czech Republic.1250', getlocale=('Czech_Czech Republic', '1250')), Locale(lang='danish', setlocale='Danish_Denmark.1252', getlocale=('Danish_Denmark', '1252')), Locale(lang='dutch', setlocale='Dutch_Netherlands.1252', getlocale=('Dutch_Netherlands', '1252')), Locale(lang='english', setlocale='English_United States.1252', getlocale=('English_United States', '1252')), Locale(lang='finnish', setlocale='Finnish_Finland.1252', getlocale=('Finnish_Finland', '1252')), Locale(lang='greek', setlocale='Greek_Greece.1253', getlocale=('Greek_Greece', '1253')), Locale(lang='hungarian', setlocale='Hungarian_Hungary.1250', getlocale=('Hungarian_Hungary', '1250')), Locale(lang='icelandic', setlocale='Icelandic_Iceland.1252', getlocale=('Icelandic_Iceland', '1252')), Locale(lang='italian', setlocale='Italian_Italy.1252', getlocale=('Italian_Italy', '1252')), Locale(lang='japanese', setlocale='Japanese_Japan.932', getlocale=('Japanese_Japan', '932')), Locale(lang='korean', setlocale='Korean_Korea.949', getlocale=('Korean_Korea', '949')), Locale(lang='norwegian', setlocale='Norwegian (Bokm?l)_Norway.1252', getlocale=('Norwegian (Bokm?l)_Norway', '1252')), Locale(lang='polish', setlocale='Polish_Poland.1250', getlocale=('Polish_Poland', '1250')), Locale(lang='russian', setlocale='Russian_Russia.1251', getlocale=('Russian_Russia', '1251')), Locale(lang='slovak', setlocale='Slovak_Slovakia.1250', getlocale=('Slovak_Slovakia', '1250')), Locale(lang='swedish', setlocale='Swedish_Sweden.1252', getlocale=('Swedish_Sweden', '1252')), Locale(lang='turkish', setlocale='Turkish_Turkey.1254', getlocale=('Turkish_Turkey', '1254'))]} ---------- components: Library (Lib) messages: 235630 nosy: fomcl at yahoo.com priority: normal severity: normal status: open title: Windows getlocale unix-like with french, german, portuguese, spanish type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 21:55:47 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 09 Feb 2015 20:55:47 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1423515347.16.0.0331746010359.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Added file: http://bugs.python.org/file38062/starunpack31.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:04:13 2015 From: report at bugs.python.org (Andy Reitz) Date: Mon, 09 Feb 2015 21:04:13 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1423515853.04.0.609687540146.issue23328@psf.upfronthosting.co.za> Andy Reitz added the comment: Sure, but the question is who should do the encoding -- the user, or python? I think it would be better for python to read the password from the environment variable, and encode it before using it. I think this is what users expect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:06:45 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Feb 2015 21:06:45 +0000 Subject: [issue23426] run_setup is broken in distutils Message-ID: <1423516005.28.0.423247861021.issue23426@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: With the following simple setup.py $ cat setup.py from distutils.core import setup from distutils.command.install import install class install1(install): sub_commands = install.sub_commamnds setup(name='bug', cmdclass={'install': install1}) I get >>> from distutils.core import run_setup >>> run_setup('setup.py') Traceback (most recent call last): File "", line 1, in File "Lib/distutils/core.py", line 216, in run_setup exec(f.read(), g, l) File "", line 4, in File "", line 5, in install1 NameError: name 'install' is not defined Furthermore, on an even simpler setup.py: $ cat setup1.py from distutils.core import setup setup(name='bug') run_setup runs, but clobbers sys.argv: >>> from distutils.core import run_setup >>> run_setup('setup1.py', script_args=['--name']) bug >>> import sys;sys.argv ['setup1.py', '--name'] ---------- components: Distutils messages: 235632 nosy: belopolsky, dstufft, eric.araujo priority: normal severity: normal status: open title: run_setup is broken in distutils type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:07:54 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Feb 2015 21:07:54 +0000 Subject: [issue23426] run_setup is broken in distutils In-Reply-To: <1423516005.28.0.423247861021.issue23426@psf.upfronthosting.co.za> Message-ID: <1423516074.88.0.607665389091.issue23426@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file38063/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:08:05 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Feb 2015 21:08:05 +0000 Subject: [issue23426] run_setup is broken in distutils In-Reply-To: <1423516005.28.0.423247861021.issue23426@psf.upfronthosting.co.za> Message-ID: <1423516085.01.0.749451878655.issue23426@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file38064/setup1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:09:28 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 09 Feb 2015 21:09:28 +0000 Subject: [issue23427] Python should expose command when invoked with -c Message-ID: <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za> New submission from Jan-Philip Gehrcke: When Python is invoked with the `-c command` switch, the command string does not get exposed in sys.argv: $ python -c "import sys; print(sys.argv)" ['-c'] $ python -c "import sys; print(sys.argv)" arg1 ['-c', 'arg1'] The command string does not get exposed anywhere, AFAIK, so it is inaccessible from within Python programs. There might be application scenarios in which it is useful to access the command string, such as for debugging purposes. One scenario is when a Python session should be able to "re-spawn" itself in a subprocess (I came across this question on StackOverflow: http://stackoverflow.com/q/28412903/145400) I propose to make the command string accessible. If you agree that it might make sense, the question is *how/where* to expose it. One possible way is to retain it in sys.argv, as in this example: $ python -c "import sys; print(sys.argv)" "arg1" ['-c', 'import sys; print(sys.argv)', 'arg1'] The current sys.argv docs say > If the command was executed using the -c command line option to > the interpreter, argv[0] is set to the string '-c'. This sentence could then be adjusted to "[...], argv[0] is set to the string '-c', and argv[1] contains the command." This method breaks existing applications that are started with the -c method and that consume command line arguments in a sys.argv[1:] fashion. The tests in Lib/test/test_cmd_line.py all pass, however. A second method would be to change sys.argv[0] from '-c' to '-c command'. This would break existing applications that check for sys.argv[0] == 'c'. A third method would be to leave sys.argv as it is, and expose the command with a new attribute in the sys module. I have attached a patch for variant 1 (passes all tests in Lib/test/test_cmd_line.py), to demonstrate which code is affected: the translation from the "real" argv to sys' argv is triggered in Modules/main.c. The patch does not change behavior of '-m' (it's funny, however, that the current version of main.c at first replaces the module string with '-m', whereas the runpy module later on replaces '-m' with the path to the module file anyway.). As a side node, I figure that the sys.argv documentation should be adjusted to properly reflect the -m behavior, which is: $ ./python -m testmodule foo testmodule sys.argv: ['/data/local/pythondev/pythontip/cpython/testmodule.py', 'foo'] Let me hear your comments, and I am willing to work on code and doc patches, thanks! ---------- assignee: docs at python components: Documentation, Interpreter Core files: sys_argv_cmd.patch keywords: patch messages: 235633 nosy: docs at python, georg.brandl, haypo, jgehrcke, pitrou priority: normal severity: normal status: open title: Python should expose command when invoked with -c type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file38065/sys_argv_cmd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:12:04 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Feb 2015 21:12:04 +0000 Subject: [issue23426] run_setup is broken in distutils In-Reply-To: <1423516005.28.0.423247861021.issue23426@psf.upfronthosting.co.za> Message-ID: <1423516324.28.0.908319953922.issue23426@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file38066/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:12:26 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Feb 2015 21:12:26 +0000 Subject: [issue23426] run_setup is broken in distutils In-Reply-To: <1423516005.28.0.423247861021.issue23426@psf.upfronthosting.co.za> Message-ID: <1423516346.1.0.488711766051.issue23426@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file38063/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:14:05 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Feb 2015 21:14:05 +0000 Subject: [issue23426] run_setup is broken in distutils In-Reply-To: <1423516005.28.0.423247861021.issue23426@psf.upfronthosting.co.za> Message-ID: <1423516445.01.0.254613810555.issue23426@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- keywords: +patch Added file: http://bugs.python.org/file38067/issue23426.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:14:23 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Feb 2015 21:14:23 +0000 Subject: [issue23426] run_setup is broken in distutils In-Reply-To: <1423516005.28.0.423247861021.issue23426@psf.upfronthosting.co.za> Message-ID: <1423516463.77.0.484710300111.issue23426@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Attached patch fixes both issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:14:53 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 09 Feb 2015 21:14:53 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1423516493.74.0.768971275527.issue6634@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: I'd love to find an agreement here. I think we are quite close to getting this closed, so further input is very welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:23:14 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 09 Feb 2015 21:23:14 +0000 Subject: [issue20709] os.utime(path_to_directory): wrong documentation for Windows. In-Reply-To: <1392937056.04.0.541478480244.issue20709@psf.upfronthosting.co.za> Message-ID: <1423516994.19.0.998971733698.issue20709@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: Can these super-small doc patches get applied or should we change something? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 22:34:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Feb 2015 21:34:27 +0000 Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX platforms Message-ID: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za> New submission from STINNER Victor: Python 3.5 now requires a monotonic clock to start and has the C function _PyTime_monotonic(). Python/condvar.h and Python/thread_pthread.h should use the monotonic clock CLOCK_MONOTONIC, not the system clock CLOCK_REALTIME. See the PEP 418 for the rationale. Most platforms support pthread_condattr_setclock(CLOCK_MONOTONIC), except Mac OS X and old versions of Android. The glib looks to use pthread_cond_timedwait_relative_np() for Mac OS X: https://mail.gnome.org/archives/commits-list/2014-February/msg07782.html Note: Android had non-standard pthread_cond_timedwait_monotonic() and pthread_cond_timedwait_monotonic_np() functions. Android is not a official supported platform, and newer Android version now support pthread_condattr_setclock(). I prefer to not support old Android versions (yet). https://android-review.googlesource.com/#/c/83881/ -- For Windows, SleepConditionVariableSRW() is used on Windows 7 and newer, otherwise WaitForSingleObjectEx() is used. By the way, the check looks to be done during the compilation. I should check which Windows version is used to build Python... SleepConditionVariableSRW() and WaitForSingleObjectEx() both take a relative timeout, so they don't use (directly) the system clock. I don't see any required change for Windows. According to the PEP 418: "WaitForSingleObject() uses the same timer as GetTickCount() with the same precision." Hum, it is not possible to interrupt such wait() with CTRL+c? time.sleep() is implemented with WaitForSingleObjectEx() with _PyOS_SigintEvent(). It doesn't look to be the case here. ---------- components: Interpreter Core messages: 235637 nosy: haypo priority: normal severity: normal status: open title: Use the monotonic clock for thread conditions on POSIX platforms versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 23:01:04 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 09 Feb 2015 22:01:04 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1423519264.5.0.19328979532.issue21793@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the catch Martin, it definitely wasn't intended. I've added a patch to fix the issue and add the extra description as suggested by Ethan. ---------- Added file: http://bugs.python.org/file38068/issue21793_logfix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 23:12:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Feb 2015 22:12:06 +0000 Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX platforms In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za> Message-ID: <1423519926.17.0.158732792797.issue23428@psf.upfronthosting.co.za> STINNER Victor added the comment: > Python/condvar.h and Python/thread_pthread.h should use the monotonic clock CLOCK_MONOTONIC Oh, I forgot that Python/thread_pthread.h only uses pthread_cond_timedwait() if semaphores are emulated with mutexes+conditional variables. On most platforms, PyThread_acquire_lock_timed() is implemented with sem_timedwait(). Problem: sem_timedwait() requires an absolute time using the CLOCK_REALTIME clock and the clock is not yet configurable on Linux :-( See the feature request in the glibc: "Bug 14717 - Allow choice of clock source for calls to sem_timedwait() and pthread_mutex_timedwait()" opened in 2012: https://sourceware.org/bugzilla/show_bug.cgi?id=14717 Note: QNX provides sem_timedwait_monotonic(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 23:17:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Feb 2015 22:17:31 +0000 Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX platforms In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za> Message-ID: <1423520251.35.0.450607353838.issue23428@psf.upfronthosting.co.za> STINNER Victor added the comment: cond_timedwait_monotonic.patch: Work-in-progress patch. It doesn't change configure.ac yet to check if pthread_condattr_setclock() is supported (with CLOCK_MONOTONIC). ---------- keywords: +patch Added file: http://bugs.python.org/file38069/cond_timedwait_monotonic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 23:17:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Feb 2015 22:17:39 +0000 Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX platforms In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za> Message-ID: <1423520259.09.0.157614751164.issue23428@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 23:19:10 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Feb 2015 22:19:10 +0000 Subject: [issue23249] test_win32 fails on aarch64 In-Reply-To: <1421401283.38.0.406623425658.issue23249@psf.upfronthosting.co.za> Message-ID: <1423520350.94.0.0980524753171.issue23249@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +doko, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 23:23:11 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 09 Feb 2015 22:23:11 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1423520591.18.0.0238725937876.issue2292@psf.upfronthosting.co.za> Benjamin Peterson added the comment: For starters, it would be nice if the patch didn't make unrelated style changes (e.g. in compile.c). I also Call arguments should be unified into one list rather than distinguishing between "keywords" and "args" anymore. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 23:40:25 2015 From: report at bugs.python.org (Justin) Date: Mon, 09 Feb 2015 22:40:25 +0000 Subject: [issue23429] -5**4 returns -625 instead of 625 Message-ID: <1423521625.37.0.588744177258.issue23429@psf.upfronthosting.co.za> New submission from Justin: C:\Users\Justin>python Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> print(-5**4) -625 >>> #note...this should be 625 and not a negative 625 ---------- messages: 235642 nosy: gilbe024 priority: normal severity: normal status: open title: -5**4 returns -625 instead of 625 type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 9 23:46:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Feb 2015 22:46:42 +0000 Subject: [issue23429] -5**4 returns -625 instead of 625 In-Reply-To: <1423521625.37.0.588744177258.issue23429@psf.upfronthosting.co.za> Message-ID: <1423522002.18.0.25801645775.issue23429@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unary minus has less priority than power operator. -5**4 is equal to -(5**4), not (-5)**4. ---------- nosy: +serhiy.storchaka resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 00:05:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Feb 2015 23:05:33 +0000 Subject: [issue23424] Unicode character ends interactive session In-Reply-To: <1423514239.73.0.0631467799432.issue23424@psf.upfronthosting.co.za> Message-ID: <1423523133.23.0.894556599628.issue23424@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue looks to be a duplicate of the issue #1602: windows console doesn't print or input Unicode. It's a limitation of Windows, not of Python itself. Python supports any Unicode character if the output is written in a file (encoded in UTF-8). Workaround: use IDLE or another Python "REPL" (interactive interpreter) which has a better Unicode support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 00:09:07 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Feb 2015 23:09:07 +0000 Subject: [issue23427] Python should expose command when invoked with -c In-Reply-To: <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: sys.argv must not be changed. It would break too many Python applications. *If* we decide to expose the command line parameter in Python, we can add a new variable like sys.command for example. "command" name in used in the C code of Python, and also comes from "c" of "-c". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 00:15:37 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 09 Feb 2015 23:15:37 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1423523737.74.0.766494247363.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Thank you, Benjamin. It's my nature to keep code consistent/clean, but I realize that I can get carried away. Should I revert all incidental PEP 7 style changes? Regarding the args/keywords, where do you mean? If you're talking about compile.c, we can't merge them because the call_function operand expects to see the positional arguments below the keyword arguments on the stack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 00:17:42 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 09 Feb 2015 23:17:42 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1423523737.74.0.766494247363.issue2292@psf.upfronthosting.co.za> Message-ID: <1423523860.3352834.225361421.015763C9@webmail.messagingengine.com> Benjamin Peterson added the comment: On Mon, Feb 9, 2015, at 18:15, Neil Girdhar wrote: > > Neil Girdhar added the comment: > > Thank you, Benjamin. > > It's my nature to keep code consistent/clean, but I realize that I can > get carried away. Should I revert all incidental PEP 7 style changes? Yes, please. > > Regarding the args/keywords, where do you mean? If you're talking about > compile.c, we can't merge them because the call_function operand expects > to see the positional arguments below the keyword arguments on the stack. You can ignore this suggestion, since it occurred to me after misinterpreting the PEP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 00:41:25 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 09 Feb 2015 23:41:25 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1423525285.0.0.500022026184.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Removed incidental PEP 7 changes and reran tests. ---------- Added file: http://bugs.python.org/file38070/starunpack32.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 01:16:25 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 00:16:25 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1423527385.78.0.54287996561.issue23328@psf.upfronthosting.co.za> Martin Panter added the comment: To comply with the RFC on URLs, whoever is setting the environment variable _should_ do the encoding, and then Python will _decode_ it. But I suspect this case is more about how Python should handle an environment variable that hasn?t been encoded correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 01:16:33 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 10 Feb 2015 00:16:33 +0000 Subject: [issue23426] run_setup is broken in distutils In-Reply-To: <1423516005.28.0.423247861021.issue23426@psf.upfronthosting.co.za> Message-ID: <1423527393.16.0.281358025572.issue23426@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Added tests. ---------- stage: -> test needed Added file: http://bugs.python.org/file38071/issue23426-with-tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 01:17:31 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 10 Feb 2015 00:17:31 +0000 Subject: [issue23426] run_setup is broken in distutils In-Reply-To: <1423516005.28.0.423247861021.issue23426@psf.upfronthosting.co.za> Message-ID: <1423527451.0.0.197009395143.issue23426@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- stage: test needed -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 01:26:51 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 00:26:51 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1423528011.63.0.736268149038.issue21793@psf.upfronthosting.co.za> Martin Panter added the comment: If changing the log format, you might also want to update the comment at the top of Lib/http/server.py:53. It seems the original format was imitating , except the timestamp is slightly different. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 02:20:33 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 01:20:33 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1423531233.59.0.515976430005.issue6634@psf.upfronthosting.co.za> Martin Panter added the comment: If it were me, I?d drop the Notes and Warnings (never been a fan), and put Thing #2 first, and then Thing #1. Maybe something like ''' sys.exit([arg]) Exit from Python. . . . and it is possible to intercept the exit attempt at an outer level. When called from a thread other than the main thread, this causes the thread to exit silently instead, and is equivalent to calling :func:`thread.exit`. The optional argument *arg* can be an integer giving the exit status (defaulting to zero). Passing ``None`` is equivalent to passing zero. Any other object is printed to `stderr` and results in an exit status of 1. In particular, ``sys.exit("some error message")`` is a quick way to exit a program when an error occurs. When called from a thread other than the main thread, nothing is printed and the argument is ignored. An exit status of zero is considered ?successful termination? and any nonzero status is considered ?abnormal termination? . . . Unix programs generally use 2 for command line syntax errors and 1 for all other kinds of errors. ''' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 02:36:01 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Tue, 10 Feb 2015 01:36:01 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1423532161.41.0.749745558214.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Would anyone like to do further review of this - or commit it ;-) ? I don't think anyone has objected to the concept since I brought it up on python-ideas, but if anyone is -1, please say so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 02:50:37 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 01:50:37 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1423533037.31.0.666443384632.issue23342@psf.upfronthosting.co.za> Martin Panter added the comment: Have you seen the code review comments on the Rietveld, ? (Maybe check spam emails.) Many of the comments from the earlier patches still stand. In particular, I would like to see the ?input? default value addressed, at least for the new run() function, if not the old check_output() function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 02:51:45 2015 From: report at bugs.python.org (eryksun) Date: Tue, 10 Feb 2015 01:51:45 +0000 Subject: [issue23424] Unicode character ends interactive session In-Reply-To: <1423514239.73.0.0631467799432.issue23424@psf.upfronthosting.co.za> Message-ID: <1423533105.24.0.299289937116.issue23424@psf.upfronthosting.co.za> eryksun added the comment: This isn't a Python bug. The Windows console doesn't properly support UTF-8. See issue 1602 and Drekin's win-unicode-console, an alternative REPL based on the wide-character (UCS-2) console API. FWIW, I attached a debugger to conhost.exe under Windows 7 to inspect what's happening here. In the client, the CRT's read() function calls WinAPI ReadFile. For a console handle this calls either ReadConsoleA or (in Windows 8+) NtReadFile. Either way, most of the action happens in the server process, conhost.exe. The server's input buffer is Unicode, which gets encoded to CP 65001 (UTF-8) by calling WideCharToMultibyte. However the server incorrectly assumes the current codepage is a Windows ANSI codepage with a one-to-one mapping, i.e. that each 16-bit wchar_t maps to an 8-bit char in the current codepage. Since '?' gets UTF-8 encoded as the two-byte string b'\xc5\x82', the allocated buffer is too small by a byte. The server doesn't recover from this failure by allocating a larger buffer. It just reports back to the client process that it read 0 bytes. The CRT in turn sets the end-of-file (EOF) flag on the stdin FILE stream, which causes Python to exit 'normally'. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 02:56:09 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Tue, 10 Feb 2015 01:56:09 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1423533369.67.0.804328280127.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Aha, I hadn't seen any of those. They had indeed been caught by the spam filter. I'll look over them now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 03:00:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Feb 2015 02:00:18 +0000 Subject: [issue23361] integer overflow in winapi_createprocess In-Reply-To: <1422798703.49.0.874007534993.issue23361@psf.upfronthosting.co.za> Message-ID: <20150210020004.51382.54241@psf.io> Roundup Robot added the comment: New changeset ab2e79c6cf6b by Benjamin Peterson in branch '3.3': add overflow checking (closes #23361) https://hg.python.org/cpython/rev/ab2e79c6cf6b New changeset b82cc9180a78 by Benjamin Peterson in branch '3.4': merge 3.3 (#23361) https://hg.python.org/cpython/rev/b82cc9180a78 New changeset 76170e33f251 by Benjamin Peterson in branch 'default': merge 3.4 (#23361) https://hg.python.org/cpython/rev/76170e33f251 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 03:08:01 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 10 Feb 2015 02:08:01 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423534081.23.0.231590312916.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: I'm idealogically opposed to polymorphic interpretation of args :) Antoine, will you be ok with one __init__ and one classmethod? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 03:55:08 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Tue, 10 Feb 2015 02:55:08 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1423536908.02.0.476631245435.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Fourth version of patch, responding to review comments on Rietveld. The major changes are: - Eliminated the corner case when passing input=None to run() - now it's a real default parameter. Added a shim in check_output to keep it behaving the old way in case anything is relying on it, but I didn't document it. - The docstring of run() was shortened quite a bit by removing the examples. - Added a whatsnew entry I also made various minor fixes - thanks to everyone who found them. ---------- Added file: http://bugs.python.org/file38072/subprocess_run4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 04:10:16 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 03:10:16 +0000 Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid port values? In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za> Message-ID: <1423537816.18.0.169583474958.issue20059@psf.upfronthosting.co.za> Martin Panter added the comment: Mapping out-of-range ports to None was added in Issue 14036, though I don?t understand why that approach was taken instead of raising ValueError. Here is a patch to raise ValueError for out-of-range integer values instead. ---------- keywords: +patch Added file: http://bugs.python.org/file38073/port-ValueError.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 04:16:41 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 03:16:41 +0000 Subject: [issue14036] urlparse insufficient port property validation In-Reply-To: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za> Message-ID: <1423538201.0.0.656210546917.issue14036@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 20059 proposing to change this to raise ValueError ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 04:34:08 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 03:34:08 +0000 Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch exiting exceptions Message-ID: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za> New submission from Martin Panter: I propose changing the socket servers to not suppress exceptions that are meant to exit the interpreter. This is most applicable to single threaded servers, but my patch does the same thing for multithreading servers. It no longer catches exceptions that are not derived from the Exception class, such as KeyboardInterrupt and SystemExit. The shutdown_request() method is still called in all cases though. I also added a test for the forking server?s handle_error() method. ---------- components: Library (Lib) files: socketserver-exit.patch keywords: patch messages: 235662 nosy: vadmium priority: normal severity: normal status: open title: socketserver.BaseServer.handle_error() should not catch exiting exceptions type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38074/socketserver-exit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 04:49:23 2015 From: report at bugs.python.org (Jeff Hammel) Date: Tue, 10 Feb 2015 03:49:23 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1423540163.72.0.841842841705.issue23342@psf.upfronthosting.co.za> Jeff Hammel added the comment: A few observations in passing. I beg your pardon for not commenting after a more in depth study of the issue, but as someone that's written and managed several subprocess module front-ends, my general observations seem applicable. subprocess needs easier and more robust ways of managing input and output streams subprocess should have easier ways of managing input: file streams are fine, but plain strings would also be nice for string commands, shell should always be true. for list/Tupperware commands, shell should be false. in fact you'll get an error if you don't ensure this. instead, just have what is passed key execution (for windows, I have no idea. I'm lucky enough not to write windows software these days) subprocess should always terminate processes on program exit robustly (unless asked not too). I always have a hard time figuring out how to get processes to terminate, and how to have them not to. I realize POSIX is black magic, to some degree. I'm attaching a far from perfect front end that I currently use for reference ---------- nosy: +Jeff.Hammel Added file: http://bugs.python.org/file38075/process.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 06:05:45 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 05:05:45 +0000 Subject: [issue23416] Make urllib.parse.SplitResult etc arguments optional In-Reply-To: <1423454637.96.0.780742641159.issue23416@psf.upfronthosting.co.za> Message-ID: <1423544745.82.0.898427370671.issue23416@psf.upfronthosting.co.za> Martin Panter added the comment: Adding a patch implementing my suggested enhancement ---------- keywords: +patch versions: +Python 3.5 Added file: http://bugs.python.org/file38076/split-result-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 06:11:38 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 05:11:38 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <1423545098.83.0.676071768585.issue23400@psf.upfronthosting.co.za> Davin Potts added the comment: Attached are proposed patches for default (3.5), 3.4, and 2.7 branches. (The patch for 3.4 is identical to that for 3.5 so there are only two files in total being attached.) Regarding the exception being raised: * An ImportError is now consistently being raised across Python versions. This is believed to be a more consistent behavior than using NotImplementedError but it is debatable whether all such situations might be switched to instead use NotImplementedError in the future. * Implementation is done via a try-except around the problematic attempt to use _multiprocessing.SemLock inside the multiprocessing.queue module; it is believed this change has minimal risk. * The text of the ImportError message differs only slightly from that used in the exception highlighted in issue 3770. In 2.7, the code raising this exception is encountered in both code execution paths (as described in issue 3770 and as described here) but in 3.x various changes have broken this shared execution path. After staring at it for quite some time, I believe a less-than-simple refactoring is required to get both execution paths to encounter the same exception -- I'm punting on that for now. Ultimately, I believe the goal was not to leave the error message inspired by issue 3770 but instead to clean it up and eliminate it as part of further code improvement efforts. I believe doing so is well beyond the scope of this issue but is still something that deserves addressing. Regarding the documentation of the exception: * A note has been added to the "Reference" section's "Pipes and Queues" subsection, describing the potential for and reasons behind an ImportError being encountered. * The note that previously appeared in the "Introduction" section's "Synchronization between processes" subsection (introduced per issue 3770) has been relocated to similarly appear in the "Reference" section's "Synchronization primitives" subsection. Such a note appearing in an introduction section serves as a distraction to the reader who is hopefully learning about key concepts; it is better located in the formal documentation around the synchronization primitives where caveats and details should be conveyed. Making this change (relocation) keeps the two explanations of the ImportError arising from different places in the code better in parallel / symmetry with one another. Running through the complete battery of tests on Debian Hurd was not possible as the sequence of tests could never complete (on the default/3.5 branch at least) -- various tests were observed to hang and never complete. While Debian Hurd may not be a mainstream supported platform for Python, given its lack of important functionality such as a working sem_open implementation, it is still rather interesting as a testing platform to see how things behave when the underlying system is unable to provide numerous chunks of key functionality to Python. ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file38077/issue23400_py35_and_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 06:16:42 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 10 Feb 2015 05:16:42 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1423545402.25.0.382520975617.issue23328@psf.upfronthosting.co.za> Senthil Kumaran added the comment: In the initial report, I thought, it was mentioned that curl reads the same http_proxy variable properly. It will be good to have a correct curl test case to ascertain that. But, at all the places, where @ character is allowed in urls (netrc, git configs, I see that @ should be encoded). In that case, this bug report is more towards detecting bad urls and presenting a better error message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 06:22:34 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 05:22:34 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <1423545754.96.0.277590955004.issue23400@psf.upfronthosting.co.za> Davin Potts added the comment: To be clear, the changes to 2.7 are exclusively in the documentation. Changes to 3.4 and default (3.5) are in both documentation and code. ---------- Added file: http://bugs.python.org/file38078/issue23400_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 06:50:34 2015 From: report at bugs.python.org (=?utf-8?b?6Kix6YKx57+U?=) Date: Tue, 10 Feb 2015 05:50:34 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423547434.28.0.298739167674.issue23421@psf.upfronthosting.co.za> ??? added the comment: Attached factored patch for tests. It looks much better. :) ---------- hgrepos: +299 Added file: http://bugs.python.org/file38079/add_tarfile_cli_filetype_test_refactor.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 06:52:10 2015 From: report at bugs.python.org (=?utf-8?b?6Kix6YKx57+U?=) Date: Tue, 10 Feb 2015 05:52:10 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423547530.9.0.241941680361.issue23421@psf.upfronthosting.co.za> ??? added the comment: s/factored/refactored/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 07:39:27 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 06:39:27 +0000 Subject: [issue13323] urllib2 does not correctly handle multiple www-authenticate headers in an HTTP response In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za> Message-ID: <1423550367.37.0.265241150739.issue13323@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 15310 appears to have a more thorough patch ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 07:48:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Feb 2015 06:48:14 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <20150210064802.52870.12735@psf.io> Roundup Robot added the comment: New changeset 2a06379f6562 by Serhiy Storchaka in branch '3.4': Issue #23421: Fixed compression in tarfile CLI. Patch by wdv4758h. https://hg.python.org/cpython/rev/2a06379f6562 New changeset 5b70eb1cfad0 by Serhiy Storchaka in branch 'default': Issue #23421: Fixed compression in tarfile CLI. Patch by wdv4758h. https://hg.python.org/cpython/rev/5b70eb1cfad0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 07:49:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 06:49:38 +0000 Subject: [issue23421] tarfile module does not correctly choose compression algorithms In-Reply-To: <1423487017.12.0.640987709425.issue23421@psf.upfronthosting.co.za> Message-ID: <1423550978.56.0.282448933382.issue23421@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution. ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 07:58:07 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 06:58:07 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1423551487.88.0.807461965024.issue23328@psf.upfronthosting.co.za> Martin Panter added the comment: This should demonstrate that Curl does parse literal slashes in the username and password fields: $ http_proxy=http://user/name:pass/word at localhost:22 curl -v http://example.net/ * Trying ::1... * Connected to localhost (::1) port 22 (#0) * Proxy auth using Basic with user 'user/name' > GET http://example.net/ HTTP/1.1 > Proxy-Authorization: Basic dXNlci9uYW1lOnBhc3Mvd29yZA== > User-Agent: curl/7.40.0 > Host: example.net > Accept: */* > Connection: TE > TE: gzip > Proxy-Connection: Keep-Alive > SSH-2.0-OpenSSH_6.2 Protocol mismatch. * Recv failure: Connection reset by peer * Closing connection 0 curl: (56) Recv failure: Connection reset by peer [Exit 56] $ base64 -d <<< dXNlci9uYW1lOnBhc3Mvd29yZA== user/name:pass/word$ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 08:02:29 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 07:02:29 +0000 Subject: [issue3609] does parse_header really belong in CGI module? In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za> Message-ID: <1423551749.6.0.620163287737.issue3609@psf.upfronthosting.co.za> Martin Panter added the comment: Good idea to move this to somewhere more visible and obvious. I would have been using parse_header() much earlier if I had known it existed. However, maybe it would be better off in the ?email.message? module. The rest of the ?email.header? module only seems to be about internationalized header fields with special encodings. ---------- components: +email nosy: +barry, r.david.murray, vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 08:09:16 2015 From: report at bugs.python.org (ww0115) Date: Tue, 10 Feb 2015 07:09:16 +0000 Subject: [issue23431] Idle Application Not Responding Message-ID: <1423552156.48.0.822437580956.issue23431@psf.upfronthosting.co.za> New submission from ww0115: I recently downloaded Python 3.4 on my Mac (running on Yosemite 10.10.2) and every time I try and open Idle, the icon just keeps jumping and the application never opens. When I click on the icon after it stops jumping it just says "Application Not Responding". I've also tried downloading ActiveTCL to see if it helps but it doesn't as that application doesn't open either. Any suggestions? ---------- components: IDLE messages: 235675 nosy: ww0115 priority: normal severity: normal status: open title: Idle Application Not Responding versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 09:18:49 2015 From: report at bugs.python.org (SilentGhost) Date: Tue, 10 Feb 2015 08:18:49 +0000 Subject: [issue23431] Idle Application Not Responding In-Reply-To: <1423552156.48.0.822437580956.issue23431@psf.upfronthosting.co.za> Message-ID: <1423556329.88.0.683625367389.issue23431@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Macintosh nosy: +hynek, ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 09:43:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 08:43:39 +0000 Subject: [issue22701] Write unescaped unicode characters (Japanese, Chinese, etc) in JSON module when "ensure_ascii=False" In-Reply-To: <1414004123.6.0.971106689488.issue22701@psf.upfronthosting.co.za> Message-ID: <1423557819.4.0.450540888059.issue22701@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 09:45:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 08:45:41 +0000 Subject: [issue22819] Python3.4: xml.sax.saxutils.XMLGenerator.__init__ fails with pythonw.exe In-Reply-To: <1415445430.26.0.203405541468.issue22819@psf.upfronthosting.co.za> Message-ID: <1423557941.91.0.385897623924.issue22819@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 09:46:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 08:46:39 +0000 Subject: [issue22899] http.server.BaseHTTPRequestHandler.parse_request (TypeError: decoding str is not supported) In-Reply-To: <1416352597.9.0.2072492328.issue22899@psf.upfronthosting.co.za> Message-ID: <1423557999.13.0.583926723387.issue22899@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 09:47:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 08:47:44 +0000 Subject: [issue20394] Coverity complains on audioop In-Reply-To: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za> Message-ID: <1423558064.11.0.586284146451.issue20394@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: pending -> closed type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 09:49:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 08:49:31 +0000 Subject: [issue21231] Issue a python 3 warning when old style classes are defined. In-Reply-To: <1397530913.57.0.912065211904.issue21231@psf.upfronthosting.co.za> Message-ID: <1423558171.68.0.684364463201.issue21231@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 10:12:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 09:12:41 +0000 Subject: [issue13407] tarfile doesn't support multistream bzipped tar files In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za> Message-ID: <1423559561.36.0.803470430787.issue13407@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The tarfile module documentation needs a note similar to issue1625 which would warn about the lack of supporting some files and suggest a workaround. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, nadeem.vawda, serhiy.storchaka priority: normal -> high stage: -> needs patch status: pending -> open title: tarfile.getnames misses members again -> tarfile doesn't support multistream bzipped tar files versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 10:58:44 2015 From: report at bugs.python.org (=?utf-8?b?0JzQuNGF0LDQuNC7INCa0YDQuNCy0YPRiNC40L0=?=) Date: Tue, 10 Feb 2015 09:58:44 +0000 Subject: [issue23427] Python should expose command when invoked with -c In-Reply-To: <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za> Message-ID: <1423562324.95.0.553876600129.issue23427@psf.upfronthosting.co.za> ?????? ???????? added the comment: Hello, I have find some workaround to get actual argv, but it broken: python -c 'import ctypes; argv = ctypes.POINTER(ctypes.c_char_p)(); argc = ctypes.c_int(); ctypes.pythonapi.Py_GetArgcArgv(ctypes.byref(argc), ctypes.byref(argv)); print([argv[i] for i in xrange(0, argc.value)])' And this will output: ['python', '-c', '-c'] May be we just need to fix this behaviour, due this is error, as far as i can see. But may broke something. ---------- nosy: +??????.???????? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 11:29:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 10:29:59 +0000 Subject: [issue22364] Improve some re error messages using regex for hints In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1423564199.36.0.88073314961.issue22364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Ezio's comments. ---------- Added file: http://bugs.python.org/file38080/re_errors_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 11:54:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 10:54:53 +0000 Subject: [issue17234] python-2.7.3-r3: crash in visit_decref() In-Reply-To: <1361266544.85.0.580763984436.issue17234@psf.upfronthosting.co.za> Message-ID: <1423565693.54.0.236531183114.issue17234@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: languishing -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 12:24:42 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 10 Feb 2015 11:24:42 +0000 Subject: [issue21717] Exclusive mode for ZipFile and TarFile In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za> Message-ID: <1423567482.35.0.951613597332.issue21717@psf.upfronthosting.co.za> Berker Peksag added the comment: Updated patch. Thanks again, Serhiy. ---------- Added file: http://bugs.python.org/file38081/issue21717_tarfile_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 12:25:44 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Tue, 10 Feb 2015 11:25:44 +0000 Subject: [issue23427] Python should expose command when invoked with -c In-Reply-To: <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za> Message-ID: <1423567544.22.0.0694451911046.issue23427@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: Victor, I support the idea of sys.command. However, it would be unpopulated most of the time (e.g. set to None by default). Now, is that something we should push forward or not? I would work on a patch, but we should have an agreement first, I guess. Mihail, the original argv becomes modified in the very early bootstrap phase, and the command gets lost within that process: it gets *overwritten* with "-c", which is exactly why you are observing two "-c". This happens here: https://hg.python.org/cpython/file/default/Modules/main.c#l684 So, no, without a code change in main.c there will be no way to retain the command for later usage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 12:30:46 2015 From: report at bugs.python.org (Mihail Krivushin) Date: Tue, 10 Feb 2015 11:30:46 +0000 Subject: [issue23427] Python should expose command when invoked with -c In-Reply-To: <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za> Message-ID: <1423567846.43.0.916780620858.issue23427@psf.upfronthosting.co.za> Mihail Krivushin added the comment: Jan-Philip, yes, I see that Main.c needs modification, but we can fix orig_argv with not just assignment but with full copy. So then we can get unmodified argv. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 12:48:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 11:48:21 +0000 Subject: [issue1423] wave sunau aifc 16bit errors In-Reply-To: <1194812128.3.0.121145701122.issue1423@psf.upfronthosting.co.za> Message-ID: <1423568901.37.0.167038365664.issue1423@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue8311. Was fixed in 3.4. In 2.7 you should first convert your data to str, bytearray, array('B') or buffer. ---------- nosy: +serhiy.storchaka resolution: -> duplicate status: languishing -> closed superseder: -> wave module sets data subchunk size incorrectly when writing wav file versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 12:58:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 11:58:03 +0000 Subject: [issue1625576] add ability to specify name to os.fdopen Message-ID: <1423569483.99.0.940662052921.issue1625576@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And the name attribute of FileIO object is writable. So you can change it after calling fdopen. >>> import os >>> f = os.fdopen(2, "w") >>> f <_io.TextIOWrapper name=2 mode='w' encoding='UTF-8'> >>> f.buffer.raw.name = 'useful name' >>> f <_io.TextIOWrapper name='useful name' mode='w' encoding='UTF-8'> ---------- nosy: +serhiy.storchaka resolution: -> rejected status: languishing -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 13:29:15 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 10 Feb 2015 12:29:15 +0000 Subject: [issue23432] Duplicate content in SystemExit documentation Message-ID: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za> New submission from Berker Peksag: >From https://docs.python.org/3/library/exceptions.html#SystemExit Also, this exception derives directly from BaseException and not Exception, since it is not technically an error. and The exception inherits from BaseException instead of Exception so that it is not accidentally caught by code that catches Exception. This allows the exception to properly propagate up and cause the interpreter to exit. Here is a patch to remove the duplicate content and document the code attribute properly. ---------- assignee: docs at python components: Documentation files: systemexit.diff keywords: patch messages: 235684 nosy: berker.peksag, docs at python priority: normal severity: normal stage: patch review status: open title: Duplicate content in SystemExit documentation versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38082/systemexit.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 15:14:31 2015 From: report at bugs.python.org (Matthias Klose) Date: Tue, 10 Feb 2015 14:14:31 +0000 Subject: [issue23433] undefined behaviour in faulthandler.c, exposed by GCC 5 Message-ID: <1423577671.31.0.124602995451.issue23433@psf.upfronthosting.co.za> New submission from Matthias Klose: richi: https://github.com/nemomobile-packages/python3/blob/master/Modules/faulthandler.c#L903 richi: LD_LIBRARY_PATH=/builddir/build/BUILD/Python-3.4.2/build/debug/ /builddir/build/BUILD/Python-3.4.2/build/debug/python -E -c 'import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()' i.e. what Jakub says richi: the function certainly shouldn't return address of a local variable; dunno what would happen if you just cast that to an integer though richi: and it better should do something to avoid tail calls there richi: the if (sp < min_sp || max_sp < sp) is also undefined behavior ah, I get python segfaults building some extensions instead (but can't reproduce locally...) jakub: so what's your fix? richi: I don't have a fix, we just documented it not to be a gcc fault, we'll leave fixing to the package maintainer ah, I see richi: dunno if e.g. uintptr_t x; memcpy (&x, &sp, sizeof (x)); would DTRT and be portable enough richi: and then of course pass uintptr_t min_sp/max_sp, compare the x against that etc. well, just (uintptr_t)&buffer should be enough ---------- components: Extension Modules messages: 235685 nosy: doko priority: normal severity: normal status: open title: undefined behaviour in faulthandler.c, exposed by GCC 5 type: crash versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 15:24:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Feb 2015 14:24:15 +0000 Subject: [issue23433] undefined behaviour in faulthandler.c, exposed by GCC 5 In-Reply-To: <1423577671.31.0.124602995451.issue23433@psf.upfronthosting.co.za> Message-ID: <1423578255.26.0.853126514394.issue23433@psf.upfronthosting.co.za> STINNER Victor added the comment: faulthandler._stack_overflow() is written to crash. The comparison on stack pointers is just here to avoid an unlimited loop. A stack of 100 MB is something really large. I never seen an OS where faulthandler._stack_overflow() doesn't crash yet. Here is a patch using Py_uintptr_t instead of void*. Can someone test with GCC 5? ---------- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file38083/faulthandler_uintptr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 15:48:47 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 14:48:47 +0000 Subject: [issue22864] Add filter to multiprocessing.Pool In-Reply-To: <1415900127.9.0.960876191139.issue22864@psf.upfronthosting.co.za> Message-ID: <1423579727.86.0.445534068335.issue22864@psf.upfronthosting.co.za> Davin Potts added the comment: The points made by Travis are clear and solid. Closing as this functionality is already handled well and no exceptional situations are being argued for that would require a special case. ---------- nosy: +davin resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 15:49:53 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 14:49:53 +0000 Subject: [issue8094] Multiprocessing infinite loop In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za> Message-ID: <1423579793.38.0.291621897137.issue8094@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 15:51:10 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 14:51:10 +0000 Subject: [issue12738] Bug in multiprocessing.JoinableQueue() implementation on Ubuntu 11.04 In-Reply-To: <1313108742.86.0.818410001029.issue12738@psf.upfronthosting.co.za> Message-ID: <1423579870.79.0.360065620027.issue12738@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 15:51:22 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 14:51:22 +0000 Subject: [issue23072] 2.7.9 multiprocessing compile conflict In-Reply-To: <1418794673.39.0.221318823729.issue23072@psf.upfronthosting.co.za> Message-ID: <1423579882.91.0.380191273605.issue23072@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 15:51:26 2015 From: report at bugs.python.org (Mihail Krivushin) Date: Tue, 10 Feb 2015 14:51:26 +0000 Subject: [issue23427] Python should expose command when invoked with -c In-Reply-To: <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za> Message-ID: <1423579886.68.0.405725662274.issue23427@psf.upfronthosting.co.za> Changes by Mihail Krivushin : ---------- versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 15:51:38 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 14:51:38 +0000 Subject: [issue21429] Input.output error with multiprocessing In-Reply-To: <1399220691.1.0.523621963732.issue21429@psf.upfronthosting.co.za> Message-ID: <1423579898.04.0.635611612905.issue21429@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 15:54:47 2015 From: report at bugs.python.org (Myroslav Opyr) Date: Tue, 10 Feb 2015 14:54:47 +0000 Subject: [issue23434] RFC6266 support Message-ID: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za> New submission from Myroslav Opyr: cgi.FieldStorage has problems parsing the multipart/form-data request with file fields with non-latin filenames. It drops the filename parameter formatted according to RFC6266 [1] (most modern browsers do). There is already python implementation for that RFC in rfc6266 module [2]. Ref: [1] https://tools.ietf.org/html/rfc6266 [2] https://pypi.python.org/pypi/rfc6266 ---------- components: Library (Lib) messages: 235688 nosy: Myroslav.Opyr priority: normal severity: normal status: open title: RFC6266 support type: enhancement versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 16:09:18 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 15:09:18 +0000 Subject: [issue9122] Problems with multiprocessing, Python embedding and Windows In-Reply-To: <1277847282.9.0.57284514454.issue9122@psf.upfronthosting.co.za> Message-ID: <1423580958.1.0.985778776417.issue9122@psf.upfronthosting.co.za> Davin Potts added the comment: Closing on the basis that: 1. Richard provided a proposed workaround but did not receive a response from the OP in 1.5 years. 2. Issues encountered by the OP may have been addressed in part by changes in the way import works in the past 4.5 years. 3. This issue has been effectively "pending" (though not formally marked as such) for more than a year without further information being received from the OP. ---------- nosy: +davin status: open -> pending type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 16:09:39 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 15:09:39 +0000 Subject: [issue9122] Problems with multiprocessing, Python embedding and Windows In-Reply-To: <1277847282.9.0.57284514454.issue9122@psf.upfronthosting.co.za> Message-ID: <1423580979.63.0.190552776971.issue9122@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- resolution: -> out of date stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 16:19:07 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 10 Feb 2015 15:19:07 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1423528011.63.0.736268149038.issue21793@psf.upfronthosting.co.za> Message-ID: <60F726C8-5D21-4243-A8D5-7C6E6C87375D@gmail.com> Demian Brecht added the comment: I?ve reverted the patch to use the old format. The main reason being that plain ints can still be used in most cases as values for code, in which case logging will be inconsistent with cases using the enum. ---------- Added file: http://bugs.python.org/file38084/issue21793_logfix_1.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e548ab4ce71d Lib/http/__init__.py --- a/Lib/http/__init__.py Mon Feb 09 19:49:00 2015 +0000 +++ b/Lib/http/__init__.py Tue Feb 10 07:15:09 2015 -0800 @@ -24,6 +24,11 @@ obj.description = description return obj + def __str__(self): + # this is mainly for backwards compatibility, where constant values + # would be output. + return '{:d}'.format(self) + # informational CONTINUE = 100, 'Continue', 'Request received, please continue' SWITCHING_PROTOCOLS = (101, 'Switching Protocols', diff -r e548ab4ce71d Lib/test/test_httpservers.py --- a/Lib/test/test_httpservers.py Mon Feb 09 19:49:00 2015 +0000 +++ b/Lib/test/test_httpservers.py Tue Feb 10 07:15:09 2015 -0800 @@ -6,7 +6,7 @@ from http.server import BaseHTTPRequestHandler, HTTPServer, \ SimpleHTTPRequestHandler, CGIHTTPRequestHandler -from http import server +from http import server, HTTPStatus import os import sys @@ -235,6 +235,27 @@ self.assertEqual(int(res.getheader('Content-Length')), len(data)) +class RequestHandlerLoggingTestCase(BaseTestCase): + class request_handler(BaseHTTPRequestHandler): + protocol_version = 'HTTP/1.1' + default_request_version = 'HTTP/1.1' + + def do_GET(self): + self.send_response(HTTPStatus.OK) + self.end_headers() + + def test_get(self): + self.con = http.client.HTTPConnection(self.HOST, self.PORT) + self.con.connect() + + with support.captured_stderr() as err: + self.con.request('GET', '/') + self.con.getresponse() + + self.assertTrue( + err.getvalue().endswith('"GET / HTTP/1.1" 200 -\n')) + + class SimpleHTTPServerTestCase(BaseTestCase): class request_handler(NoLogRequestHandler, SimpleHTTPRequestHandler): pass @@ -764,6 +785,7 @@ cwd = os.getcwd() try: support.run_unittest( + LoggingRequestHandlerTestCase, BaseHTTPRequestHandlerTestCase, BaseHTTPServerTestCase, SimpleHTTPServerTestCase, From report at bugs.python.org Tue Feb 10 16:34:34 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 10 Feb 2015 15:34:34 +0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1423582474.03.0.0152411629871.issue2211@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Demian is this of any interest to you? ---------- nosy: +BreamoreBoy, demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 17:00:19 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 16:00:19 +0000 Subject: [issue11240] Running unit tests in a command line tool leads to infinite loop with multiprocessing on Windows In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za> Message-ID: <1423584019.03.0.267345113111.issue11240@psf.upfronthosting.co.za> Davin Potts added the comment: In some (but not necessarily all) circumstances, the multiprocessing module is now (in 2.7 and 3.x) able to detect the "infinite spawning" behavior described due to unsafe importing of the main module on Windows. The resulting error message looks like this: RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase. This probably means that you are not using fork to start your child processes and you have forgotten to use the proper idiom in the main module: if __name__ == '__main__': freeze_support() ... The "freeze_support()" line can be omitted if the program is not going to be frozen to produce an executable. Hopefully this behavior and the resulting message will both alert developers when such a problem is introduced in a project and communicate to them what the problem is. Giant blinking red letters aside, hopefully this pragmatic solution will do a better job of educating and helping developers notice and deal with such issues. In the combinatoric explosion of possibilities that combine nosetest-binaries with PyDev with other useful dev tools, if this error message is being suppressed or otherwise not shared with the end user of those tools, that would warrant opening an issue with that tool. ---------- nosy: +davin resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 17:06:46 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 10 Feb 2015 16:06:46 +0000 Subject: [issue12954] Multiprocessing logging under Windows In-Reply-To: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za> Message-ID: <1423584406.41.0.389511498576.issue12954@psf.upfronthosting.co.za> Davin Potts added the comment: Closing per the feedback of the OP and secondary contributor to the issue. Kudos to the reporters for such nice follow-up. ---------- nosy: +davin resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 17:13:57 2015 From: report at bugs.python.org (Justin) Date: Tue, 10 Feb 2015 16:13:57 +0000 Subject: [issue23429] -5**4 returns -625 instead of 625 In-Reply-To: <1423521625.37.0.588744177258.issue23429@psf.upfronthosting.co.za> Message-ID: <1423584837.25.0.268308177103.issue23429@psf.upfronthosting.co.za> Justin added the comment: I think there is a misunderstanding of precedence here. If we had an operation were -1 * 5**4, I could fully understand the statement of precedence. However, in the absence of the "-1 *", the -5 becomes a single atom. For example: >>> myVal = -5 >>> myVal**4 625 >>> # not -625 because it is treated as a single atom. The statement -5**4 - 20, should yield the same result and yet, it does not. >>> -5**4 - 20 -645 >>> 5**4 - 20 605 >>> Let's take the reverse side of this take 4**-2, if precedence is to hold the same way, why would this not be 16 instead of the correct answer of 0.0625. In this instance, the unary sign all of a sudden jumped in precedence and became a single atom. >>> 4**-2 0.0625 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 17:14:28 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 10 Feb 2015 16:14:28 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1423584868.04.0.934242332477.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: My apologies for the delay, but I've now reviewed the proposed patch. With a fresh outlook after taking a bit of time off, I'm not sure anymore that this is the best way of going about solving this problem. The main reason being that we now have two errors that effectively mean the same thing: The remote socket has encountered some error condition. I understand that ConnectionClosed was added to maintain backwards compatibility with the BadStatusLine error, but I'm beginning to think that what really should be done is that backwards compatibility /should/ be broken as (in my mind) it's one of those cases where the backwards compatible solution may introduce just as many issues as it solves. The root issue here (or at least what it has turned into) is that BadStatusLine is incorrectly raised when EOF is encountered when reading the status line. In light of that, I think that simply raising a ConnectionError in _read_status where line is None is the right way to fix this issue. Not only is it consistent with other cases where the remote socket is closed (i.e. when reading the response body), but it's removing the need for the addition of a potentially confusing exception. I'm not 100% what the policy is around backwards introducing backwards incompatible changes is, but I really think that this is one of those few cases where it really should be broken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 17:16:22 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 10 Feb 2015 16:16:22 +0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1423584982.27.0.0689636157506.issue2211@psf.upfronthosting.co.za> Demian Brecht added the comment: @Mark: Sure, but not super high priority. Thanks for pointing it out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 18:43:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 17:43:16 +0000 Subject: [issue23429] -5**4 returns -625 instead of 625 In-Reply-To: <1423521625.37.0.588744177258.issue23429@psf.upfronthosting.co.za> Message-ID: <1423590195.99.0.000168162438126.issue23429@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, -5 is not an atom. See The Python Language Reference [1]: """Note that numeric literals do not include a sign; a phrase like -1 is actually an expression composed of the unary operator ?-? and the literal 1.""" [1] https://docs.python.org/3/reference/lexical_analysis.html#numeric-literals ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 18:53:18 2015 From: report at bugs.python.org (Justin) Date: Tue, 10 Feb 2015 17:53:18 +0000 Subject: [issue23429] -5**4 returns -625 instead of 625 In-Reply-To: <1423521625.37.0.588744177258.issue23429@psf.upfronthosting.co.za> Message-ID: <1423590798.19.0.992807661369.issue23429@psf.upfronthosting.co.za> Justin added the comment: Thank you for the link. I can understand the language definition and I can accept it at face value. The confusion I have is that it does not appear to be consistent. My example of -5**4 vs 4**-2 would both have literals with a unary sign. One works as expected, whereas the other one does not. Granted that I am new to Python, although well experience in development and programming; I will conceded to those more experienced in Python development that it is as it should be. Regards, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 19:29:41 2015 From: report at bugs.python.org (Ivailo Monev) Date: Tue, 10 Feb 2015 18:29:41 +0000 Subject: [issue23435] installation with full path as prefix incomplete Message-ID: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> New submission from Ivailo Monev: Installing Python with prefix that equals "/" seems to not install the dymic libraries like _collections. The steps I performed to install it: ./configure --prefix=/ \ --with-threads \ --enable-shared \ --enable-ipv6 \ --with-system-ffi \ --with-system-expat make make install I saw that during the installation that the sharedinstall rule from Makefile.pre (originally defined in Makefile.pre.in) fails to remove $(DESTDIR)$(DESTSHARED)/_sysconfigdata.py* so I manually created the leading directory and touched the file it was looking for (I could've modified Makefile.pre too) and it actually worked - lib-dynload was created and the .so files where installed in it. I have tried using empty string as prefix but that causes runtime issues since - Python is not able to find the site-packages directory. Cheers! ---------- messages: 235699 nosy: Ivailo.Monev priority: normal severity: normal status: open title: installation with full path as prefix incomplete _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 19:59:15 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 10 Feb 2015 18:59:15 +0000 Subject: [issue23434] RFC6266 support In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za> Message-ID: <1423594755.64.0.0731528638741.issue23434@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 20:16:26 2015 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 10 Feb 2015 19:16:26 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1423595786.97.0.323931577969.issue21793@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: -eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 20:30:43 2015 From: report at bugs.python.org (Kevin Rocard) Date: Tue, 10 Feb 2015 19:30:43 +0000 Subject: [issue23436] xml.dom.minidom.Element.ownerDocument is hiden Message-ID: <1423596643.73.0.960398071264.issue23436@psf.upfronthosting.co.za> New submission from Kevin Rocard: Extracted from xml.dom.minidom: ~~~ Node(...): ... ownerDocument = None ... Element(Node): __slots__=('ownerDocument', ...) ... ~~~ As Element declares an ownerDocument attribute in __slots__, Node's ownerDocument attribute is hidden: ~~~ class B: b=1; class D(B): __slots__={'b'} D().b -> AttributeError ~~~ This leads to a strange behaviour were accessing a base attribute fails with an attribute error. Should the Node.ownerDocument attribute not be removed? Or its name removed from the Element.__slots__ list? Ie have the attribute in the base or the derivative, but not both. Independent note: says: > When inheriting from a class without __slots__ [Node], the __dict__ attribute of that class will always be accessible, so a __slots__ definition in the subclass [Element] is meaningless. So as for as I understand Element.__slots__ does not reduce the Element() footprint (it was introduced for that). ---------- components: Library (Lib) messages: 235700 nosy: krocard priority: normal severity: normal status: open title: xml.dom.minidom.Element.ownerDocument is hiden type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 21:09:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 20:09:31 +0000 Subject: [issue22883] Get rid of references to PyInt in Py3 sources In-Reply-To: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za> Message-ID: <1423598971.26.0.170683267975.issue22883@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation -Extension Modules, Interpreter Core nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 21:10:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 20:10:30 +0000 Subject: [issue23383] Clean up bytes formatting In-Reply-To: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> Message-ID: <1423599030.44.0.735853997866.issue23383@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 21:46:26 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 10 Feb 2015 20:46:26 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows Message-ID: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> New submission from Paul Moore: Patch to make the user scripts directory on Windows %APPDATA%\Python\PythonXY\Scripts rather than %APPDATA%\Python\Scripts. See the thread "PEP 370 - per-user scripts directory on Windows" (Feb 10 2015) on python-dev for discussion, but essentially this is to ensure that different Python versions cannot overwrite each others' package scripts when packages are installed into the user site directory. Not tested, as I don't yet have Visual Studio 2015 installed. I'll try to obtain and install it when I get the chance. ---------- assignee: steve.dower components: Windows files: userscripts.patch keywords: needs review, patch messages: 235702 nosy: pmoore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Make user scripts directory versioned on Windows type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38085/userscripts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 21:49:08 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 10 Feb 2015 20:49:08 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <1423601348.44.0.109988525457.issue23437@psf.upfronthosting.co.za> Steve Dower added the comment: You should be able to apply the patch to 3.5.0a1 and test it that way easily enough. Other than the doc changes, it's just .py files. (Building 3.5 with earlier VS versions is also okay right now.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 21:57:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 20:57:44 +0000 Subject: [issue23383] Clean up bytes formatting In-Reply-To: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> Message-ID: <1423601864.0.0.325980887148.issue23383@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Victor's comments. ---------- Added file: http://bugs.python.org/file38086/bytes_format_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 21:59:27 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 10 Feb 2015 20:59:27 +0000 Subject: [issue23427] Python should expose command when invoked with -c In-Reply-To: <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za> Message-ID: <1423601967.13.0.801675322941.issue23427@psf.upfronthosting.co.za> Zachary Ware added the comment: Rather than add a variable to sys that will be empty 99% of the time, I think I'd rather stick a '__command__' constant in the __main__ module namespace when running with '-c' (think of '__file__'). You could then get at it elsewhere with 'from __main__ import __command__' (probably wrapped in a try/except ImportError, since it will usually not exist). This should probably be discussed on python-ideas. (Removing all versions but 3.5, as this is a feature request.) ---------- assignee: docs at python -> components: -Documentation nosy: +zach.ware versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 22:10:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 21:10:28 +0000 Subject: [issue23383] Clean up bytes formatting In-Reply-To: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> Message-ID: <1423602628.43.0.641161367489.issue23383@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file38086/bytes_format_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 22:10:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 21:10:56 +0000 Subject: [issue23383] Clean up bytes formatting In-Reply-To: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> Message-ID: <1423602656.82.0.0778531062075.issue23383@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Eliminated tabs. ---------- Added file: http://bugs.python.org/file38087/bytes_format_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 22:15:24 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 21:15:24 +0000 Subject: [issue23434] RFC6266 support (Content-Disposition for HTTP) In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za> Message-ID: <1423602924.32.0.809159012393.issue23434@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium title: RFC6266 support -> RFC6266 support (Content-Disposition for HTTP) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 22:18:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 21:18:08 +0000 Subject: [issue23383] Clean up bytes formatting In-Reply-To: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> Message-ID: <1423603088.62.0.098821106366.issue23383@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your reviews and suggestions Martin and Victor. If Ethan has no objections I'll commit the patch soon. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 22:20:34 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 10 Feb 2015 21:20:34 +0000 Subject: [issue23383] Clean up bytes formatting In-Reply-To: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> Message-ID: <1423603234.94.0.686039431203.issue23383@psf.upfronthosting.co.za> Ethan Furman added the comment: As long as it works I have no objections. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 22:23:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Feb 2015 21:23:48 +0000 Subject: [issue23383] Clean up bytes formatting In-Reply-To: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> Message-ID: <20150210212345.25494.77494@psf.io> Roundup Robot added the comment: New changeset 4883f9046b10 by Serhiy Storchaka in branch 'default': Issue #23383: Cleaned up bytes formatting. https://hg.python.org/cpython/rev/4883f9046b10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 22:41:01 2015 From: report at bugs.python.org (Daniel Lenski) Date: Tue, 10 Feb 2015 21:41:01 +0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1423604461.47.0.376796699515.issue1818@psf.upfronthosting.co.za> Daniel Lenski added the comment: Here's the class I have been using for reading namedtuples from CSV files: from collections import namedtuple from itertools import imap import csv class CsvNamedTupleReader(object): __slots__ = ('_r', 'row', 'fieldnames') def __init__(self, *args, **kwargs): self._r = csv.reader(*args, **kwargs) self.row = namedtuple("row", self._r.next()) self.fieldnames = self.row._fields def __iter__(self): #FIXME: how about this? return imap(self.row._make, self._r[:len(self.fieldnames)] return imap(self.row._make, self._r) dialect = property(lambda self: self._r.dialect) line_num = property(lambda self: self._r.line_num) This class wraps csv.reader since it doesn't seem to be possible to inherit from it. It uses itertools.imap to iterate over the rows output by csv.reader and convert them to the namedtuple class. One thing that needs fixing (marked with FIXME above) is what to do in the case of a row which has more fields than the header row. The simplest solution is simply to truncate such a row, but perhaps more options are needed, similar to those offered by DictReader. ---------- nosy: +dlenski _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 22:47:17 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 21:47:17 +0000 Subject: [issue23432] Duplicate content in SystemExit documentation In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za> Message-ID: <1423604837.68.0.155163802702.issue23432@psf.upfronthosting.co.za> Martin Panter added the comment: The new text changes ?the associated value? to ?the value passed to [the] :func:`sys.exit` call?. There seems to be a trend in removing documentation of exception constructor arguments; is this intentional? In my code I tend to raise SystemExit() directly rather than importing the ?sys? module and calling sys.exit(). ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 22:54:27 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 21:54:27 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1423605267.53.0.741528501917.issue21793@psf.upfronthosting.co.za> Martin Panter added the comment: New logfix patch looks good. I would have written format(self) or format(self, 'd') instead of '{:d}'.format(self), but that?s no big deal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 23:00:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Feb 2015 22:00:54 +0000 Subject: [issue20416] Marshal: performance regression with versions 3 and 4 In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1423605654.45.0.901186677012.issue20416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Update patch addresses Victor's comments. ---------- Added file: http://bugs.python.org/file38088/marshal_hashtable_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 23:01:22 2015 From: report at bugs.python.org (pyed) Date: Tue, 10 Feb 2015 22:01:22 +0000 Subject: [issue23438] HTMLParser don't know how to deal with 'ampersand' Message-ID: <1423605682.36.0.595483679722.issue23438@psf.upfronthosting.co.za> New submission from pyed: the attached file use example from : https://docs.python.org/3/library/html.parser.html and it will show different cases where HTMLParser fail to parse '&' and '&' ---------- components: Library (Lib) files: htmlparser_bugs.py messages: 235714 nosy: pyed priority: normal severity: normal status: open title: HTMLParser don't know how to deal with 'ampersand' type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file38089/htmlparser_bugs.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 23:02:38 2015 From: report at bugs.python.org (pyed) Date: Tue, 10 Feb 2015 22:02:38 +0000 Subject: [issue23438] HTMLParser doesn't know how to deal with 'ampersand' In-Reply-To: <1423605682.36.0.595483679722.issue23438@psf.upfronthosting.co.za> Message-ID: <1423605758.76.0.949274020823.issue23438@psf.upfronthosting.co.za> Changes by pyed : ---------- title: HTMLParser don't know how to deal with 'ampersand' -> HTMLParser doesn't know how to deal with 'ampersand' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 23:31:11 2015 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 10 Feb 2015 22:31:11 +0000 Subject: [issue23438] HTMLParser doesn't know how to deal with 'ampersand' In-Reply-To: <1423605682.36.0.595483679722.issue23438@psf.upfronthosting.co.za> Message-ID: <1423607471.01.0.666570782554.issue23438@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: & is an entity reference. Either pass "convert_charrefs=True" to the constructor, or implement a method "def handle_entityref(self, data)" to receive them as events. https://docs.python.org/3.4/library/html.parser.html ---------- nosy: +amaury.forgeotdarc resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 23:31:44 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 10 Feb 2015 22:31:44 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <1423607504.78.0.730461931032.issue23437@psf.upfronthosting.co.za> Paul Moore added the comment: Cool, I've just run the tests by manually patching a 3.5a0 install. No extra failures, so things look fine. (Interestingly, before patching, test_site "altered the execution environment" but afterwards it didn't - it just succeeded. I don't know if that means anything, but I'm inclined not to worry as it definitely didn't fail.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 23:33:31 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 10 Feb 2015 22:33:31 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <1423607611.89.0.186888356993.issue23437@psf.upfronthosting.co.za> Steve Dower added the comment: How do pip & co. handle the change? I assume they just look in sysconfig and don't think too much about the path... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 23:39:26 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 10 Feb 2015 22:39:26 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <1423607966.75.0.542751869596.issue23437@psf.upfronthosting.co.za> Paul Moore added the comment: Sorry, yes pip just installs into %APPDATA%\Python\Python35\Scripts with no issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 23:41:51 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 22:41:51 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test Message-ID: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> New submission from Martin Panter: This patch was split off my patch for Issue 3566, since it should be less controversial. It adds the HTTPMessage class and the parse_headers() function to __all__. I?m not too sure on the status of the parse_headers() function. It is not mentioned in the ?http.client? documentation, but is referenced by the ?http.server? module?s BaseHTTPRequestHandler.headers entry. Perhaps it should be left unexported? ---------- components: Library (Lib) messages: 235719 nosy: vadmium priority: normal severity: normal status: open title: Fixed http.client.__all__ and added a test type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 10 23:42:04 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 10 Feb 2015 22:42:04 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1423608124.93.0.142081242081.issue23439@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- keywords: +patch Added file: http://bugs.python.org/file38090/http.client-all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 00:08:24 2015 From: report at bugs.python.org (Mahmoud Hashemi) Date: Tue, 10 Feb 2015 23:08:24 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423609704.46.0.287540976693.issue17911@psf.upfronthosting.co.za> Mahmoud Hashemi added the comment: Hey all, great to see this being worked on so diligently for so long. Having worked in this area for a while (at home and at PayPal), we've got a few learnings to share: 1) linecache is textbook not-threadsafe. For example, https://hg.python.org/cpython/file/default/Lib/linecache.py#l38 For a lightweight traceback wrapper to be concurrency-friendly, we've had to catch KeyErrors, like so: https://github.com/mahmoud/boltons/blob/master/boltons/tbutils.py#L115 It's kind of a blanket approach, but maybe we could make a separate issue and help out with a linecache refresh? 2) We use something like (filename, lineno) in our DeferredLine class, but for very lightweight areas (e.g., greenlet creation) we just save a reference to the code object, as the additional attribute accesses do end up showing up in the profiles. 3) Generally we've found the APIs in TracebackInfo here to be pretty sufficient/functional: https://github.com/mahmoud/boltons/blob/master/boltons/tbutils.py#L134 Let me know if you've got any questions on that, and keep up the good work! ---------- nosy: +mahmoud _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 01:09:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 11 Feb 2015 00:09:12 +0000 Subject: [issue20416] Marshal: performance regression with versions 3 and 4 In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1423613352.08.0.494271631961.issue20416@psf.upfronthosting.co.za> STINNER Victor added the comment: Except of the minor suggestion that I added on the review, the patch looks good the me. It's quite simple and makes dumps() 34% faster (for protocol 4). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 01:09:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 11 Feb 2015 00:09:58 +0000 Subject: [issue20416] Marshal: performance regression with versions 3 and 4 In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1423613398.32.0.453642058571.issue20416@psf.upfronthosting.co.za> STINNER Victor added the comment: (I didn't reproduce the benchmark, I just used Serhy numbers. I guess that using memcpy() doesn't make the code slower.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 04:09:23 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 11 Feb 2015 03:09:23 +0000 Subject: [issue23431] Idle Application Not Responding In-Reply-To: <1423552156.48.0.822437580956.issue23431@psf.upfronthosting.co.za> Message-ID: <1423624163.21.0.48112325065.issue23431@psf.upfronthosting.co.za> Ned Deily added the comment: Try launching IDLE from a Terminal window command line shell with: /usr/local/bin/python3.4 -m idlelib and see if any error messages are reported. Also please report what is printed when this is run in a command shell: /usr/local/bin/python3.4 -c 'import sys;print(sys.version)' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 05:05:25 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 04:05:25 +0000 Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags and seaches In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za> Message-ID: <1423627525.63.0.26327214864.issue18304@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 8583 for a proposal that would apparently allow all namespaces to be ignored ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 05:06:49 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 04:06:49 +0000 Subject: [issue8583] Hardcoded namespace_separator in the cElementTree.XMLParser In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za> Message-ID: <1423627609.01.0.520488735277.issue8583@psf.upfronthosting.co.za> Martin Panter added the comment: Also Issue 18304 for more discussion on simplifying namespaces ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 05:10:29 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 11 Feb 2015 04:10:29 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1423627829.89.0.0910831486368.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Jeff: This makes it somewhat easier to handle input and output as strings instead of streams. Most of the functionality was already there, but this makes it more broadly useful. It doesn't especially address your other points, but I'm not aiming to completely overhaul subprocess. > for string commands, shell should always be true. for list/Tupperware commands, shell should be false I wondered why this is not the case before, but on Windows a subprocess is actually launched by a string, not a list. And on POSIX, a string without shell=True is interpreted like a one-element list, so you can do e.g. Popen('ls') instead of Popen(['ls']). Changing that would probably break backwards compatibility in unexpected ways. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 06:09:44 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 11 Feb 2015 05:09:44 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423631384.32.0.77380818037.issue23435@psf.upfronthosting.co.za> Ned Deily added the comment: Without more information it is hard to provide a meaningful response. You don't say which version of Python nor which platform you are trying to install on. Be aware that the default for --prefix is '/usr/local'. On most POSIX platforms, you should not be trying to use --prefix='/'; I believe that would attempt to install into the /bin, /lib, /install, et al which is very likely *not* what you want to do and could be harmful to your system. If you are trying to install into the standard system locations (usually also not a good idea if it conflicts with the platform's own packages), you would use --prefix='/usr'. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 06:10:51 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 11 Feb 2015 05:10:51 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423631451.71.0.784159645026.issue23435@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- Removed message: http://bugs.python.org/msg235727 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 06:11:09 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 11 Feb 2015 05:11:09 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423631469.51.0.756154125154.issue23435@psf.upfronthosting.co.za> Ned Deily added the comment: Without more information it is hard to provide a meaningful response. You don't say which version of Python nor which platform you are trying to install on. Be aware that the default for --prefix is '/usr/local'. On most POSIX platforms, you should not be trying to use --prefix='/'; I believe that would attempt to install into the /bin, /lib, /include, et al which is very likely *not* what you want to do and could be harmful to your system. If you are trying to install into the standard system locations (usually also not a good idea if it conflicts with the platform's own packages), you would use --prefix='/usr'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 06:35:41 2015 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 11 Feb 2015 05:35:41 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <1423632941.42.0.844056064275.issue23437@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 07:08:43 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 06:08:43 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1423634923.85.0.604179098132.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for helping with this Demian. The idea of raising the same exception in all cases is new to me. Initially I was opposed, but it is starting to make sense. Let me consider it some more. Here are some cases that could trigger this exception: 1. EOF before receiving any status line. This is the most common case. Currently triggers BadStatusLine. 2. EOF in the middle of the status line. Triggers BadStatusLine, or is treated as an empty set of header fields. 3. EOF in the middle of a header line, or before the terminating blank line. Ignored, possibly with HTTPMessage.defects set. 4. EOF after receiving 100 Continue response, but before the final response. Currently triggers the same BadStatusLine. 5. ConnectionReset anywhere before the blank line terminating the header section. In all those cases it should be okay to automatically retry an idempotent request. With non-idempotent requests, retrying in these cases seems about equally dangerous. For contrast, some related cases that can still be handled differently: 6. Connection reset or broken pipe in the request() method, since the server can still send a response 7. Unexpected EOF or connection reset when reading the response body. Perhaps this could also be handled with a similar ConnectionError exception. Currently IncompleteRead is raised for EOF, at least in most cases. IncompleteRead has also been suggested as an alternative to BadStatusLine in the past. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 08:42:51 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 07:42:51 +0000 Subject: [issue23440] Extend http.server.SimpleHTTPRequestHandler testing Message-ID: <1423640571.78.0.653754704207.issue23440@psf.upfronthosting.co.za> New submission from Martin Panter: These are some additions to the ?http.server? module tests. It is an updated version of index-test.2.patch that I posted at Issue 23255. * Tests that index.html is served, rather than an automatic directory listing * Tests that there is no extra data sent after the response ---------- components: Tests files: simple-http-testing.patch keywords: patch messages: 235730 nosy: vadmium priority: normal severity: normal status: open title: Extend http.server.SimpleHTTPRequestHandler testing type: enhancement Added file: http://bugs.python.org/file38091/simple-http-testing.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 08:45:28 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 07:45:28 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1423640728.62.0.366132431554.issue23255@psf.upfronthosting.co.za> Martin Panter added the comment: Opened Issue 23440 for my test changes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 09:53:52 2015 From: report at bugs.python.org (Myroslav Opyr) Date: Wed, 11 Feb 2015 08:53:52 +0000 Subject: [issue23434] RFC6266 support (Content-Disposition for HTTP) In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za> Message-ID: <1423644832.9.0.760399107727.issue23434@psf.upfronthosting.co.za> Myroslav Opyr added the comment: In test_cgi.py-v2.7.5-rfc6266_filename.patch there is a patch to test_cgi.py (Python 2.7.5) that reveals the issue. ---------- keywords: +patch Added file: http://bugs.python.org/file38092/test_cgi.py-v2.7.5-rfc6266_filename.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 11:21:44 2015 From: report at bugs.python.org (Armin Rigo) Date: Wed, 11 Feb 2015 10:21:44 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces Message-ID: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> New submission from Armin Rigo: In the interactive prompt: >>> if 1: ... Pressing tab here should just insert 4 spaces. It makes no sense to display all 500 possible "completions" of the empty word, and using tab to indent is a very common feature of any editor with a Python mode. Patch attached. ---------- components: Library (Lib) files: rlcompleter_tab2space.diff keywords: patch messages: 235733 nosy: arigo priority: normal severity: normal status: open title: rlcompleter: tab on empty prefix => insert spaces type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file38093/rlcompleter_tab2space.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 11:32:26 2015 From: report at bugs.python.org (Myroslav Opyr) Date: Wed, 11 Feb 2015 10:32:26 +0000 Subject: [issue23434] RFC6266 support (Content-Disposition for HTTP) In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za> Message-ID: <1423650746.38.0.437830847902.issue23434@psf.upfronthosting.co.za> Myroslav Opyr added the comment: As a proof of concept there is fix for the issue powered by rfc6266 library[1]. See cgi.py-v2.7.5-rfc6266_filename.patch References: [1] https://pypi.python.org/pypi/rfc6266 ---------- Added file: http://bugs.python.org/file38094/cgi.py-v2.7.5-rfc6266_filename.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 11:50:29 2015 From: report at bugs.python.org (Myroslav Opyr) Date: Wed, 11 Feb 2015 10:50:29 +0000 Subject: [issue23434] RFC6266 support (Content-Disposition for HTTP) In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za> Message-ID: <1423651829.82.0.948716158231.issue23434@psf.upfronthosting.co.za> Changes by Myroslav Opyr : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 11:56:25 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 10:56:25 +0000 Subject: [issue14782] Tab-completion of callables displays opening paren In-Reply-To: <1336738586.42.0.602618902889.issue14782@psf.upfronthosting.co.za> Message-ID: <1423652185.6.0.394871984272.issue14782@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 11:58:28 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 10:58:28 +0000 Subject: [issue10351] Add autocompletion for keys in dictionaries In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za> Message-ID: <1423652308.4.0.84599886254.issue10351@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 12:06:06 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 11:06:06 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1423652766.54.0.910729908233.issue23441@psf.upfronthosting.co.za> Martin Panter added the comment: Main bug report: Issue 22086. Can you say if this works when the cursor is not at the start of the entry? E.g. after an existing tab (Ctrl-V Tab on GNU readline) or space, or after an embedded newline (Ctrl-V Enter). What happens if you press backspace after pressing tab? Do you have to backspace four times? Another options is to insert a literal tab code instead of spaces. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 12:06:58 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 11:06:58 +0000 Subject: [issue22086] Tab indent no longer works in interpreter In-Reply-To: <1406396060.4.0.777513387491.issue22086@psf.upfronthosting.co.za> Message-ID: <1423652818.48.0.13608194413.issue22086@psf.upfronthosting.co.za> Martin Panter added the comment: Patch at Issue 23441 ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 12:46:11 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 11:46:11 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 Message-ID: <1423655171.77.0.0216146047129.issue23442@psf.upfronthosting.co.za> New submission from Martin Panter: This is a regression caused by the new HTTPStatus enum from Issue 21793. RFC 6585 uses the plural ?Fields?, so maybe the new enum symbol needs renaming. $ python3.4 Python 3.4.2 (default, Oct 8 2014, 13:44:52) [GCC 4.9.1 20140903 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import http.client >>> http.client.REQUEST_HEADER_FIELDS_TOO_LARGE 431 >>> http.client.REQUEST_HEADER_FIELD_TOO_LARGE Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'REQUEST_HEADER_FIELD_TOO_LARGE' >>> $ ./python Python 3.5.0a0 (qbase qtip simple-http-testing.patch tip:f3fadbfb10ba, Feb 11 2015, 07:18:07) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import http.client >>> http.client.REQUEST_HEADER_FIELDS_TOO_LARGE Traceback (most recent call last): File "", line 1, in AttributeError: module 'http.client' has no attribute 'REQUEST_HEADER_FIELDS_TOO_LARGE' >>> http.client.REQUEST_HEADER_FIELD_TOO_LARGE ---------- components: Library (Lib) messages: 235737 nosy: demian.brecht, vadmium priority: normal severity: normal status: open title: http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 12:47:17 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 11:47:17 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1423655237.14.0.739245455294.issue21793@psf.upfronthosting.co.za> Martin Panter added the comment: FYI I opened Issue 23442 for a separate regression to do with the REQUEST_HEADER_FIELDS_TOO_LARGE name ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 13:02:01 2015 From: report at bugs.python.org (Will) Date: Wed, 11 Feb 2015 12:02:01 +0000 Subject: [issue23258] Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached In-Reply-To: <1421522813.3.0.624329571132.issue23258@psf.upfronthosting.co.za> Message-ID: <1423656121.91.0.416496962042.issue23258@psf.upfronthosting.co.za> Will added the comment: Had the exact same problem. Windows 7 / 64-bit All I can get from the MSIexec log is: ________________ Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action UpdatePip, location: B:\lang\python\v03.04\python.exe, command: -m ensurepip -U --default-pip === Logging stopped: 11-Feb-2015 22:13:46 === _________________ I tried this various ways -- from command line, as administrator, msiexec /a, verbose logging -- NO LUCK. I think it is really broken ---------- nosy: +aplatypus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 13:08:19 2015 From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=) Date: Wed, 11 Feb 2015 12:08:19 +0000 Subject: [issue23433] undefined behaviour in faulthandler.c, exposed by GCC 5 In-Reply-To: <1423577671.31.0.124602995451.issue23433@psf.upfronthosting.co.za> Message-ID: <1423656499.15.0.446369154031.issue23433@psf.upfronthosting.co.za> Changes by Mat?j Stuchl?k : ---------- nosy: +sYnfo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 13:15:27 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 11 Feb 2015 12:15:27 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1423656927.62.0.478944216284.issue1508475@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 13:37:58 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 11 Feb 2015 12:37:58 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <1423655171.77.0.0216146047129.issue23442@psf.upfronthosting.co.za> Message-ID: <1423658278.17.0.0749994632263.issue23442@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 13:38:07 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Wed, 11 Feb 2015 12:38:07 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1423658287.96.0.0143534844423.issue6634@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: Martin, I very much like the order you suggested, thanks. I did not feel confident enough for re-structuring the entire entry. So, can we agree on using that for Python 2.7? Is there a consensus regarding the approach to take for Python 3.5? Except from Martin there was no feedback on the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 13:40:53 2015 From: report at bugs.python.org (Ivailo Monev) Date: Wed, 11 Feb 2015 12:40:53 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423658453.17.0.894384417232.issue23435@psf.upfronthosting.co.za> Changes by Ivailo Monev : ---------- components: +Build versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 13:42:51 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 11 Feb 2015 12:42:51 +0000 Subject: [issue23432] Duplicate content in SystemExit documentation In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za> Message-ID: <1423658571.97.0.327528694521.issue23432@psf.upfronthosting.co.za> Berker Peksag added the comment: Good catch, thanks! Do you have better wording for that part of the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 13:44:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 11 Feb 2015 12:44:57 +0000 Subject: [issue21717] Exclusive mode for ZipFile and TarFile In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za> Message-ID: <1423658697.6.0.32537859622.issue21717@psf.upfronthosting.co.za> Changes by Berker Peksag : Added file: http://bugs.python.org/file38095/issue21717_tarfile_v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 13:46:00 2015 From: report at bugs.python.org (Ivailo Monev) Date: Wed, 11 Feb 2015 12:46:00 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423658760.34.0.291715234408.issue23435@psf.upfronthosting.co.za> Ivailo Monev added the comment: Right, I'm building it on custom Linux distribution on which software is installed on / instead of /usr on purpose. And the Python version is 2.7.9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 14:09:40 2015 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Wed, 11 Feb 2015 13:09:40 +0000 Subject: [issue6634] sys.exit() called from threads other than the main one: undocumented behaviour In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za> Message-ID: <1423660180.87.0.0145885437995.issue6634@psf.upfronthosting.co.za> Changes by Jan-Philip Gehrcke : Added file: http://bugs.python.org/file38096/issue6634_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 14:12:44 2015 From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=) Date: Wed, 11 Feb 2015 13:12:44 +0000 Subject: [issue23433] undefined behaviour in faulthandler.c, exposed by GCC 5 In-Reply-To: <1423577671.31.0.124602995451.issue23433@psf.upfronthosting.co.za> Message-ID: <1423660364.58.0.255987061296.issue23433@psf.upfronthosting.co.za> Mat?j Stuchl?k added the comment: FWIW with your patch all the tests pass on Fedora rawhide in Koji [1], whereas before the x86_64 build would hang [2]. If you want to do some more testing, you can download the rpms from [1]. :) [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8894494 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 14:21:43 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 11 Feb 2015 13:21:43 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1423660903.81.0.62851522884.issue23439@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 14:26:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Feb 2015 13:26:18 +0000 Subject: [issue23433] undefined behaviour in faulthandler.c, exposed by GCC 5 In-Reply-To: <1423577671.31.0.124602995451.issue23433@psf.upfronthosting.co.za> Message-ID: <20150211132548.31040.12739@psf.io> Roundup Robot added the comment: New changeset 689092296ad3 by Victor Stinner in branch '3.4': Issue #23433: Fix faulthandler._stack_overflow() https://hg.python.org/cpython/rev/689092296ad3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 14:45:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 11 Feb 2015 13:45:19 +0000 Subject: [issue23433] undefined behaviour in faulthandler.c, exposed by GCC 5 In-Reply-To: <1423577671.31.0.124602995451.issue23433@psf.upfronthosting.co.za> Message-ID: <1423662319.29.0.118942798091.issue23433@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks for the report. This issue should now be fixed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 14:55:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Feb 2015 13:55:58 +0000 Subject: [issue20416] Marshal: performance regression with versions 3 and 4 In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <20150211135547.11136.1687@psf.io> Roundup Robot added the comment: New changeset 012364df2712 by Serhiy Storchaka in branch 'default': Issue #20416: marshal.dumps() with protocols 3 and 4 is now 40-50% faster on https://hg.python.org/cpython/rev/012364df2712 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 14:55:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Feb 2015 13:55:58 +0000 Subject: [issue23344] Faster marshalling In-Reply-To: <1422483726.85.0.28053556963.issue23344@psf.upfronthosting.co.za> Message-ID: <20150211135547.11136.31927@psf.io> Roundup Robot added the comment: New changeset bb05f845e7dc by Serhiy Storchaka in branch 'default': Issue #23344: marshal.dumps() is now 20-25% faster on average. https://hg.python.org/cpython/rev/bb05f845e7dc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 15:19:22 2015 From: report at bugs.python.org (Ken Marsh) Date: Wed, 11 Feb 2015 14:19:22 +0000 Subject: [issue23443] XMLRPCLIB Exception uses str not class or instance Message-ID: <1423664362.4.0.817157506262.issue23443@psf.upfronthosting.co.za> New submission from Ken Marsh: xmlrpclib.Fault: :exceptions must be classes or instances, not str" Exception handling appears to be improperly coded. Occurs when far side gives an unexpected response to an RPC call. ---------- components: XML messages: 235748 nosy: kmarsh priority: normal severity: normal status: open title: XMLRPCLIB Exception uses str not class or instance type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 15:19:32 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 11 Feb 2015 14:19:32 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1423634923.85.0.604179098132.issue3566@psf.upfronthosting.co.za> Message-ID: <54DB64F1.3070207@gmail.com> Demian Brecht added the comment: > Thanks for helping with this Demian. No worries. This textual white boarding exercise has also been greatly valuable in getting my own head wrapped around various low frequency socket level errors that can be encountered when using the client. The downside is that this issue is now quite likely very difficult for new readers to follow :/ > The idea of raising the same exception in all cases is new to me. This initially puzzled me. I then re-read my response and realized that I was thinking one thing and wrote another. The exception that I was intending to suggest using here is ConnectionResetError, rather than the ConnectionError base class. To elaborate a little further, as I understand it, the /only/ case where the empty read happens is when the remote connection has been closed but where the TCP still allows for EOS to be read. In this case, the higher level implementation (in this case the client) /knows/ that the empty line is signifying that the connection has been closed by the remote host. To be clear, a rough example of what I'm proposing is this: diff -r e548ab4ce71d Lib/http/client.py --- a/Lib/http/client.py Mon Feb 09 19:49:00 2015 +0000 +++ b/Lib/http/client.py Wed Feb 11 06:04:08 2015 -0800 @@ -210,7 +210,7 @@ if not line: # Presumably, the server closed the connection before # sending a valid response. - raise BadStatusLine(line) + raise ConnectionResetError try: version, status, reason = line.split(None, 2) except ValueError: Your example of the XML-RPC client would then use the alternative approach: try: return self.single_request(...) except ConnectionError: #retry request once if cached connection has gone cold return self.single_request(...) That all said, I'm also not tremendously opposed to the introduction of the ConnectionClosed exception. I simply wanted to explore this thought before the addition is made, although the comments in my patch review would still hold true. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 16:28:17 2015 From: report at bugs.python.org (Armin Rigo) Date: Wed, 11 Feb 2015 15:28:17 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1423668497.0.0.767894999887.issue23441@psf.upfronthosting.co.za> Armin Rigo added the comment: Ah, thanks, I missed there was already an issue. The patch's logic is as follows: when pressing tab anywhere in the line, if the word to complete is empty (which might be for any number of reasons, like the cursor is after another space or a non-word character), then suggest as completion a string of N spaces, where N is a number from 1 to 4 so that the cursor ends up being aligned to a multiple of 4. You have to press backspace several times to remove all these spaces. Indeed, it could also suggest a single '\t' character, which would be simpler and revert exactly to the old behavior (including a single backspace to remove the whole tab). I didn't do it only because it would typically indent to 8 characters instead of 4. If people think it is anyway a better idea, I can submit a second (simpler) patch doing that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 16:50:15 2015 From: report at bugs.python.org (Thomas Chiroux) Date: Wed, 11 Feb 2015 15:50:15 +0000 Subject: [issue23444] HCI Bluetooth socket bind error on an arm crosscompiler environment Message-ID: <1423669815.59.0.783666779084.issue23444@psf.upfronthosting.co.za> New submission from Thomas Chiroux: This bug bellow occurs only on my crosscompiled environment on arm (marvell armada 166): arm-pxa168-linux-gnueabi It does not seems to be a cross-compile issue: python compiles without problem and all unittests pass on the target device. description and first clues --------------------------- The problem is easyly reproducted using this script: #!/usr/bin/python import socket sock = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_RAW, socket.BTPROTO_HCI) sock.bind((0,)) which raises the following exception when run on the target device: Traceback (most recent call last): File "./test_bt.py", line 4, in sock.bind((0,)) OSError: [Errno 22] Invalid argument This does not give much clues, but strace does (i've filtered to display the two significant parts of strace) socket(PF_BLUETOOTH, SOCK_RAW|SOCK_CLOEXEC, 1) = 3 bind(3, {sa_family=AF_UNSPEC, sa_data="\0\0\360\35\251\266s\316(U\3\0\0\0"}, 6) = -1 EINVAL (Invalid argument) (on a working environment, including arm, like a raspberry pi, strace gives the following result (and no traceback of course): socket(PF_BLUETOOTH, SOCK_RAW|SOCK_CLOEXEC, 1) = 3 bind(3, {sa_family=AF_BLUETOOTH, sa_data="\0\0\0\0\0\0X\352\243\266\0\24\265\266"}, 6) = 0 So, on the armada166, between the socket creation and the bind we lost the socket family (AF_UNSPEC instead of AF_BLUETOOTH). And That's why bind returns invalid argument. socketmodule and PyArg_ParseTuple --------------------------------- Now let's look at Modules/socketmodule.c: After some digging, i've found that the problem is in getsockaddrarg, in the AF_BLUETOOTH / BTPROTO_HCI case and more precisely on this line: https://hg.python.org/cpython/file/ab2c023a9432/Modules/socketmodule.c#l1449 reproducted here: if (!PyArg_ParseTuple(args, "i", &_BT_HCI_MEMB(addr, dev))) { When we execute the PyArg_ParseTuple, the addr->hci_family is crunched (by zeros with my previous python sample). At this same place, i've done the following test: char buffer[8]; memset(buffer, 0x55, 8); if (!PyArg_ParseTuple(args, "i", buffer) { PyErr_SetString(PyExc_OSError, "getsockaddrarg: " "wrong format"); return 0; } printf("CL: %d %d %d %d %d %d %d %d\n", buffer[0], buffer[1], buffer[2], buffer[3], buffer[4], buffer[5], buffer[6], buffer[7]); memset(buffer, 0xAA, 8); if (!PyArg_ParseTuple(args, "i", buffer+1) { PyErr_SetString(PyExc_OSError, "getsockaddrarg: " "wrong format"); return 0; } printf("CL+1: %d %d %d %d %d %d %d %d\n", buffer[0], buffer[1], buffer[2], buffer[3], buffer[4], buffer[5], buffer[6], buffer[7]); memset(buffer, 0xBB, 8); if (!PyArg_ParseTuple(args, "i", buffer+2) { PyErr_SetString(PyExc_OSError, "getsockaddrarg: " "wrong format"); return 0; } printf("CL+2: %d %d %d %d %d %d %d %d\n", buffer[0], buffer[1], buffer[2], buffer[3], buffer[4], buffer[5], buffer[6], buffer[7]); memset(buffer, 0xcc, 8); if (!PyArg_ParseTuple(args, "i", buffer+3) { PyErr_SetString(PyExc_OSError, "getsockaddrarg: " "wrong format"); return 0; } printf("CL+3: %d %d %d %d %d %d %d %d\n", buffer[0], buffer[1], buffer[2], buffer[3], buffer[4], buffer[5], buffer[6], buffer[7]); and the result is: CL: 0 0 0 0 85 85 85 85 CL+1: 0 0 0 0 170 170 170 170 CL+2: 0 0 0 0 187 187 187 187 CL+3: 0 0 0 0 204 204 204 204 (WTF ??) in a working environnement (tested on raspberry B+ / python 3.4.2 locally compiled) result is what we should expect: CL: 0 0 0 0 85 85 85 85 CL+1: 170 0 0 0 0 170 170 170 CL+2: 187 187 0 0 0 0 187 187 CL+3: 204 204 204 0 0 0 0 204 So on my box if PyArg_ParseTuple write on &addr->hci_dev if write 4 bytes from &addr->hci_family which is 2 bytes BEFORE &addr->hci_dev At this time I can not understand how it's possible. Remarks and patch ----------------- Now I have several remarks and a working patch. * remark/question 1: why does PyArg_ParseTuple parse an int when addr->hci_dev is an unsigned short ? even in normal situation, when it works, writing on &addr->hci_dev overflow on the next two bytes which are btw addr->channel (more on that later) * remark/question 2: i've tried to dig more deeply inside PyArg_ParseTuple and found another odd thing, but I did not try to change it without knowing what I do: in Python/getargs.c, in convertsimple, int parsing result is not casted before returned: here: https://hg.python.org/cpython/file/ab2c023a9432/Python/getargs.c#l690 (ival is a long). In all other cases (short, unsigned short, char, usigned char), they are casted before return. [disclosure: i've tested to add the cast and relaunched my bind test, it did not change anything, but it's still strange for me] * Now a working patch: here below and attached a working patch which results on a good socket bind, but now completely satisfiying: --- Python-3.4.2/Modules/socketmodule.c 2014-10-08 10:18:15.000000000 +0200 +++ CC_PYTHON/Python-3.4.2/Modules/socketmodule.c 2015-02-11 15:42:35.173455634 +0100 @@ -1446,11 +1446,12 @@ getsockaddrarg(PySocketSockObject *s, Py return 0; #else _BT_HCI_MEMB(addr, family) = AF_BLUETOOTH; - if (!PyArg_ParseTuple(args, "i", &_BT_HCI_MEMB(addr, dev))) { + if (!PyArg_ParseTuple(args, "H", &_BT_HCI_MEMB(addr, dev))) { PyErr_SetString(PyExc_OSError, "getsockaddrarg: " "wrong format"); return 0; } + _BT_HCI_MEMB(addr, channel) = HCI_CHANNEL_RAW; #endif *len_ret = sizeof *addr; return 1; in short: I parse now an unsigned short instead of parsing an int which gives me a two bytes long elements which is stored well on addr->hci_dev without overloading addr->hci_family. But this modification alone is not enough: addr->hci_channel needed a good value. that's why i added _BT_HCI_MEMB(addr, channel) = HCI_CHANNEL_RAW; which sets addr->hci_channel to zero. (without this line, any value could be here) And that led me to another question/problem: how is hci_channel normally handled ? It does not seems to be a valid parameter of bind; behaviour without the patch will erase hci_channel while storing int value in hci_dev, so theorically we can assign a well defined int value in our bind method to both assign the wanted value in hci_dev and hci_channel, but it does not seems to be a proper way to do it. ---------- components: Extension Modules files: bluetooth_bind_arm.patch keywords: patch messages: 235751 nosy: Thomas.Chiroux priority: normal severity: normal status: open title: HCI Bluetooth socket bind error on an arm crosscompiler environment type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file38097/bluetooth_bind_arm.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 16:51:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Feb 2015 15:51:27 +0000 Subject: [issue23344] Faster marshalling In-Reply-To: <1422483726.85.0.28053556963.issue23344@psf.upfronthosting.co.za> Message-ID: <1423669887.42.0.00581835899777.issue23344@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Kristj?n. Together with issue20416 this increases dumping speed almost twice for typical module data and up to 5x for some data. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 16:53:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Feb 2015 15:53:15 +0000 Subject: [issue20416] Marshal: performance regression with versions 3 and 4 In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1423669995.74.0.465627527343.issue20416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks for your review Antoine and Victor. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 17:05:05 2015 From: report at bugs.python.org (Thomas Chiroux) Date: Wed, 11 Feb 2015 16:05:05 +0000 Subject: [issue23444] HCI Bluetooth socket bind error on an arm crosscompiled environment In-Reply-To: <1423669815.59.0.783666779084.issue23444@psf.upfronthosting.co.za> Message-ID: <1423670705.06.0.889547445488.issue23444@psf.upfronthosting.co.za> Changes by Thomas Chiroux : ---------- title: HCI Bluetooth socket bind error on an arm crosscompiler environment -> HCI Bluetooth socket bind error on an arm crosscompiled environment _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 17:28:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Feb 2015 16:28:42 +0000 Subject: [issue23445] Use -Og for debug builds Message-ID: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Recent gcc versions have an optimization level named "-Og". It enables all optimizations that do not break debugging. Here is a patch that uses it on debug builds. Without the patch I get the following time for the whole test suite: $ time ./python -m test -j12 [...] real 3m51.670s user 11m53.039s sys 0m28.300s With the patch it goes down to: real 2m36.378s user 7m13.743s sys 0m29.728s So the test suite is 33% faster to pass. ---------- components: Build, Tests files: og.patch keywords: patch messages: 235754 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: Use -Og for debug builds type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38098/og.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 17:44:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Feb 2015 16:44:09 +0000 Subject: [issue23445] Use -Og for debug builds In-Reply-To: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za> Message-ID: <1423673049.54.0.616032090575.issue23445@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Most slow tests are skipped without -uall. As for the patch, may be use AX_CHECK_COMPILE_FLAG [1]? [1] http://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 18:10:31 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Feb 2015 17:10:31 +0000 Subject: [issue23445] Use -Og for debug builds In-Reply-To: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za> Message-ID: <1423674631.82.0.700712022964.issue23445@psf.upfronthosting.co.za> Antoine Pitrou added the comment: -uall, without patch: real 5m47.290s user 18m28.405s sys 0m29.493s -uall, with patch: real 3m35.132s user 10m26.345s sys 0m30.351s That's a 38% speedup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 18:11:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Feb 2015 17:11:02 +0000 Subject: [issue23445] Use -Og for debug builds In-Reply-To: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za> Message-ID: <1423674662.67.0.750133720365.issue23445@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > As for the patch, may be use AX_CHECK_COMPILE_FLAG [1]? It's not used elsewhere in configure.ac. I reused the idiom used a couple lines above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 18:29:33 2015 From: report at bugs.python.org (William Scullin) Date: Wed, 11 Feb 2015 17:29:33 +0000 Subject: [issue22699] cross-compilation of Python3.4 In-Reply-To: <1413992946.14.0.956103683321.issue22699@psf.upfronthosting.co.za> Message-ID: <1423675773.1.0.148709435202.issue22699@psf.upfronthosting.co.za> Changes by William Scullin : ---------- nosy: +wscullin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 18:30:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Feb 2015 17:30:15 +0000 Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc Message-ID: <1423675815.31.0.721977402363.issue23446@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch replaces PyMem_Malloc with PyMem_New if the former is used in the form PyMem_Malloc(len * sizeof(type)). This can fix possible overflow errors and makes the code cleaner. ---------- components: Extension Modules, Interpreter Core files: pymem_new.patch keywords: patch messages: 235758 nosy: benjamin.peterson, haypo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Use PyMem_New instead of PyMem_Malloc type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38099/pymem_new.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 19:00:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Feb 2015 18:00:01 +0000 Subject: [issue23445] Use -Og for debug builds In-Reply-To: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za> Message-ID: <1423677601.13.0.584737658052.issue23445@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks pretty harmless. Some slow buildbots run tests very long time and failed with timeout after 3600 seconds. May be this patch will make them faster. Yet one advantage -- the code compiled with partial optimization will be closer to the code compiled with full optimization. Therefore debugging version could catch more bugs that exist only with optimization. But may be apply this only to 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 19:03:00 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Feb 2015 18:03:00 +0000 Subject: [issue23445] Use -Og for debug builds In-Reply-To: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za> Message-ID: <1423677780.23.0.350768457546.issue23445@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'd like to apply it to 3.4 as well, because it makes development more pleasant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 19:38:45 2015 From: report at bugs.python.org (Antonio Cota) Date: Wed, 11 Feb 2015 18:38:45 +0000 Subject: [issue23447] Relative imports with __all__ attribute Message-ID: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> New submission from Antonio Cota: That's the situation: a/ __init__.py first.py second.py #init.py __all__ = ['second', 'first'] print('i\'m starting the directory') #first.py print('hi, i\'m the first') from . import * #second.py print('hi, i\'m the second') >From the interactive prompt: >>> import a.first i'm starting the directory hi, i'm the first hi, i'm the second Traceback (most recent call last): File "", line 1, in File "/home/antox/Scrivania/a/first.py", line 2, in from . import * AttributeError: module 'a' has no attribute 'first' It's pretty weird. ---------- messages: 235761 nosy: antox priority: normal severity: normal status: open title: Relative imports with __all__ attribute type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 19:40:23 2015 From: report at bugs.python.org (Neil Gierman) Date: Wed, 11 Feb 2015 18:40:23 +0000 Subject: [issue23448] urllib2 needs to remove scope from IPv6 address when creating Host header Message-ID: <1423680023.83.0.120732364895.issue23448@psf.upfronthosting.co.za> New submission from Neil Gierman: Using a scoped IPv6 address with urllib2 creates an invalid Host header that Apache will not accept. IP = "fe80::0000:0000:0000:0001%eth0" req = urllib2.Request("http://[" + IP + "]/") req.add_header('Content-Type', 'application/json') res = urllib2.urlopen(req, json.dumps(data)) Apache will reject the above request because the Host header is "[fe80::0000:0000:0000:0001%eth0]". This behavior was reported to Apache at https://issues.apache.org/bugzilla/show_bug.cgi?id=35122 and the Apache devs will not fix this as there are new RFCs prohibiting scopes in the Host header. Firefox had the same issue and their fix was to strip out the scope from the Host header: https://bugzilla.mozilla.org/show_bug.cgi?id=464162 and http://hg.mozilla.org/mozilla-central/rev/bb80e727c531. My suggestion is to change urllib2.py's do_request_ method from: if not request.has_header('Host'): request.add_unredirected_header('Host', sel_host) to: if not request.has_header('Host'): request.add_unredirected_header('Host', re.compile(r"%.*$").sub("", sel_host, 1)) I have not tested this patch to urllib2.py however I am now using similar logic in my code to override the Host header when I create my request: IP = "fe80::0000:0000:0000:0001%eth0" req = urllib2.Request("http://[" + IP + "]/") req.add_header('Host', '[' + re.compile(r"%.*").sub("", IP, 1) + ']') req.add_header('Content-Type', 'application/json') res = urllib2.urlopen(req, json.dumps(data)) ---------- components: Library (Lib) messages: 235762 nosy: ngierman priority: normal severity: normal status: open title: urllib2 needs to remove scope from IPv6 address when creating Host header type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 19:41:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Feb 2015 18:41:20 +0000 Subject: [issue23445] Use -Og for debug builds In-Reply-To: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za> Message-ID: <20150211184112.31018.26011@psf.io> Roundup Robot added the comment: New changeset e37b201297d2 by Antoine Pitrou in branch '3.4': Issue #23445: pydebug builds now use "gcc -Og" where possible, to make the resulting executable faster. https://hg.python.org/cpython/rev/e37b201297d2 New changeset 527ed5205806 by Antoine Pitrou in branch 'default': Issue #23445: pydebug builds now use "gcc -Og" where possible, to make the resulting executable faster. https://hg.python.org/cpython/rev/527ed5205806 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 19:41:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Feb 2015 18:41:42 +0000 Subject: [issue23445] Use -Og for debug builds In-Reply-To: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za> Message-ID: <1423680102.47.0.752959064207.issue23445@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Done. It shouldn't break anything. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 19:50:38 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 11 Feb 2015 18:50:38 +0000 Subject: [issue9207] multiprocessing occasionally spits out exception during shutdown (_handle_workers) In-Reply-To: <1278619533.83.0.0853433126095.issue9207@psf.upfronthosting.co.za> Message-ID: <1423680638.39.0.843955600673.issue9207@psf.upfronthosting.co.za> Davin Potts added the comment: Closing this issue after having verified that the issue can no longer be reproduced on the systems mentioned (Ubuntu 10.04 or OSX). Related issues such as issue9205 have been addressed elsewhere and other possibly related issues such as issue22393 are being tracked separately. It appears Jesse's patches in 2010 (though not explicitly added to this issue here) have indeed addressed this issue. Using OS X 10.10: Using Greg's original test script (from his first post), I ran the script 100 times (via shell script loop) but was unable to provoke the issue on OS X 10.10 using either the Anaconda build of Python 2.7.9 or a local build from the default (3.5.0a1+) branch. Using Matt Walker's supplied test script (from a much later post here), I ran his script 100 times in tight succession but was unable to provoke the issue on OS X 10.10 using either the Anaconda build of Python 2.7.9 or a local build from the default (3.5.0a1+) branch. Side note: running Matt's test script kinda takes a while ("time.sleep(10)" seriously?), especially at 100 iterations. Using Ubuntu 10.04 (64-bit): I installed Ubuntu 10.04.4 64-bit Server in a VM and repeated the above test sequences with those two scripts using the stock Python 2.6.5, locally built 2.7 branch, and locally built default (3.5) branch versions. Summary: * At 100 iterations I was still unable to provoke the issue with Greg's script using 2.6.5, 2.7.9+, or 3.5.0a1+. * Matt's script leverages functionality only introduced in 2.7 and so could not be run as-is with 2.6.5. * At 100 iterations I was still unable to provoke the issue with Matt's script using 2.7.9+ or 3.5.0a1+. Even if it's a little late in saying: thanks goes to the reporters, Greg and Matt, and to Jesse for implementing the fix. ---------- nosy: +davin resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 20:15:21 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 11 Feb 2015 19:15:21 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1423682121.48.0.593296646279.issue15914@psf.upfronthosting.co.za> Davin Potts added the comment: Adding Brett Cannon as this issue appears to really be about doing an import shortly after an os.fork() -- this may be of particular interest to him. This issue probably should have had Brett and/or others added to nosy long ago. ---------- nosy: +brett.cannon, davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 21:30:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Feb 2015 20:30:02 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1423686602.98.0.980170994594.issue23441@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks a lot for doing this. I think it's a good improvement. I prefer 4 spaces myself (tabs usually insert 8 spaces, which is too wide), but I'm open to other opinions. ---------- nosy: +pitrou, r.david.murray stage: -> patch review versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 21:43:10 2015 From: report at bugs.python.org (Antonio Cota) Date: Wed, 11 Feb 2015 20:43:10 +0000 Subject: [issue23447] Relative imports with __all__ attribute In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> Message-ID: <1423687390.65.0.223203304781.issue23447@psf.upfronthosting.co.za> Changes by Antonio Cota : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 22:03:41 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 21:03:41 +0000 Subject: [issue23448] urllib2 needs to remove scope from IPv6 address when creating Host header In-Reply-To: <1423680023.83.0.120732364895.issue23448@psf.upfronthosting.co.za> Message-ID: <1423688621.2.0.0893826479394.issue23448@psf.upfronthosting.co.za> Martin Panter added the comment: I?m no IPv6 expert, but there seems to be a few standards: * (Feb 2013). Encodes as http://[fe80::1%25eth0]/; says Windows uses this form. Also mentions the unencoded http://[fe80::1%eth0]/ form. Says that the HTTP Host header should not include the scope zone identifier, since it is not necessarily relevant to the server. * (Nov 2013). Encodes as http://[v1.fe80::1+eth0]/; says CUPS uses this form. Also acknowledges the RFC %25 form. Says that the Host header _should_ include the scope, to help with servers that send back self-referencing absolute URLs. Also, I would probably find IP.split('%', 1)[0] easier to read than a regular expression. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 22:06:45 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 11 Feb 2015 21:06:45 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <1423655171.77.0.0216146047129.issue23442@psf.upfronthosting.co.za> Message-ID: Demian Brecht added the comment: Thanks for the catch Martin, the field should indeed be updated to be plural. I'll try to get a patch for this later today unless someone else beats me to it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 22:23:46 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 11 Feb 2015 21:23:46 +0000 Subject: [issue23448] urllib2 needs to remove scope from IPv6 address when creating Host header In-Reply-To: <1423680023.83.0.120732364895.issue23448@psf.upfronthosting.co.za> Message-ID: <1423689826.1.0.309155133991.issue23448@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 22:24:52 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 11 Feb 2015 21:24:52 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1423689892.97.0.633758037626.issue23439@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 22:25:20 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 11 Feb 2015 21:25:20 +0000 Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc In-Reply-To: <1423675815.31.0.721977402363.issue23446@psf.upfronthosting.co.za> Message-ID: <1423689920.2.0.557178783887.issue23446@psf.upfronthosting.co.za> Stefan Krah added the comment: In _testbuffer.c: ndim <= 64, so the changes aren't really necessary. Somehow this fact needs to get widely known, since it does not make sense to check for overflow anytime ndim is used. The reason is of course that even an array with only 2 elements per dimension gets quite large with ndim=64. :) ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 22:49:40 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 11 Feb 2015 21:49:40 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1423691380.08.0.602153005194.issue23439@psf.upfronthosting.co.za> Martin Panter added the comment: Actually, maybe I should add all those status codes as well, like http.client.OK. Will probably require different patches for 3.4 and 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 22:54:08 2015 From: report at bugs.python.org (Edward O) Date: Wed, 11 Feb 2015 21:54:08 +0000 Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__ In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za> Message-ID: <1423691648.11.0.0860249223127.issue20371@psf.upfronthosting.co.za> Changes by Edward O : ---------- nosy: +eddygeek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 22:57:42 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 11 Feb 2015 21:57:42 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1423691862.48.0.859736215284.issue23439@psf.upfronthosting.co.za> Berker Peksag added the comment: It's not that important in my opinion. Let's keep it simple for now :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 23:19:31 2015 From: report at bugs.python.org (Edward O) Date: Wed, 11 Feb 2015 22:19:31 +0000 Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__ In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za> Message-ID: <1423693171.23.0.425798587808.issue20371@psf.upfronthosting.co.za> Edward O added the comment: Here is a workaround for subclasses (2&3-compatible): --- start code --- class MyDate(datetime): @classmethod def fromDT(cls, d): """ :type d: datetime """ return cls(d.year, d.month, d.day, d.hour, d.minute, d.second, d.microsecond, d.tzinfo) def replace(self, *args, **kw): """ :type other: datetime.timedelta :rtype: MyDate """ return self.fromDT(super(MyDate, self).replace(*args, **kw)) --- end code --- This is really a bug and not a misuse as datetime was specifically adapted to be subclassing-friendly. From a look at the (python) source, this seems to be the only bit that was forgotten. The real fix is as per yselivanov comment [and no, this has nothing to do with pickle or copy AFAIK] ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 11 23:30:04 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 11 Feb 2015 22:30:04 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: Demian Brecht added the comment: The only real question I have is: why? As far as I'm aware, these are implementation details of the http.client module (there's even a comment in HTTPMessage that it might make sense to move the class altogether). As far as the constants go, they're only there for backwards compatibility and http.HTTPStatus should be preferred. In light of that and the fact that they were not previously in __all__, I agree with Berker about keeping this simple for now. On Wed, Feb 11, 2015, 13:57 Berker Peksag wrote: > > Berker Peksag added the comment: > > It's not that important in my opinion. Let's keep it simple for now :) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 00:01:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Feb 2015 23:01:51 +0000 Subject: [issue12340] Access violation when using the C version of the io module In-Reply-To: <1308152515.03.0.630952257185.issue12340@psf.upfronthosting.co.za> Message-ID: <1423695711.28.0.994210219223.issue12340@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as the crash was fixed in one of previous bugfixes. As for memoryview related issue, this is a duplicate of issue20699. ---------- nosy: +serhiy.storchaka status: languishing -> pending superseder: -> Behavior of ZipFile with file-like object and BufferedWriter. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 00:11:09 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 11 Feb 2015 23:11:09 +0000 Subject: [issue23449] Fatal errors rebuilding 3.5 from Visual Studio Windows 8.1 64 bit Message-ID: <1423696269.22.0.462965146464.issue23449@psf.upfronthosting.co.za> New submission from Mark Lawrence: If I select "Rebuild Solution" I get this:- error C1083: Cannot open include file: 'tcl.h': No such file or directory C:\cpython\Modules\_tkinter.c error C1083: Cannot open include file: 'tcl.h': No such file or directory C:\cpython\Modules\tkappinit.c I'm assuming that this should never happen. ---------- components: Build, Windows messages: 235776 nosy: BreamoreBoy, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Fatal errors rebuilding 3.5 from Visual Studio Windows 8.1 64 bit type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 00:21:04 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 11 Feb 2015 23:21:04 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit Message-ID: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> New submission from Mark Lawrence: The attached file lists many of the warnings, but note there may be more as tkinter didn't build and is subject to #23449. ---------- components: Build, Windows files: PossibleLossOfData.txt messages: 235777 nosy: BreamoreBoy, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file38100/PossibleLossOfData.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 00:26:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 11 Feb 2015 23:26:06 +0000 Subject: [issue20699] Behavior of ZipFile with file-like object and BufferedWriter. In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1423697166.34.0.639964596181.issue20699@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 00:34:06 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 11 Feb 2015 23:34:06 +0000 Subject: [issue23451] Deprecation warnings building 3.5 Visual Studio Windows 8.1 64 bit Message-ID: <1423697646.35.0.470486317043.issue23451@psf.upfronthosting.co.za> New submission from Mark Lawrence: Raised as a placeholder. ---------- components: Build, Windows files: Deprecations.txt messages: 235778 nosy: BreamoreBoy, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Deprecation warnings building 3.5 Visual Studio Windows 8.1 64 bit type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file38101/Deprecations.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 00:40:25 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 11 Feb 2015 23:40:25 +0000 Subject: [issue23449] Fatal errors rebuilding 3.5 from Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696269.22.0.462965146464.issue23449@psf.upfronthosting.co.za> Message-ID: <1423698025.39.0.864217264572.issue23449@psf.upfronthosting.co.za> Mark Lawrence added the comment: Using Microsoft Visual Studio Express 2013 for Windows Desktop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 00:40:41 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 11 Feb 2015 23:40:41 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423698041.65.0.103117723408.issue23450@psf.upfronthosting.co.za> Mark Lawrence added the comment: Using Microsoft Visual Studio Express 2013 for Windows Desktop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 00:41:00 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 11 Feb 2015 23:41:00 +0000 Subject: [issue23451] Deprecation warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423697646.35.0.470486317043.issue23451@psf.upfronthosting.co.za> Message-ID: <1423698060.02.0.202823325827.issue23451@psf.upfronthosting.co.za> Mark Lawrence added the comment: Using Microsoft Visual Studio Express 2013 for Windows Desktop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 01:59:24 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 12 Feb 2015 00:59:24 +0000 Subject: [issue22559] [backport] ssl.MemoryBIO In-Reply-To: <1412540756.02.0.793381062078.issue22559@psf.upfronthosting.co.za> Message-ID: <1423702764.98.0.0644104400715.issue22559@psf.upfronthosting.co.za> Nick Coghlan added the comment: While I agree with the idea of backporting this at some point after it has been published in a 3.x release, Guido also specifically requested that we *not* treat PEP 466 as blanket permission to backport other network security features to Python 2.7. (I originally had that kind of wording in the PEP, and he convinced me to take it out to ensure we considered each future feature backport request on its own merits) That means 2.7.x should track the 3.4.x maintenance branch until after 3.5 is released, and then it should start tracking the 3.5.x maintenance branch. However, any new 3.5 ssl features will need their own backporting PEP, rather than relying on the previous approval in PEP 466 to backport ssl features from 3.4. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 02:09:20 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 01:09:20 +0000 Subject: [issue23449] Fatal errors rebuilding 3.5 from Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696269.22.0.462965146464.issue23449@psf.upfronthosting.co.za> Message-ID: <1423703360.39.0.392255246686.issue23449@psf.upfronthosting.co.za> Steve Dower added the comment: Have you previously run ``build.bat -e`` from the command line? That's the best way to make sure you're ready to work inside VS. (And technically it's allowed to happen, since VS 2013 is not supported and our build can do whatever it likes :) But it should work, so let's figure out why it isn't.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 02:10:48 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 01:10:48 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423703448.01.0.678513139027.issue23450@psf.upfronthosting.co.za> Steve Dower added the comment: These are warnings about implicit downcasting in a 64-bit build. They're not fatal to the build or execution (as far as we know), and as nice as it would be to fix them all, "good" fixes may introduce behaviour changes (for example, new overflow errors). As an aside, building with VS 2015 also shows a lot of warnings for variable shadowing, which should also be fixed but is not likely unless someone gets really annoyed by them. What's the usual policy on issues like this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 02:16:50 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 12 Feb 2015 01:16:50 +0000 Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc In-Reply-To: <1423675815.31.0.721977402363.issue23446@psf.upfronthosting.co.za> Message-ID: <1423703810.32.0.774966342847.issue23446@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Very nice. I think you should also apply it to older versions, since (as we now) this sort of thing is very liable to cause security problems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 02:24:13 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 01:24:13 +0000 Subject: [issue23451] Deprecation warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423697646.35.0.470486317043.issue23451@psf.upfronthosting.co.za> Message-ID: <1423704253.51.0.152928010849.issue23451@psf.upfronthosting.co.za> Steve Dower added the comment: Adding 'socket' nosy list, as Antoine may have a stronger opinion about changing _socket to avoid these warnings - they aren't all in Windows-exclusive code. Or I'm happy to add the suppression to the build if that's the better option. I'll work up a patch for the GetVersion deprecations. I believe they're mostly checking for Vista, which we can assume now, so they aren't necessary. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 02:46:12 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 01:46:12 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1423705572.1.0.068392022582.issue19143@psf.upfronthosting.co.za> Steve Dower added the comment: The newer attachment should handle back to Windows 2000. Unfortunately, I have no machines to test this on, but all of the API calls existed at least on XP and the version numbers are correct. It runs correctly back to Python 2.7, works on 2.6 but gives the wrong result (possibly a ctypes bug?), and is fine on Python 3. ---------- Added file: http://bugs.python.org/file38102/win32_ver.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 03:16:32 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 12 Feb 2015 02:16:32 +0000 Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za> Message-ID: <1423707391.99.0.171616513043.issue18610@psf.upfronthosting.co.za> Berker Peksag added the comment: The change was suggested before PEP 3333 in issue 4718 (see msg78292), but PEP 3333 says: A server should allow read() to be called without an argument, and return the remainder of the client's input stream. https://www.python.org/dev/peps/pep-3333/#input-and-error-streams I couldn't find any objection at https://mail.python.org/pipermail/web-sig/2010-September/004655.html ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 03:17:08 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 02:17:08 +0000 Subject: [issue23451] Deprecation warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423697646.35.0.470486317043.issue23451@psf.upfronthosting.co.za> Message-ID: <1423707428.76.0.16312716945.issue23451@psf.upfronthosting.co.za> Steve Dower added the comment: Patch attached. Interesting, once you declare Vista as the minimum API set, WinSock claims to support CMSG_LEN which enables sendmsg() et al support in _socket. Since the WinSock API bears little relation to the POSIX(?) API, it doesn't build, so I've just undef'd CMSG_LEN when building socket. ---------- keywords: +patch Added file: http://bugs.python.org/file38103/23451_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 03:21:51 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 02:21:51 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1423707711.97.0.877000571475.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: Anyone interested in reviewing this patch? ---------- assignee: -> steve.dower stage: -> patch review type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 03:24:48 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 02:24:48 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1423707888.2.0.999805962017.issue23314@psf.upfronthosting.co.za> Steve Dower added the comment: Attached a patch with options 1 and 2 implemented - both are fairly trivial. Any thoughts/preferences? ---------- assignee: -> steve.dower keywords: +patch Added file: http://bugs.python.org/file38104/23314 Options.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 03:34:05 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 12 Feb 2015 02:34:05 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423708445.24.0.847486333804.issue23435@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, I tried using your ./configure with a 2.7.9 tarball on a Debian VM from which I removed the system Python 2.7 and, despite installing into the non-standard locations, at a quick look everything seemed to work OK. For example, >>> import _collections >>> _collections.__file__ '/lib/python2.7/lib-dynload/_collections.so' If you are building with --enable-shared, make sure the build isn't being influenced by a previously installed system or local Python 2.7. ---------- resolution: -> works for me stage: -> resolved status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 04:20:47 2015 From: report at bugs.python.org (Ivailo Monev) Date: Thu, 12 Feb 2015 03:20:47 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423711247.82.0.541318155449.issue23435@psf.upfronthosting.co.za> Ivailo Monev added the comment: I don't know how --enable-shared can have effect on this but I do not know much about the build system either (I just quick scoped trough it) so I tried that - it doesn't change anything. Also, I have only one version of Python installed and that is 2.7.9. I have tried bind mounting / to /usr in case of some hardcoded path check (I deal with that a lot) but that does not help either. I guess I'll have to poke deeper and figure it out on my own. I'll let you know if I find the source of that issue. Cheers! ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 04:27:12 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 12 Feb 2015 03:27:12 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423711632.68.0.657916033613.issue23435@psf.upfronthosting.co.za> Ned Deily added the comment: --enable-shared builds in some cases can erroneously link with an already installed Python library of the same version. That's what happened on my first try, before removing the system 2.7. In any case, I'm closing this issue for now. Feel free to reopen if you can identify a reproducible problem on a supported configuration. Good luck! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 05:25:34 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 04:25:34 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423715134.4.0.151469516664.issue23450@psf.upfronthosting.co.za> Mark Lawrence added the comment: Changes to nosy list as advised by Terry Reedy on c.l.py ---------- nosy: +haypo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 05:47:56 2015 From: report at bugs.python.org (Ivailo Monev) Date: Thu, 12 Feb 2015 04:47:56 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423716476.49.0.482965935165.issue23435@psf.upfronthosting.co.za> Ivailo Monev added the comment: I found the source of the problem, it's in distutils. at line 148 in Lib/distutils/util.py (in the tarball) the path join does not handle the full path properly (os.path.join returns the second path if it is full path), as a workaround I used "return new_root + pathname[1:]" and it worked as expected. Do note that I've forgot to mention in my initial comment/message on this issue does not mention that I'm trying to install it ala DESTDIR. Trying to install Python as regular user failed because it was trying to place files on / instead of the sepcified DESTDIR. Will you do something about this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 05:58:47 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Feb 2015 04:58:47 +0000 Subject: [issue10486] http.server doesn't set all CGI environment variables In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za> Message-ID: <1423717127.35.0.189883042434.issue10486@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 5054 is for HTTP_ACCEPT ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 06:08:45 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 12 Feb 2015 05:08:45 +0000 Subject: [issue10351] Add autocompletion for keys in dictionaries In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za> Message-ID: <1423717725.18.0.585099982565.issue10351@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 06:11:12 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Feb 2015 05:11:12 +0000 Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns [] In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za> Message-ID: <1423717872.42.0.760082976959.issue5053@psf.upfronthosting.co.za> Martin Panter added the comment: I agree with Catalin?s proposal to remove it straight away. It just causes confusion, and to me the intended behaviour is not equivalent to Message.get_all(). I would remove the entire HTTPMessage class and replace it as an alias of email.message.Message. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 06:26:19 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Feb 2015 05:26:19 +0000 Subject: [issue23432] Duplicate content in SystemExit documentation In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za> Message-ID: <1423718779.95.0.992384958347.issue23432@psf.upfronthosting.co.za> Martin Panter added the comment: How about this: ''' The constructor accepts the same optional argument passed to :func:`sys.exit`. If the value is an integer, it specifies the system exit status . . . . . . .. attribute:: code The exit status or error message that is passed to the constructor. (Defaults to ``None``.) ''' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 07:00:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 06:00:07 +0000 Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns [] In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za> Message-ID: <1423720807.51.0.841209190093.issue5053@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +r.david.murray versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 07:06:55 2015 From: report at bugs.python.org (Martin Dengler) Date: Thu, 12 Feb 2015 06:06:55 +0000 Subject: [issue21360] mailbox.Maildir should ignore files named with a leading dot In-Reply-To: <1398550003.67.0.360972625113.issue21360@psf.upfronthosting.co.za> Message-ID: <1423721215.91.0.369252086523.issue21360@psf.upfronthosting.co.za> Changes by Martin Dengler : ---------- nosy: +mdengler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 07:25:20 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 06:25:20 +0000 Subject: [issue23449] Fatal errors rebuilding 3.5 from Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696269.22.0.462965146464.issue23449@psf.upfronthosting.co.za> Message-ID: <1423722320.77.0.331335111032.issue23449@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've run "build.bat -e" for all four combinations of release and debug with 32 or 64 bit with no problems. Go back to VS and all four combinations fail with this problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 07:45:59 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 06:45:59 +0000 Subject: [issue23452] Build errors using VS Express 2013 in win32 mode Message-ID: <1423723559.86.0.395515662536.issue23452@psf.upfronthosting.co.za> New submission from Mark Lawrence: I came across these while looking at #23449. The output is in the attached file as it's cleaner that way. ---------- components: Build, Windows files: Win32BuildErrors.txt messages: 235801 nosy: BreamoreBoy, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Build errors using VS Express 2013 in win32 mode type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file38105/Win32BuildErrors.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 08:09:20 2015 From: report at bugs.python.org (John Nagle) Date: Thu, 12 Feb 2015 07:09:20 +0000 Subject: [issue20916] ssl.enum_certificates() will not return all certificates trusted by Windows In-Reply-To: <1394740101.16.0.76901026465.issue20916@psf.upfronthosting.co.za> Message-ID: <1423724960.84.0.185382240302.issue20916@psf.upfronthosting.co.za> John Nagle added the comment: Amusingly, I'm getting this failure on "verisign.com" on Windows 7 with Python 2.7.9: "HTTP error - [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)..)" The current Verisign root cert (Class 3 public) is, indeed, not in the Windows 7 cert store. Verisign has a newer root cert. That error message ought to be improved. Tell the user which cert was rejected. "python.org", with a DigiCert certificate, works fine. I'm going to use the Mozilla certificate store explicitly. ---------- nosy: +nagle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 08:55:18 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 12 Feb 2015 07:55:18 +0000 Subject: [issue23361] integer overflow in winapi_createprocess In-Reply-To: <1422798703.49.0.874007534993.issue23361@psf.upfronthosting.co.za> Message-ID: <1423727718.52.0.828703332868.issue23361@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- versions: +Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 09:06:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 08:06:49 +0000 Subject: [issue22559] [backport] ssl.MemoryBIO In-Reply-To: <1412540756.02.0.793381062078.issue22559@psf.upfronthosting.co.za> Message-ID: <1423728409.61.0.394865690512.issue22559@psf.upfronthosting.co.za> STINNER Victor added the comment: > Since this is such a new feature (not even released in 3.x), I don't think we should put it in 2.7.9. While ssl.MemoryBIO would be very useful on Windows for Trollius (to support SSL with the IOCP event loop), I also consider it as a new feature. It's a little bit borderline between feature and security fix. Maybe it should be discussed on python-dev? Note: MemoryBIO was added by issue #21965 (first commit: a79003f25a41). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 09:19:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 08:19:53 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423729193.97.0.60548728093.issue23450@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which fixes many warnings reported by MS compiler on 64-bit platform [1]. Some of these warnings indicated real bugs. [1] http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/411/steps/compile/logs/warnings%20(396) ---------- components: +Extension Modules, Interpreter Core -Build, Windows keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file38106/int_overflows.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:13:08 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Feb 2015 11:13:08 +0000 Subject: [issue20699] Behavior of ZipFile with file-like object and BufferedWriter. In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1423739588.43.0.320699028743.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: Posting patch v2: * Changed readinto() argument descriptions to ?a pre-allocated, writable bytes-like buffer?, for both RawIOBase and BufferedIOBase * Integrated the single-use test_memoryio.BytesIOMixin test class, which tricked me when I did the first patch * Added tests for BufferedRWPair, BytesIO.readinto() etc methods with non-bytearray() buffers * Fix _pyio.BufferedReader.readinto/1() for non-bytearray ---------- Added file: http://bugs.python.org/file38107/bytes-like-param.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:16:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 11:16:01 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423739761.3.0.907624069221.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: scandir-3.patch: New implementation based on scandir-2.patch on Ben's github repository. Main changes with scandir-2.patch: * new DirEntry.inode() method * os.scandir() doesn't support bytes on Windows anymore: it's deprecated since python 3.3 and using bytes gives unexpected results on Windows As discussed with Ben Hoyt, I added a inode() method to solve the use case described here: https://www.reddit.com/r/Python/comments/2synry/so_8_peps_are_currently_being_proposed_for_python/cnvnz1w I will update the PEP 471 to add the inode() method. Notes: * os.scandir() doesn't accept a file descriptor, as decided in the PEP 471. * It may be nice to modify Scandir.close() to close the handle/directory; Scandir is the iterator returned by os._scandir() * My patch doesn't modify os.walk(): it prefer to do that in a new issue * DirEntry methods have no docstring Changes with scandir-2.patch: * C code is added to posixmodule.c, not into a new _scandir.c file, to avoid code duplication (all Windows code to handle attributes) * C code is restricted to the minimum: it's now only a wrapper to opendir+readdir and FindFirstFileW/FindNextFileW * os._scandir() directly calls opendir(), it's no more delayed to the first call to next(), to report errors earlier. In practice, I don't think that anymore will notify :-p * don't allocate a buffer to store a HANDLE: use directly a HANDLE * C code: use #ifdef inside functions, not outside * On Windows, os._scandir() appends "*.*" instead of "*" to the path, to mimic os.listdir() * put information about cache and syscall directly in the doc of DirEntry methods * remove promise of performances from scandir doc: be more factual, explain when syscalls are required or not * expose DT_UNKOWN, DT_DIR, DT_REG, DT_LNK constants in the posix module; but I prefer to not document them: use directly scandir! * rewrite completly unit test: - reuse test.support - compare DirEntry attributes with the result of functions (ex: os.stat() or os.path.islink()) * add tests on removed directory, removed file and broken symbolic link * remove ":" from repr(DirEntry) result, it's now ""; drop __str__ method (by default, __str__ calls __repr__) * use new OSError subclasses (FileNotFoundError) * DirEntry methods: use stat.S_ISxxx() methods instead of "st.st_mode & 0o170000 == S_IFxxx" ---------- Added file: http://bugs.python.org/file38108/scandir-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:18:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 11:18:58 +0000 Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc In-Reply-To: <1423675815.31.0.721977402363.issue23446@psf.upfronthosting.co.za> Message-ID: <1423739938.53.0.538309545973.issue23446@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > In _testbuffer.c: ndim <= 64, so the changes aren't really necessary. Indeed, I'll remove these changes. > The reason is of course that even an array with only 2 elements per dimension gets quite large with ndim=64. :) But an array can be with 1 element per dimension. In any case it is good that there is strict limitation on ndim values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:19:58 2015 From: report at bugs.python.org (Carl Chenet) Date: Thu, 12 Feb 2015 11:19:58 +0000 Subject: [issue23453] Opening a stream with tarfile.open() triggers a TypeError: can't concat bytes to str error Message-ID: <1423739998.49.0.706967373594.issue23453@psf.upfronthosting.co.za> New submission from Carl Chenet: I'm trying to use a tar stream to a Python tarfile object but each time I do have a TypeError: can't concat bytes to str error Here is my test: -----8<----- #!/usr/bin/python3.4 import tarfile import sys tarobj = tarfile.open(mode='r|', fileobj=sys.stdin) print(tarobj) tarobj.close() -----8<----- $ tar cvf test.tar.gz tests/ tests/ tests/foo1 tests/foo/ tests/foo/bar $ tar -O -xvf test.tar | ./tarstream.py tests/ tests/foo1 tests/foo/ tests/foo/bar Traceback (most recent call last): File "./tarstream.py", line 6, in tarobj = tarfile.open(mode='r|', fileobj=sys.stdin) File "/usr/lib/python3.4/tarfile.py", line 1578, in open t = cls(name, filemode, stream, **kwargs) File "/usr/lib/python3.4/tarfile.py", line 1470, in __init__ self.firstmember = self.next() File "/usr/lib/python3.4/tarfile.py", line 2249, in next tarinfo = self.tarinfo.fromtarfile(self) File "/usr/lib/python3.4/tarfile.py", line 1082, in fromtarfile buf = tarfile.fileobj.read(BLOCKSIZE) File "/usr/lib/python3.4/tarfile.py", line 535, in read buf = self._read(size) File "/usr/lib/python3.4/tarfile.py", line 543, in _read return self.__read(size) File "/usr/lib/python3.4/tarfile.py", line 569, in __read self.buf += buf TypeError: can't concat bytes to str Regards, Carl Chenet ---------- components: Library (Lib) messages: 235808 nosy: chaica_ priority: normal severity: normal status: open title: Opening a stream with tarfile.open() triggers a TypeError: can't concat bytes to str error type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:27:04 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 11:27:04 +0000 Subject: [issue20486] msilib: can't close opened database In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za> Message-ID: <1423740424.69.0.31984920819.issue20486@psf.upfronthosting.co.za> Mark Lawrence added the comment: Sorry folks I can't try this myself as I'm not running 2.7 and I don't know how to create the test.msi file. ---------- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:30:06 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Feb 2015 11:30:06 +0000 Subject: [issue23453] Opening a stream with tarfile.open() triggers a TypeError: can't concat bytes to str error In-Reply-To: <1423739998.49.0.706967373594.issue23453@psf.upfronthosting.co.za> Message-ID: <1423740606.52.0.128608873869.issue23453@psf.upfronthosting.co.za> Martin Panter added the comment: Using fileobj=sys.stdin.buffer instead should do the trick. The ?tarfile? module would expect a binary stream, not a text stream. Given the documentation currently says, ?Use this variant in combination with e.g. sys.stdin, . . .?, I presume that is why you were using plain stdin. The documentation should be clarified. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:38:12 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 11:38:12 +0000 Subject: [issue20391] windows python launcher should support explicit 64-bit version In-Reply-To: <1390666697.34.0.8179359034.issue20391@psf.upfronthosting.co.za> Message-ID: <1423741092.27.0.415947189482.issue20391@psf.upfronthosting.co.za> Mark Lawrence added the comment: Having read https://docs.python.org/3/using/windows.html#customizing-default-python-versions I'm not convinced that this is needed, as the first sentence of the fifth paragraph states "On 64-bit Windows with both 32-bit and 64-bit implementations of the same (major.minor) Python version installed, the 64-bit version will always be preferred." ---------- components: +Windows nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:46:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 11:46:17 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423741577.39.0.190872741124.issue23450@psf.upfronthosting.co.za> STINNER Victor added the comment: The 64-bit support of Windows is still incomplete :-/ We tried to fix most of them, but there are still remaining issues. The main issue is #9566. I opened for example the issue #18295: "Possible integer overflow in PyCode_New()". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:49:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 11:49:50 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423741790.13.0.961293516188.issue23450@psf.upfronthosting.co.za> STINNER Victor added the comment: signal_cast_socket_t.patch: Fix warning in signal.set_wakeup_fd(). I introduced recently the warning when I added support for sockets in this function on Windows. ---------- Added file: http://bugs.python.org/file38109/signal_cast_socket_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 12:56:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 11:56:15 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1423742175.97.0.925443563227.issue23314@psf.upfronthosting.co.za> STINNER Victor added the comment: "When we completely switch Windows builds over to VC14, we're going to encounter some new assert dialogs from the CRT. (...) A number of tests attempt operations on bad file descriptors, which will assert and terminate in MSVCRT (I have a fix for the termination coming, but the assertions will still appear)." Can you give some examples of tests which fail with an assertion error? _PyVerify_fd() doesn't protect use against the assertion error? I would prefer to keep CRT error checks, to protect us against bugs. -- Instead of patching faulthandler, you should patch test.support.SuppressCrashReport.__enter__. This function already calls SetErrorMode(). Instead of ctypes, the function may be exposed in the _winapi module for example. I'm talking about SetErrorMode() *and* _CrtSetReportMode(). +#if defined MS_WINDOWS && defined _DEBUG + if ((p = Py_GETENV("PYTHONNOCRTASSERT")) && *p != '\0') { + _CrtSetReportMode(_CRT_ASSERT, 0); + } +#endif The function is not available if _DEBUG is not defined? Why not calling the function if _DEBUG is not defined? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 13:00:07 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 12:00:07 +0000 Subject: [issue20523] global .pdbrc on windows 7 not reachable out of the box In-Reply-To: <1391637453.5.0.977818995818.issue20523@psf.upfronthosting.co.za> Message-ID: <1423742407.67.0.150872490269.issue20523@psf.upfronthosting.co.za> Mark Lawrence added the comment: We have a patch to review or we need a doc patch, unless someone has a different idea to the approaches suggested by the originator. I prefer the idea of changing the code, manually changing environment variables just seems wrong to me, but I won't lose any sleep over it. ---------- components: +Library (Lib), Windows nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 13:06:47 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 12:06:47 +0000 Subject: [issue20521] [PATCH] Cleanup for "dis" module documentation In-Reply-To: <1391608572.54.0.381225308012.issue20521@psf.upfronthosting.co.za> Message-ID: <1423742807.87.0.779597485297.issue20521@psf.upfronthosting.co.za> Mark Lawrence added the comment: Could someone review the patch please, it doesn't appear to contain anything that's contentious. ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 13:18:27 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 12:18:27 +0000 Subject: [issue20947] -Wstrict-overflow findings In-Reply-To: <1394991597.86.0.942219538296.issue20947@psf.upfronthosting.co.za> Message-ID: <1423743507.4.0.17755909673.issue20947@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Serhiy/Victor I believe that you're both interested in this type of problem. ---------- nosy: +BreamoreBoy, haypo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 13:26:07 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 12 Feb 2015 12:26:07 +0000 Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc In-Reply-To: <1423739938.53.0.538309545973.issue23446@psf.upfronthosting.co.za> Message-ID: <20150212122548.GA4356@bytereef.org> Stefan Krah added the comment: Yes, but these (degenerate) arrays tend to arise only as a result of slicing. Last time I looked NumPy had MAX_NDIM=32, so we should be fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 13:27:11 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 12:27:11 +0000 Subject: [issue21107] Add pgen.vcxproj to allow regenerating grammar files on Windows In-Reply-To: <1396238659.26.0.487973987032.issue21107@psf.upfronthosting.co.za> Message-ID: <1423744031.44.0.665203395123.issue21107@psf.upfronthosting.co.za> Mark Lawrence added the comment: Would you guys please review the patch as it's Double Dutch to me. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 13:29:12 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 12:29:12 +0000 Subject: [issue17306] Improve the way abstract base classes are shown in help() In-Reply-To: <1361932149.15.0.421194254516.issue17306@psf.upfronthosting.co.za> Message-ID: <1423744152.8.0.164971576683.issue17306@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 14:21:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 13:21:24 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1423747284.24.0.781334495158.issue20699@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch LGTM. But native speaker should check documentation part. ---------- title: Behavior of ZipFile with file-like object and BufferedWriter. -> Document that binary IO classes work with bytes-likes objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 14:24:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 13:24:05 +0000 Subject: [issue23383] Clean up bytes formatting In-Reply-To: <1422952973.11.0.84169569208.issue23383@psf.upfronthosting.co.za> Message-ID: <1423747445.97.0.591563833318.issue23383@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 14:38:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 13:38:02 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423748282.11.0.464550399959.issue23450@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: signal_cast_socket_t.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:09:55 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 14:09:55 +0000 Subject: [issue20391] windows python launcher should support explicit 64-bit version In-Reply-To: <1390666697.34.0.8179359034.issue20391@psf.upfronthosting.co.za> Message-ID: <1423750195.78.0.794706107667.issue20391@psf.upfronthosting.co.za> Steve Dower added the comment: It may be useful if you want an error rather than the 32-bit version, though there are other ways to check that if it's critical and it probably is better in the script. Patches welcome :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:17:07 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 14:17:07 +0000 Subject: [issue20088] locale.getlocale() fails if locale name doesn't include encoding In-Reply-To: <1388223842.98.0.521951916148.issue20088@psf.upfronthosting.co.za> Message-ID: <1423750627.41.0.454907108008.issue20088@psf.upfronthosting.co.za> Mark Lawrence added the comment: With #20079 closed but #20087 still open where do we stand with this issue? ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:17:19 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 14:17:19 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1423750639.26.0.597512478999.issue23314@psf.upfronthosting.co.za> Steve Dower added the comment: _Py_verifyfd has to go away, unfortunately. It requires inside knowledge of the exact CRT version, and with VC14 the CRT will automatically upgrade so that we're always using the latest. I've gotten a function added to the CRT to make it unnecessary for release builds (which terminate on invalid fds). However, debug builds will display a message box still, which affects the buildbots. test already suppresses the dialogs for its own process, but when it creates subprocesses they don't inherit that setting. An environment variable is an easy way to make sure that all subprocesses also have assert dialogs disabled. In release builds they are always disabled, hence the _DEBUG check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:22:15 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 14:22:15 +0000 Subject: [issue20503] super behaviour and abstract base classes (either implementation or documentation/error message is wrong) In-Reply-To: <1391441802.61.0.557224247712.issue20503@psf.upfronthosting.co.za> Message-ID: <1423750935.59.0.843910162669.issue20503@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +rhettinger title: super behavioru and abstract base classes (either implementation or documentation/error message is wrong) -> super behaviour and abstract base classes (either implementation or documentation/error message is wrong) versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:22:22 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 14:22:22 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423750942.66.0.712940714826.issue23450@psf.upfronthosting.co.za> Steve Dower added the comment: Wow, I didn't expect that so quickly :) I'll check these out as soon as I can, but they look okay from a quick glance on my phone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:23:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 14:23:42 +0000 Subject: [issue23146] Incosistency in pathlib between / and \ In-Reply-To: <1420191625.18.0.999730856462.issue23146@psf.upfronthosting.co.za> Message-ID: <1423751022.24.0.308082715266.issue23146@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:28:11 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 12 Feb 2015 14:28:11 +0000 Subject: [issue21107] Add pgen.vcxproj to allow regenerating grammar files on Windows In-Reply-To: <1396238659.26.0.487973987032.issue21107@psf.upfronthosting.co.za> Message-ID: <1423751291.47.0.0181705840284.issue21107@psf.upfronthosting.co.za> Zachary Ware added the comment: The patch is way out of date, pgen.vcxproj needs to be updated to match the rest of our projects. If nobody else takes this over (and it is low priority for a reason!), I'll get back to it eventually. ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:31:59 2015 From: report at bugs.python.org (Ulrich Dorsch) Date: Thu, 12 Feb 2015 14:31:59 +0000 Subject: [issue23454] plistlib and xml.parsers.expat python3 problems with strings and bytes Message-ID: <1423751518.98.0.629522641345.issue23454@psf.upfronthosting.co.za> New submission from Ulrich Dorsch: TypeError: startswith first arg must be str or a tuple of str, not bytes In line 558 of plistlib.py at the beginnging of "def _is_fmt_xml(header)" is the problem, caused by the use of the byte arguments defined in line 555 (prefixes = (b' _______________________________________ From report at bugs.python.org Thu Feb 12 15:34:56 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 14:34:56 +0000 Subject: [issue21568] Win32 pip doesn't use relative path to found site-packages. In-Reply-To: <1400898605.95.0.696955822975.issue21568@psf.upfronthosting.co.za> Message-ID: <1423751696.94.0.587436414507.issue21568@psf.upfronthosting.co.za> Mark Lawrence added the comment: I'm not certain exactly what is being asked for here so could the originator please clarify their needs? I also don't really know who "owns" this hence the changes to the nosy list. ---------- components: +Windows nosy: +BreamoreBoy, dstufft, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:46:44 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 14:46:44 +0000 Subject: [issue21874] test_strptime fails on rhel/centos/fedora systems In-Reply-To: <1403826345.9.0.88896627543.issue21874@psf.upfronthosting.co.za> Message-ID: <1423752404.25.0.570126377508.issue21874@psf.upfronthosting.co.za> Mark Lawrence added the comment: Have there been any recent reports of this test failing on these platforms? ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:47:47 2015 From: report at bugs.python.org (Pod) Date: Thu, 12 Feb 2015 14:47:47 +0000 Subject: =?utf-8?b?W2lzc3VlMjMyOTddIOKAmHRva2VuaXplLmRldGVjdF9lbmNvZGluZ+KAmSBp?= =?utf-8?q?s_confused_between_text_and_bytes=3A_no_=E2=80=98startswith?= =?utf-8?q?=E2=80=99_method_on_a_byte_string?= In-Reply-To: <1421901626.89.0.392776519963.issue23297@psf.upfronthosting.co.za> Message-ID: <1423752467.79.0.0846467890261.issue23297@psf.upfronthosting.co.za> Pod added the comment: Not the OP, but I find this message a bug because it's confusing from the perspective of a user of the tokenize() function. If you give tokenize a readlines() that returns a str, you get this error message that confusingly states that something inside tokenize must be a string and NOT a bytes, even though the user gave readlines a string, not a bytes. It looks like an internal bug. Turns out it's because the contact changed from python2 to 3. Personally, I'd been accidentally reading the python2 page for the tokenize library instead of python3, and had been using tokenize.generate_tokens in my python 3 code which accepts a io.StringIO just fine. When I realising my mistake and switched to the python3 version of the page I noticed generate_tokens is no longer supported, even though the code I had was working, and I noticed that the definition of tokenize had changed to match the old generate_tokens (along with a subtle change in the definition of the acceptable readlines function). So when I switched from tokenize.generate_tokens to tokenize.tokenize to try and use the library as intended, I get the same error as OP. Perhaps OP made a similar mistake? To actually hit the error in question: $ cat -n temp.py 1 import tokenize 2 import io 3 4 5 byte_reader = io.BytesIO(b"test bytes generate_tokens") 6 tokens = tokenize.generate_tokens(byte_reader.readline) 7 8 byte_reader = io.BytesIO(b"test bytes tokenize") 9 tokens = tokenize.tokenize(byte_reader.readline) 10 11 byte_reader = io.StringIO("test string generate") 12 tokens = tokenize.generate_tokens(byte_reader.readline) 13 14 str_reader = io.StringIO("test string tokenize") 15 tokens = tokenize.tokenize(str_reader.readline) 16 17 $ python3 temp.py Traceback (most recent call last): File "temp.py", line 15, in tokens = tokenize.tokenize(str_reader.readline) File "C:\work\env\python\Python34_64\Lib\tokenize.py", line 467, in tokenize encoding, consumed = detect_encoding(readline) File "C:\work\env\python\Python34_64\Lib\tokenize.py", line 409, in detect_encoding if first.startswith(BOM_UTF8): TypeError: startswith first arg must be str or a tuple of str, not bytes ---------- nosy: +Pod _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:55:00 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 14:55:00 +0000 Subject: [issue21568] Win32 pip doesn't use relative path to found site-packages. In-Reply-To: <1400898605.95.0.696955822975.issue21568@psf.upfronthosting.co.za> Message-ID: <1423752900.77.0.518836148238.issue21568@psf.upfronthosting.co.za> Steve Dower added the comment: Do you mean pip.exe? Does running 'python.exe -m pip install ...' work for you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 15:57:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 14:57:09 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423753029.33.0.364956024141.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch. Thanks for the review Serhiy. ---------- Added file: http://bugs.python.org/file38110/scandir-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:02:14 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 12 Feb 2015 15:02:14 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1423753334.83.0.371355818759.issue15914@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm adding Nick to see if he has anything to add since he was the one that worked on the change that Richard said caused the problem. But in my opinion this is in the same realm as importing as a side-effect of spawning a thread; don't do it. ---------- nosy: +ncoghlan status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:20:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 15:20:30 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423754430.86.0.544897678933.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: (I regenerated scandir-4.patch, I had a local private changeset. I removed it.) ---------- Added file: http://bugs.python.org/file38111/scandir-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:20:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 15:20:42 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423754442.86.0.915401504453.issue22524@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file38110/scandir-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:30:19 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 12 Feb 2015 15:30:19 +0000 Subject: [issue23447] Relative imports with __all__ attribute In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> Message-ID: <1423755019.33.0.851031361212.issue23447@psf.upfronthosting.co.za> Brett Cannon added the comment: If you put a print call after your `from . import *` call you will notice it never gets executed. Basically import is still in the middle of finishing imports when that import * is reached, including setting the module attributes on the package. Basically you have a circular import. ---------- nosy: +brett.cannon resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:33:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 15:33:08 +0000 Subject: [issue23454] plistlib and xml.parsers.expat python3 problems with strings and bytes In-Reply-To: <1423751518.98.0.629522641345.issue23454@psf.upfronthosting.co.za> Message-ID: <1423755188.2.0.42369142204.issue23454@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: All correct. plistlib.load() requires binary file object as documented [1]. [1] https://docs.python.org/3/library/plistlib.html#plistlib.load ---------- nosy: +ronaldoussoren, serhiy.storchaka resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:34:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 15:34:04 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1423750639.26.0.597512478999.issue23314@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: "An environment variable is an easy way to make sure that all subprocesses also have assert dialogs disabled. In release builds they are always disabled, hence the _DEBUG check." If _PyVerify_fd() must go, I would prefer to always disable CRT check. Otherwise, os.dup() would open the CRT assertion popup, instead of raising OSError(EBADF). I prefer to have the same behaviour with any version of the CRT and any version of the Visual Studio. You may add an environment variable to explicitly *enable* the check, if you want. Programming with Python is different than programming with C. Python always raise an OSError(EBADF) exception. It's not like the C language, where you have to explicitly check the result of each function call. It's difficult to ignore OSError without notifying it. I don't know other CRT checks. Many other checks make sense for Python too? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:35:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Feb 2015 15:35:15 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <20150212153500.37939.96557@psf.io> Roundup Robot added the comment: New changeset 9e10c4255277 by Victor Stinner in branch 'default': Issue #23450: Fix signal.set_wakeup_fd() on Windows https://hg.python.org/cpython/rev/9e10c4255277 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:35:47 2015 From: report at bugs.python.org (eryksun) Date: Thu, 12 Feb 2015 15:35:47 +0000 Subject: [issue20088] locale.getlocale() fails if locale name doesn't include encoding In-Reply-To: <1388223842.98.0.521951916148.issue20088@psf.upfronthosting.co.za> Message-ID: <1423755347.63.0.0653433172906.issue20088@psf.upfronthosting.co.za> eryksun added the comment: For 3.5 this affects Windows as well, since the new CRT supports RFC1766 language codes, but only without a codepage spec: Python 3.5.0a1 (v3.5.0a1:5d4b6a57d5fd, Feb 7 2015, 18:15:14) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_ALL, 'en-GB') 'en-GB' >>> locale.getlocale() Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python35\lib\locale.py", line 578, in getlocale return _parse_localename(localename) File "C:\Program Files\Python35\lib\locale.py", line 487, in _parse_localename raise ValueError('unknown locale: %s' % localename) ValueError: unknown locale: en-GB On Vista+ (since 3.5 drops XP support) the codepage can be queried easily via GetLocaleInfoEx: >>> from ctypes import * >>> LOCALE_IDEFAULTANSICODEPAGE = 0x1004 >>> GetLocaleInfoEx = WinDLL('kernel32').GetLocaleInfoEx >>> info = (c_wchar * 100)() >>> GetLocaleInfoEx("en-GB", LOCALE_IDEFAULTANSICODEPAGE, info, len(info)) 5 >>> info.value '1252' >>> GetLocaleInfoEx("zh-CN", LOCALE_IDEFAULTANSICODEPAGE, info, len(info)) 4 >>> info.value '936' Note that Windows follows the RFC spec here (not POSIX), using a hyphen instead of an underscore. This is a bit of tangent, but for the Windows full language_country.codepage form, the X-11 based locale_alias dict is generally useless. So, contrary to the docs, on Windows getlocale doesn't return the language code in RFC 1766 form. In some cases it does, but only by chance. ---------- components: +Windows nosy: +eryksun, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:53:08 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 15:53:08 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1423756388.69.0.952708465166.issue23314@psf.upfronthosting.co.za> Steve Dower added the comment: EBADF will still be returned; _PyVerify_fd is only there to prevent the assertion dialogs in debug builds. Release builds will not need _PyVerify_fd at all (though it's public, so it will remain, but it won't be necessary to protect calls into the CRT). As I said, there is a change coming in a CRT update that will make file calls behave more like POSIX, ie. returning EBADF instead of crashing. See #4804 and #3545 for the discussions (and complaints) about turning off all assertion dialogs. Note that this issue only affects the dialogs in debug builds, and that for Python 3.5 we'll be making debug builds more widely available so that people can debug their extensions/hosts (see e.g. #22411). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:53:11 2015 From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=) Date: Thu, 12 Feb 2015 15:53:11 +0000 Subject: [issue21568] Win32 pip doesn't use relative path to found site-packages. In-Reply-To: <1423752900.77.0.518836148238.issue21568@psf.upfronthosting.co.za> Message-ID: ?? ? added the comment: yes python -m pip works for me but pip.exe doesn't work 2015?2?12? ??10:55? "Steve Dower" ??? > > Steve Dower added the comment: > > Do you mean pip.exe? Does running 'python.exe -m pip install ...' work for > you? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 16:55:46 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 15:55:46 +0000 Subject: [issue21568] Win32 pip doesn't use relative path to found site-packages. In-Reply-To: <1400898605.95.0.696955822975.issue21568@psf.upfronthosting.co.za> Message-ID: <1423756546.17.0.481307162517.issue21568@psf.upfronthosting.co.za> Steve Dower added the comment: In that case, this should be reported to the setuptools project, since they are responsible for creating the pip.exe launcher when pip is installed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 17:05:56 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 12 Feb 2015 16:05:56 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1423757156.5.0.283729887885.issue23314@psf.upfronthosting.co.za> Steve Dower added the comment: To be clearer (while still respecting the confidentiality agreement I'm under), previously this code would (if _DEBUG) display an assertion dialog and (regardless of _DEBUG) terminate the process: close(fd); // succeeds, assuming a good fd close(fd); // crashes here This code would not display the dialog, but would still terminate: _CrtSetReportMode(_CRT_ASSERT, 0); close(fd); close(fd); This code would not display the dialog or terminate, but depends on knowing implementation details of the CRT: if (!_PyVerify_fd(fd)) return posix_error() res = close(fd); if (res < 0) return posix_error() if (!_PyVerify_fd(fd)) return posix_error() res = close(fd); if (res < 0) return posix_error() Soon we'll have a safe way (including in the presence of threads) to do this: _DONT_TERMINATE_ON_INVALID_PARAMETER_ON_THIS_THREAD res = close(fd); if (res < 0) return posix_error() res = close(fd); // would have terminated, but now returns EBADF if (res < 0) return posix_error() _ALLOW_TERMINATE_ON_INVALID_PARAMETER_ON_THIS_THREAD In the last case, we prevent termination but can't safely suppress the _DEBUG dialog in the same way. SuppressCrashHandler works for its purpose, since the OS error mode is inherited by child processes. The _CrtSetReportMode setting is *not* inherited, and so it needs to be called in every child process created by tests. Maybe it's possible to add the call into every test, but I'm skeptical (especially considering the multiprocessing tests). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 17:26:39 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 12 Feb 2015 16:26:39 +0000 Subject: [issue10486] http.server doesn't set all CGI environment variables In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za> Message-ID: <1423758399.59.0.845961355694.issue10486@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 17:34:14 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 12 Feb 2015 16:34:14 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <1423655171.77.0.0216146047129.issue23442@psf.upfronthosting.co.za> Message-ID: <1423758854.02.0.210658278719.issue23442@psf.upfronthosting.co.za> Demian Brecht added the comment: The attached patch fixes the name ---------- keywords: +patch Added file: http://bugs.python.org/file38112/issue23442.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 17:42:19 2015 From: report at bugs.python.org (Erick Jones) Date: Thu, 12 Feb 2015 16:42:19 +0000 Subject: [issue9698] When reusing an handler, urllib(2)'s digest authentication fails after multiple regative replies In-Reply-To: <1282892368.57.0.758322534297.issue9698@psf.upfronthosting.co.za> Message-ID: <1423759339.06.0.481598200209.issue9698@psf.upfronthosting.co.za> Erick Jones added the comment: This ended up biting me also. I had a list of URLs to fetch with authentication. One of the URLs was bad (returning 401 even with authentication), and that was causing all of the subsequent URLs to fail as well since the reset count wasn't getting reset. I also don't like that the retry count is stored in the handler -- that's mutable global state, which wreaks havoc if I use this with Eventlet coroutines for concurrent page fetches. (If I just add the authentication headers myself, then urllib2 works just fine under Eventlet.) Couldn't the retry count be stored in the request object itself? And why do we even need a retry "count"? If it fails without authentication, then try it with authentication. If it fails again, just return to the application. It makes no sense to retry four more times. ---------- nosy: +Erick.Jones _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 18:24:40 2015 From: report at bugs.python.org (Antonio Cota) Date: Thu, 12 Feb 2015 17:24:40 +0000 Subject: [issue23447] Relative imports with __all__ attribute In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> Message-ID: <1423761880.12.0.846767367635.issue23447@psf.upfronthosting.co.za> Antonio Cota added the comment: I tried the following on python 3.5.0a1: #init.py __all__ = ['second', 'first'] print('i\'m starting the directory') #first.py print('hi, i\'m the first') from . import second #second.py print('hi, i\'m the second') from . import first >>> import a.first i'm starting the directory hi, i'm the first hi, i'm the second it just worked out perfectly, no errors. But the case I show before still continues to get the AttributeError error. You told me that basically it doesn't work because it is a circular import, but isn't python already able to manage circular import? What I expected when running the "from . import *" statament was Python looking up in the __all__ attribute and import everything within it. When it had to import 'first' I expected Python to check in the sys.modules to see if it was already imported so, in this case, it could see that first.py was already imported and no error was raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 18:25:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 17:25:51 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423761951.86.0.162200728226.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 5: - Use None value for the d_type instead of DT_UNKNOW to *prepare* support for platforms where the dirent structure has no d_type field. Serhiy guess that such platform have no DT_xxx constant neither. DirEntry doesn't DT_xxx constants if d_type is None - Fix test_removed_file() and test_removed_dir() tests if d_type is unknown (I tested manually by forcing d_type to None) - Use os.lstat() instead of os.stat(follow_symlinks=False) in DirEntry.inode(), it's a little bit faster even if it's the same syscall. The cost probably comes from the code parsing Python parameters, especially the keyword ---------- Added file: http://bugs.python.org/file38113/scandir-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 18:25:53 2015 From: report at bugs.python.org (Antonio Cota) Date: Thu, 12 Feb 2015 17:25:53 +0000 Subject: [issue23447] Relative imports with __all__ attribute In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> Message-ID: <1423761953.69.0.101648509181.issue23447@psf.upfronthosting.co.za> Changes by Antonio Cota : ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 19:00:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 18:00:54 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423764054.49.0.125407984594.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: bench_scandir.py: dummy benchmark to compare listdir+stat vs scandir+is_dir. os.scandir() is always slower than os.listdir() on tmpfs and ext4 partitions of a local hard driver. I will try with NFS. Results with scandir-5.patch on Fedora 21 (Linux). --- Using /home/haypo (ext4, hard drive) --- Test listdir+stat vs scandir+is_dir Temporary directory: /home/haypo/tmpji8uviyl Create 100000 files+symlinks... Create 10000 directories... # entries: 210000 Benchmark... listdir: 2187.3 ms scandir: 1047.2 ms listdir: 494.4 ms scandir: 1048.1 ms listdir: 493.0 ms scandir: 1042.6 ms Result: listdir: min=493.0 ms (2.3 us per file), max=2187.3 ms (10.4 us per file) scandir: min=1042.6 ms (5.0 us per file), max=1048.1 ms (5.0 us per file) scandir is between 0.5x and 2.1x faster --- Using /tmp (tmpfs, full in memory) --- Test listdir+stat vs scandir+is_dir Temporary directory: /tmp/tmp6_zk3mqo Create 100000 files+symlinks... Create 10000 directories... # entries: 210000 Benchmark... listdir: 405.4 ms scandir: 1001.3 ms listdir: 403.3 ms scandir: 1024.2 ms listdir: 408.1 ms scandir: 1013.5 ms Remove the temporary directory... Result: listdir: min=403.3 ms (1.9 us per file), max=408.1 ms (1.9 us per file) scandir: min=1001.3 ms (4.8 us per file), max=1024.2 ms (4.9 us per file) scandir is between 0.4x and 0.4x faster ---------- Added file: http://bugs.python.org/file38114/bench_scandir.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 19:25:12 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 12 Feb 2015 18:25:12 +0000 Subject: [issue9698] When reusing an handler, urllib(2)'s digest authentication fails after multiple regative replies In-Reply-To: <1282892368.57.0.758322534297.issue9698@psf.upfronthosting.co.za> Message-ID: <1423765512.58.0.942758020702.issue9698@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 19:48:55 2015 From: report at bugs.python.org (Andrew Dalke) Date: Thu, 12 Feb 2015 18:48:55 +0000 Subject: [issue23455] file iterator "deemed broken"; can resume after StopIteration Message-ID: <1423766934.46.0.3718920034.issue23455@psf.upfronthosting.co.za> New submission from Andrew Dalke: The file iterator is "deemed broken". As I don't think it should be made non-broken, I suggest the documentation should be changed to point out when file iteration is broken. I also think the term 'broken' is a label with needlessly harsh connotations and should be softened. The iterator documentation uses the term 'broken' like this (quoting here from https://docs.python.org/3.4/library/stdtypes.html): Once an iterator?s __next__() method raises StopIteration, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken. (Older versions comment "This constraint was added in Python 2.3; in Python 2.2, various iterators are broken according to this rule.") An IOBase is supposed to support the iterator protocol (says https://docs.python.org/3.4/library/io.html#io.IOBase ). However, it does not, nor does the documentation say that it's broken in the face of a changing file (eg, when another process appends to a log file). % ./python.exe Python 3.5.0a1+ (default:4883f9046b10, Feb 11 2015, 04:30:46) [GCC 4.8.4] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> f = open("empty") >>> next(f) Traceback (most recent call last): File "", line 1, in StopIteration >>> >>> ^Z Suspended % echo "Hello!" >> empty % fg ./python.exe >>> next(f) 'Hello!\n' This is apparently well-known behavior, as I've come across several references to it on various Python-related lists, including this one from Miles in 2008: https://mail.python.org/pipermail/python-list/2008-September/491920.html . Strictly speaking, file objects are broken iterators: Fredrik Lundh in the same thread ( https://mail.python.org/pipermail/python-list/2008-September/521090.html ) says: it's a design guideline, not an absolute rule The 7+ years of 'broken' behavior in Python suggests that /F is correct. But while 'broken' could be considered a meaningless label, it carries with it some rather negative connotations. It sounds like developers are supposed to make every effort to avoid broken code, when that's not something Python itself does. It also means that my code can be called "broken" solely because it assumed Python file iterators are non-broken. I am not happy when people say my code is broken. It is entirely reasonable that a seek(0) would reset the state and cause next(it) to not continue to raise a StopIteration exception. However, errors can arise when using Python file objects, as an iterator, to parse a log file or any other files which are appended to by another process. Here's an example of code that can break. It extracts the first and last elements of an iterator; more specifically, the first and last lines of a file. If there are no lines it returns None for both values; and if there's only one line then it returns the same line as both values. def get_first_and_last_elements(it): first = last = next(it, None) for last in it: pass return first, last This code expects a non-broken iterator. If passed a file, and the file were 1) initially empty when the next() was called, and 2) appended to by the time Python reaches the for loop, then it's possible for first value to be None while last is a string. This is unexpected, undocumented, and may lead to subtle errors. There are work-arounds, like ensuring that the StopIteration only occurs once: def get_first_and_last_elements(it): first = last = next(it, None) if last is not None: for last in it: pass return first, last but much existing code expects non-broken iterators, such as the Python example implementation at https://docs.python.org/2/library/itertools.html#itertools.dropwhile . (I have a reproducible failure using it, a fork(), and a file iterator with a sleep() if that would prove useful.) Another option is to have a wrapper around file object iterators to keep raising StopIteration, like: def safe_iter(it): yield from it # -or- (line for line in file_iter) but people need to know to do this with file iterators or other potentially broken iterators. The current documentation does not say when file iterators are broken, and I don't know which other iterators are also broken. I realize this is a tricky issue. I don't think it's possible now to change the file's StopIteration behavior. I expect that there is code which depends on the current brokenness, the ability to seek() and re-iterate is useful, and the idea that next() returns text if and only if readline() is not empty is useful and well-entrenched. Pypy has the same behavior as CPython so any change will take some time to propagate to the other implementations. Instead, I'm fine with a documentation change in io.html . It currently says: IOBase (and its subclasses) support the iterator protocol, meaning that an IOBase object can be iterated over yielding the lines in a stream. Lines are defined slightly differently depending on whether the stream is a binary stream (yielding bytes), or a text stream (yielding unicode strings). See readline() below. I suggest adding something like: The file iterator does not completely follow the iterator protocol. If new data is added to the file after the iterator raises a StopIteration then next(file) will resume returning lines. The safest way to iterate over lines in a log file or other changing file is use a generator comprehension: (line for line in file) The iterator may also resume after using seek() to move the file position. You'll note that I failed to use the term "broken". This should really start The file iterator is broken. I find that term rather harsh, and since broken iterators are acceptable in Python, I suggest toning down or qualifying the use of "broken" in stdtypes.html. I have no suggestions for an improved version. ---------- assignee: docs at python components: Documentation messages: 235850 nosy: dalke, docs at python priority: normal severity: normal status: open title: file iterator "deemed broken"; can resume after StopIteration versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 19:55:28 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 12 Feb 2015 18:55:28 +0000 Subject: [issue23455] file iterator "deemed broken"; can resume after StopIteration In-Reply-To: <1423766934.46.0.3718920034.issue23455@psf.upfronthosting.co.za> Message-ID: <1423767328.58.0.572741924854.issue23455@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 20:21:54 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Feb 2015 19:21:54 +0000 Subject: [issue23146] Incosistency in pathlib between / and \ In-Reply-To: <1420191625.18.0.999730856462.issue23146@psf.upfronthosting.co.za> Message-ID: <1423768914.67.0.803299779416.issue23146@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, this is a bug indeed. A patch would be welcome ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 20:28:51 2015 From: report at bugs.python.org (eryksun) Date: Thu, 12 Feb 2015 19:28:51 +0000 Subject: [issue20503] super behaviour and abstract base classes (either implementation or documentation/error message is wrong) In-Reply-To: <1391441802.61.0.557224247712.issue20503@psf.upfronthosting.co.za> Message-ID: <1423769331.67.0.286264431874.issue20503@psf.upfronthosting.co.za> eryksun added the comment: Given super(cls, obj), cls needs to be somewhere in type(obj).__mro__. Thus the implementation checks PyType_IsSubtype instead of the more generic PyObject_IsSubclass. In this case int's MRO is unrelated to numbers.Number: >>> print(*int.__mro__, sep='\n') It gets registered as a subclass via numbers.Integral.register(int). >>> print(*numbers.Integral._abc_registry) issubclass calls PyObject_IsSubclass, which uses the __subclasscheck__ API. In this case ABCMeta.__subclasscheck__ recursively checks the registry and caches the result to speed up future checks. >>> numbers.Number.__subclasscheck__(int) True >>> print(*numbers.Number._abc_cache) ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 20:47:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 12 Feb 2015 19:47:03 +0000 Subject: [issue21717] Exclusive mode for ZipFile and TarFile In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za> Message-ID: <1423770423.2.0.869725307235.issue21717@psf.upfronthosting.co.za> Changes by Berker Peksag : Added file: http://bugs.python.org/file38115/issue21717_tarfile_v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 21:32:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 20:32:02 +0000 Subject: [issue18295] Possible integer overflow in PyCode_New() In-Reply-To: <1372108745.44.0.114375127897.issue18295@psf.upfronthosting.co.za> Message-ID: <1423773122.91.0.753674887174.issue18295@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Many of these overflows can be provoked by specially constructed function, code object or bytecode. Also I think following examples crash or return wrong result on 64 bit platform: def f(*args, **kwargs): return len(args), len(kwargs) f(*([0]*(2**32+1))) f(**dict.fromkeys(map(hex, range(2**31+1)))) Here is updated patch which handles overflows in non-debug build. It prevent creating Python function with more than 255 default values (in any case compiler and interpreter don't support more than 255 arguments) and raise exception when function is called with too many arguments or too large *args or **kwargs. ---------- stage: -> patch review type: -> crash Added file: http://bugs.python.org/file38116/code_ssize_t_2.patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 21:40:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 20:40:56 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423773656.22.0.509444994663.issue23450@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please ignore changes to Objects/codeobject.c, Objects/funcobject.c and Python/ceval.c. The patch in issue18295 is more advanced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 22:36:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Feb 2015 21:36:44 +0000 Subject: [issue23146] Incosistency in pathlib between / and \ In-Reply-To: <1420191625.18.0.999730856462.issue23146@psf.upfronthosting.co.za> Message-ID: <1423777004.84.0.00305010993969.issue23146@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. It also fixes tests which didn't test altsep. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file38117/pathlib_parse_parts_altsep.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 22:57:09 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Feb 2015 21:57:09 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <1423655171.77.0.0216146047129.issue23442@psf.upfronthosting.co.za> Message-ID: <1423778229.55.0.323119456335.issue23442@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks. Confirming the patch fixes the problem for me, so should be comitted. I wonder if a test case would be good too though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 22:59:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 21:59:58 +0000 Subject: [issue23456] asyncio: add missing @coroutine decorators Message-ID: <1423778398.48.0.478290226002.issue23456@psf.upfronthosting.co.za> New submission from STINNER Victor: coroutine_decorator.patch adds missing @coroutine decorator to coroutine functions and methods in the asyncio module. I'm not sure that it's ok to add @coroutine to __iter__() methods. At least, test_asyncio pass. ---------- components: asyncio files: coroutine_decorator.patch keywords: patch messages: 235857 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: add missing @coroutine decorators versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38118/coroutine_decorator.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 23:09:02 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 12 Feb 2015 22:09:02 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1423778942.53.0.328079927645.issue23439@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t have a strong opinion about changing __all__ in these cases. I only noticed the potential problem when I went to add a new class to the module, and thought this was common practice. If we leave it as it is, it would be good to add comment in the source code explaining this decision. Also the test case could still be useful to catch future bugs. The currently situation means the status constants are be missing from pydoc help output, and are not available when you do ?from http.client import *? in the interactive interpreter. HTTPMessage is a strange class indeed; see Issue 5053. But it is referenced a few times by the documentation, so I originally assumed it should be in __all__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 23:09:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 22:09:04 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423778944.76.0.963324458906.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: Similar benchmark result on my laptop which has a SSD (ext4 filesystem tool, but I guess that the directory is small and fits into the memory). Note: I'm not sure that the "between ...x and ...x faster" are revelant, I'm not sure that my computation is correct. Test listdir+stat vs scandir+is_dir Temporary directory: /home/haypo/prog/python/default/tmpbrn4r2tv Create 100000 files+symlinks... Create 10000 directories... # entries: 210000 Benchmark... listdir: 1730.7 ms scandir: 1029.4 ms listdir: 476.8 ms scandir: 1058.3 ms listdir: 485.4 ms scandir: 1041.1 ms Remove the temporary directory... Result: listdir: min=476.8 ms (2.3 us per file), max=1730.7 ms (8.2 us per file) scandir: min=1029.4 ms (4.9 us per file), max=1058.3 ms (5.0 us per file) scandir is between 0.5x and 1.7x faster ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 23:19:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 22:19:54 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423779594.03.0.611229382909.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: Benchmark on NFS. Client: my laptop, connected to the LAN by wifi. Server: desktop, connected to the LAN by PLC. For an unknown reason, the creation of files, symlinks and directories is very slow (more than 30 seconds while I reduced the number of files & directories). Test listdir+stat vs scandir+is_dir Temporary directory: /home/haypo/mnt/tmp5aee0eic Create 1000 files+symlinks... Create 1000 directories... # entries: 3000 Benchmark... listdir: 14478.0 ms scandir: 732.1 ms listdir: 9.9 ms scandir: 14.9 ms listdir: 7.5 ms scandir: 12.9 ms Remove the temporary directory... Result: listdir: min=7.5 ms (2.5 us per file), max=14478.0 ms (4826.0 us per file) scandir: min=12.9 ms (4.3 us per file), max=732.1 ms (244.0 us per file) scandir is between 0.0x and 1119.6x faster ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 23:23:13 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 12 Feb 2015 22:23:13 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <1423655171.77.0.0216146047129.issue23442@psf.upfronthosting.co.za> Message-ID: <1423779793.08.0.16173908515.issue23442@psf.upfronthosting.co.za> Berker Peksag added the comment: I found another regression: In Python 3.4, 416 is REQUESTED_RANGE_NOT_SATISFIABLE, but REQUEST_RANGE_NOT_SATISFIABLE in 3.5. ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 23:27:17 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 12 Feb 2015 22:27:17 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <1423655171.77.0.0216146047129.issue23442@psf.upfronthosting.co.za> Message-ID: <1423780037.59.0.893972268386.issue23442@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a test case. ====================================================================== FAIL: test_client_constants (test.test_httplib.OfflineTest) (constant='REQUESTED_RANGE_NOT_SATISFIABLE') ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/berker/projects/cpython/default/Lib/test/test_httplib.py", line 985, in test_client_constants self.assertTrue(hasattr(client, const)) AssertionError: False is not true ====================================================================== FAIL: test_client_constants (test.test_httplib.OfflineTest) (constant='REQUEST_HEADER_FIELDS_TOO_LARGE') ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/berker/projects/cpython/default/Lib/test/test_httplib.py", line 985, in test_client_constants self.assertTrue(hasattr(client, const)) AssertionError: False is not true ---------- Added file: http://bugs.python.org/file38119/httpstatus_tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 12 23:35:17 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 12 Feb 2015 22:35:17 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <1423780037.59.0.893972268386.issue23442@psf.upfronthosting.co.za> Message-ID: <54DD2AA1.5070503@gmail.com> Demian Brecht added the comment: Thanks for the test Berker, I'll put a patch together with the changes later this afternoon. On 2015-02-12 2:27 PM, Berker Peksag wrote: > > Berker Peksag added the comment: > > Here is a test case. > > ====================================================================== > FAIL: test_client_constants (test.test_httplib.OfflineTest) (constant='REQUESTED_RANGE_NOT_SATISFIABLE') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/berker/projects/cpython/default/Lib/test/test_httplib.py", line 985, in test_client_constants > self.assertTrue(hasattr(client, const)) > AssertionError: False is not true > > ====================================================================== > FAIL: test_client_constants (test.test_httplib.OfflineTest) (constant='REQUEST_HEADER_FIELDS_TOO_LARGE') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/berker/projects/cpython/default/Lib/test/test_httplib.py", line 985, in test_client_constants > self.assertTrue(hasattr(client, const)) > AssertionError: False is not true > > ---------- > Added file: http://bugs.python.org/file38119/httpstatus_tests.diff > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 00:17:07 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 12 Feb 2015 23:17:07 +0000 Subject: [issue19433] Define PY_UINT64_T on Windows 32bit In-Reply-To: <1383054622.8.0.294038814234.issue19433@psf.upfronthosting.co.za> Message-ID: <1423783027.78.0.297044146245.issue19433@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is there any more work needed on this or can it be closed? Please note the reference to #17884 in msg201654. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 00:41:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Feb 2015 23:41:10 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423784470.61.0.520993795325.issue22524@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file38120/bench_scandir2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 01:32:32 2015 From: report at bugs.python.org (Brian Curtin) Date: Fri, 13 Feb 2015 00:32:32 +0000 Subject: [issue19433] Define PY_UINT64_T on Windows 32bit In-Reply-To: <1383054622.8.0.294038814234.issue19433@psf.upfronthosting.co.za> Message-ID: <1423787552.57.0.73108747778.issue19433@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 01:38:24 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 00:38:24 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423787904.82.0.874829610084.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: I enhanced bench_scandir2.py to have one command to create a directory or a different command to run the benchmark. All commands: - create: create the directory for tests (you don't need this command, you can also use an existing directory) - bench: compare scandir+is_dir to listdir+stat, cached - bench_nocache: compare scandir+is_dir to listdir+stat, flush disk caches - bench_nostat: compare scandir to listdir, cached - bench_nostat_nocache: compare scandir to listdir, flush disk caches -- New patch version 6 written for performances, changes: - On POSIX, decode the filename in C - _scandir() iterator now yields list of items, instead of an single item With my benchmarks, I see that yielding 10 items reduces the overhead of scandir on Linux (creating DirEntry objects). On Windows, the number of items has no effect. I prefer to also fetch entries 10 per 10 to mimic POSIX. Later, on POSIX, we may use directly getdents() and yield the full getdents() result at once. according to strace, it's currently around 800 entries per getdents() syscall. Results of bench_scandir2.py on my laptop using SSD and ext4 filesystem: - 110,100 entries (100,000 files, 100 symlinks, 10,000 directories) - bench: 1.3x faster (scandir: 164.9 ms, listdir: 216.3 ms) - bench_nostat: 0.4x faster (scandir: 104.0 ms, listdir: 38.5 ms) - bench_nocache: 2.1x faster (scandir: 460.2 ms, listdir: 983.2 ms) - bench_nostat_nocache: 2.2x faster (scandir: 480.4 ms, listdir: 1055.6 ms) Results of bench_scandir2.py on my laptop using NFS share (server: ext4 filesystem) and slow wifi: - 11,100 entries (1,0000 files, 100 symlinks, 1000 directories) - bench: 1.3x faster (scandir: 22.5 ms, listdir: 28.9 ms) - bench_nostat: 0.2x faster (scandir: 14.3 ms, listdir: 3.2 ms) *** Timings with NFS are not reliable. Sometimes, a directory listing takes more than 30 seconds, but then it takes less than 100 ms. *** Results of bench_scandir2.py on a Windows 7 VM using NTFS: - 11,100 entries (10,000 files, 1,000 directories, 100 symlinks) - bench: 9.9x faster (scandir: 58.3 ms, listdir: 578.5 ms) - bench_nostat: 0.3x faster (scandir: 28.5 ms, listdir: 7.6 ms) Results of bench_scandir2.py on my desktop PC using tmpfs (/tmp): - 110,100 entries (100,000 files, 100 symlinks, 10,000 directories) - bench: 1.3x faster (scandir: 149.2 ms, listdir: 189.2 ms) - bench_nostat: 0.3x faster (scandir: 91.9 ms, listdir: 27.1 ms) Results of bench_scandir2.py on my desktop PC using HDD and ext4: - 110,100 entries (100000 files, 100 symlinks, 10000 directories) - bench: 1.4x faster (scandir: 168.5 ms, listdir: 238.9 ms) - bench_nostat: 0.4x faster (scandir: 107.5 ms, listdir: 41.9 ms) ---------- Added file: http://bugs.python.org/file38121/scandir-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 01:49:49 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 00:49:49 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <54DD2AA1.5070503@gmail.com> Message-ID: <54DD4A29.6090003@gmail.com> Demian Brecht added the comment: I've attached a patch with fixes for both cases and the tests added by Berker. Thanks guys. ---------- Added file: http://bugs.python.org/file38122/issue23442_1.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e548ab4ce71d Lib/http/__init__.py --- a/Lib/http/__init__.py Mon Feb 09 19:49:00 2015 +0000 +++ b/Lib/http/__init__.py Thu Feb 12 16:48:03 2015 -0800 @@ -93,7 +93,7 @@ 'URI is too long') UNSUPPORTED_MEDIA_TYPE = (415, 'Unsupported Media Type', 'Entity body in unsupported format') - REQUEST_RANGE_NOT_SATISFIABLE = (416, + REQUESTED_RANGE_NOT_SATISFIABLE = (416, 'Request Range Not Satisfiable', 'Cannot satisfy request range') EXPECTATION_FAILED = (417, 'Expectation Failed', @@ -107,7 +107,7 @@ TOO_MANY_REQUESTS = (429, 'Too Many Requests', 'The user has sent too many requests in ' 'a given amount of time ("rate limiting")') - REQUEST_HEADER_FIELD_TOO_LARGE = (431, + REQUEST_HEADER_FIELDS_TOO_LARGE = (431, 'Request Header Field Too Large', 'The server is unwilling to process the request because its header ' 'fields are too large') diff -r e548ab4ce71d Lib/test/test_httplib.py --- a/Lib/test/test_httplib.py Mon Feb 09 19:49:00 2015 +0000 +++ b/Lib/test/test_httplib.py Thu Feb 12 16:48:03 2015 -0800 @@ -924,6 +924,66 @@ def test_responses(self): self.assertEqual(client.responses[client.NOT_FOUND], "Not Found") + def test_client_constants(self): + expected = [ + 'CONTINUE', + 'SWITCHING_PROTOCOLS', + 'PROCESSING', + 'OK', + 'CREATED', + 'ACCEPTED', + 'NON_AUTHORITATIVE_INFORMATION', + 'NO_CONTENT', + 'RESET_CONTENT', + 'PARTIAL_CONTENT', + 'MULTI_STATUS', + 'IM_USED', + 'MULTIPLE_CHOICES', + 'MOVED_PERMANENTLY', + 'FOUND', + 'SEE_OTHER', + 'NOT_MODIFIED', + 'USE_PROXY', + 'TEMPORARY_REDIRECT', + 'BAD_REQUEST', + 'UNAUTHORIZED', + 'PAYMENT_REQUIRED', + 'FORBIDDEN', + 'NOT_FOUND', + 'METHOD_NOT_ALLOWED', + 'NOT_ACCEPTABLE', + 'PROXY_AUTHENTICATION_REQUIRED', + 'REQUEST_TIMEOUT', + 'CONFLICT', + 'GONE', + 'LENGTH_REQUIRED', + 'PRECONDITION_FAILED', + 'REQUEST_ENTITY_TOO_LARGE', + 'REQUEST_URI_TOO_LONG', + 'UNSUPPORTED_MEDIA_TYPE', + 'REQUESTED_RANGE_NOT_SATISFIABLE', + 'EXPECTATION_FAILED', + 'UNPROCESSABLE_ENTITY', + 'LOCKED', + 'FAILED_DEPENDENCY', + 'UPGRADE_REQUIRED', + 'PRECONDITION_REQUIRED', + 'TOO_MANY_REQUESTS', + 'REQUEST_HEADER_FIELDS_TOO_LARGE', + 'INTERNAL_SERVER_ERROR', + 'NOT_IMPLEMENTED', + 'BAD_GATEWAY', + 'SERVICE_UNAVAILABLE', + 'GATEWAY_TIMEOUT', + 'HTTP_VERSION_NOT_SUPPORTED', + 'INSUFFICIENT_STORAGE', + 'NOT_EXTENDED', + 'NETWORK_AUTHENTICATION_REQUIRED', + ] + for const in expected: + with self.subTest(constant=const): + self.assertTrue(hasattr(client, const)) + class SourceAddressTest(TestCase): def setUp(self): From report at bugs.python.org Fri Feb 13 02:03:11 2015 From: report at bugs.python.org (Steven Barker) Date: Fri, 13 Feb 2015 01:03:11 +0000 Subject: [issue23447] Relative imports with __all__ attribute In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> Message-ID: <1423789391.2.0.199929826418.issue23447@psf.upfronthosting.co.za> Steven Barker added the comment: This issue is a special case of the problem discussed in issue 992389, that modules within packages are not added to the package dictionary until they are fully loaded, which breaks circular imports in the form "from package import module". The consensus on that issue is that it doesn't need to be fixed completely, given the partial fix from issue 17636. I think the current issue is a corner case that was not covered by the fix, but which probably should be fixed as well, for consistency. The fix so far has made imports that name the module work, even though the module objects are still not placed into the package's namespace yet (this is why Antonio's last example works in the newly released 3.5a1, though not in previous versions). Wildcard imports however still fail. Can the fix be expanded to cover wildcard imports as well? I know, we're heaping up two kinds of usually-bad code (wildcard imports and circular imports) on top of one another, but still, the failure is very unexpected to anyone who's not read the bug reports. I don't know my way around the import system at all yet, so I'm not going to be capable of writing up a patch immediately, but if there's any interest at all, and nobody more knowledgeable gets to it first I might see what I can learn and try to put together something. Here's a more concise example of the issue: package/__init__.py: __all__ = ["module"] package/module.py: from . import module # this works in 3.5a1, thanks to the fix from issue 17636 from . import * # this still fails ---------- nosy: +Steven.Barker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:13:27 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:13:27 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423778942.53.0.328079927645.issue23439@psf.upfronthosting.co.za> Message-ID: <54DD4FB0.5020504@gmail.com> Demian Brecht added the comment: > If we leave it as it is, it would be good to add comment in the source code explaining this decision. I think that __all__ should be left as-is for the time being. Adding some comments around that decision makes sense to me to avoid any future confusion around that. > Also the test case could still be useful to catch future bugs. Agreed. I've added a couple minor comments to the review. Thanks for the work on this! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:15:41 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Feb 2015 01:15:41 +0000 Subject: [issue17986] Alternative async subprocesses (pep 3145) In-Reply-To: <1368652199.21.0.577907802925.issue17986@psf.upfronthosting.co.za> Message-ID: <1423790141.64.0.0476579311476.issue17986@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:22:24 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:22:24 +0000 Subject: [issue22147] PosixPath() constructor should not accept strings with embedded NUL bytes In-Reply-To: <1407267848.45.0.809324931091.issue22147@psf.upfronthosting.co.za> Message-ID: <1423790544.79.0.0229186825177.issue22147@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:22:50 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:22:50 +0000 Subject: [issue12455] urllib2 forces title() on header names, breaking some requests In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za> Message-ID: <1423790570.4.0.844474307051.issue12455@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:23:11 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:23:11 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1423790591.9.0.274789671129.issue17908@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:23:31 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:23:31 +0000 Subject: [issue12849] Cannot override 'connection: close' in urllib2 headers In-Reply-To: <1314559168.55.0.630424901631.issue12849@psf.upfronthosting.co.za> Message-ID: <1423790611.49.0.485934413267.issue12849@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:23:44 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Feb 2015 01:23:44 +0000 Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns [] In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za> Message-ID: <1423790624.32.0.391825460117.issue5053@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:24:51 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:24:51 +0000 Subject: [issue8843] urllib2 Digest Authorization uri must match request URI In-Reply-To: <1275046398.81.0.158910525846.issue8843@psf.upfronthosting.co.za> Message-ID: <1423790691.91.0.468383922329.issue8843@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:25:02 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:25:02 +0000 Subject: [issue14414] xmlrpclib leaves connection in broken state if server returns error without content-length In-Reply-To: <1332778465.08.0.819519448389.issue14414@psf.upfronthosting.co.za> Message-ID: <1423790702.11.0.372302185177.issue14414@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:25:10 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:25:10 +0000 Subject: [issue14301] xmlrpc client transport and threading problem In-Reply-To: <1331735658.17.0.761953257498.issue14301@psf.upfronthosting.co.za> Message-ID: <1423790710.37.0.192094252154.issue14301@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:25:19 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:25:19 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1423790719.73.0.427586459715.issue22197@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:25:29 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:25:29 +0000 Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za> Message-ID: <1423790729.25.0.723555470542.issue14044@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:25:43 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:25:43 +0000 Subject: [issue22946] urllib gives incorrect url after open when using HTTPS In-Reply-To: <1416998247.62.0.575795755864.issue22946@psf.upfronthosting.co.za> Message-ID: <1423790743.04.0.0689912191122.issue22946@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:25:53 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:25:53 +0000 Subject: [issue21557] os.popen & os.system lack shell-related security warnings In-Reply-To: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za> Message-ID: <1423790753.53.0.220657427982.issue21557@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:26:02 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:26:02 +0000 Subject: [issue23043] doctest ignores "from __future__ import print_function" In-Reply-To: <1418419698.58.0.173848086418.issue23043@psf.upfronthosting.co.za> Message-ID: <1423790762.92.0.0674314454616.issue23043@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:26:16 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:26:16 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1423790776.64.0.11279951248.issue23004@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:26:58 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:26:58 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances In-Reply-To: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> Message-ID: <1423790818.06.0.0103096366697.issue23166@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:27:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 01:27:03 +0000 Subject: [issue17986] Alternative async subprocesses (pep 3145) In-Reply-To: <1368652199.21.0.577907802925.issue17986@psf.upfronthosting.co.za> Message-ID: <1423790823.73.0.79133418936.issue17986@psf.upfronthosting.co.za> STINNER Victor added the comment: As Tulip and subprocdev, starting such project outside the Python stdlib may help to get feedback, find and fix bugs faster. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:27:08 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:27:08 +0000 Subject: [issue23448] urllib2 needs to remove scope from IPv6 address when creating Host header In-Reply-To: <1423680023.83.0.120732364895.issue23448@psf.upfronthosting.co.za> Message-ID: <1423790828.64.0.076071619095.issue23448@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:27:52 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 01:27:52 +0000 Subject: [issue9698] When reusing an handler, urllib(2)'s digest authentication fails after multiple regative replies In-Reply-To: <1282892368.57.0.758322534297.issue9698@psf.upfronthosting.co.za> Message-ID: <1423790872.83.0.0423629386608.issue9698@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 02:53:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 01:53:32 +0000 Subject: [issue17986] Alternative async subprocesses (pep 3145) In-Reply-To: <1368652199.21.0.577907802925.issue17986@psf.upfronthosting.co.za> Message-ID: <1423792412.43.0.950307145232.issue17986@psf.upfronthosting.co.za> STINNER Victor added the comment: Subprocess support of asyncio has nice features and is efficient: - async read from stdout and stderr - async write into stdin - async wait for the process exit - async communicate() - timeout on any async operation - support running multiple child processes in parallel - epoll, kqueue, devpoll or IOCP selector - On POSIX, fast child watcher waiting for SIGCHLD signal If possible, I would prefer to not write a second "async subprocess". It's possible to write a blocking API on top of asyncio using loop.run_until_complete(). sync_proc_asyncio.py: incomplete proof-of-concept (no working select() method). ---------- Added file: http://bugs.python.org/file38123/sync_proc_asyncio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 03:47:56 2015 From: report at bugs.python.org (Dwight) Date: Fri, 13 Feb 2015 02:47:56 +0000 Subject: [issue23457] make test failures Message-ID: <1423795676.28.0.704579624562.issue23457@psf.upfronthosting.co.za> New submission from Dwight: Hi, Looking for assistance in figuring out what caused the following test failures and how to fix the problems. Built and run on an IBM pSeries system running AIX 7.1. Appreciate any help I can get. I am not a software developer. I am compiling this because I need this to build things I need to build firefox. Would really appreciate some help! (Mozilla.org and IBM not interested in providing a working browser for my system.) Bye, Dwight ***Failed Test the were run in verbose mode test_locale failed test_io failed test_ssl failed test_faulthandler test_httpservers test_socket failed test_fileio failed test_distutils failed test_asyncio failed test_mmap failed test_resource failed test_posix failed ---------- components: Tests files: PYTHONFailedTest.log messages: 235871 nosy: dcrs6000 at gmail.com priority: normal severity: normal status: open title: make test failures versions: Python 3.4 Added file: http://bugs.python.org/file38124/PYTHONFailedTest.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 04:07:49 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 13 Feb 2015 03:07:49 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1423796869.3.0.652218243401.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: @Mahmoud thanks! I had a quick look and the structural approach we've taken is a bit different. What do you think of the current patch here (issue17911-4.patch) ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 04:51:47 2015 From: report at bugs.python.org (Ben Hoyt) Date: Fri, 13 Feb 2015 03:51:47 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423799507.25.0.0614546605056.issue22524@psf.upfronthosting.co.za> Ben Hoyt added the comment: Hi Victor, I thank you for your efforts here, especially your addition of DirEntry.inode() and your work on the tests. However, I'm a bit frustrated that you just re-implemented the whole thing without discussion: I've been behind scandir and written the first couple of implementations, and I asked if you could review my code, but instead of reviewing it or interacting with my fairly clear desire for the all-C version, you simply turn up and say "I've rewritten it, can you please review?" You did express concern off list about an all-C vs part-Python implementation, but you said "it's still unclear to me which implementation should be added to Python" and "I don't feel able today to take the right decision. We may use python-dev to discuss that". But I didn't see that discussion at all, and I had expressed fairly clearly (both here and off list), with benchmarks, why I thought it should be the all-C version. So it was a bit of a let down for a first-time Python contributor. Even a simple question would have been helpful here: "Ben, I really think this much C code for a first version is bug-prone; what do you think about me re-implementing it and comparing?" TLDR: I'd like to see os.scandir() in Python even if it means the slower implementation, but some discussion would have been nice. :-) So if it's not too late, I'll continue that discussion in my next message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 05:39:25 2015 From: report at bugs.python.org (Ben Hoyt) Date: Fri, 13 Feb 2015 04:39:25 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423802365.04.0.822831901186.issue22524@psf.upfronthosting.co.za> Ben Hoyt added the comment: To continue the actual "which implementation" discussion: as I mentioned last week in http://bugs.python.org/msg235458, I think the benchmarks above show pretty clearly we should use the all-C version. For background: PEP 471 doesn't add any new functionality, and especially with the new pathlib module, it doesn't make directory iteration syntax nicer either: os.scandir() is all about letting the OS give you whatever info it can *for performance*. Most of the Rationale for adding scandir given in PEP 471 is because it can be so so much faster than listdir + stat. My original all-C implementation is definitely more code to review (roughly 800 lines of C vs scandir-6.patch's 400), but it's also more than twice as fast. On my Windows 7 SSD just now, running benchmark.py: Original scandir-2.patch version: os.walk took 0.509s, scandir.walk took 0.020s -- 25.4x as fast New scandir-6.patch version: os.walk took 0.455s, scandir.walk took 0.046s -- 10.0x as fast So the all-C implementation is literally 2.5x as fast on Windows. (After both tests, just for a sanity check, I ran the ctypes version as well, and it said about 8x as fast for both runs.) Then on Linux, not a perfect comparison (different benchmarks) but shows the same kind of trend: Original scandir-2.patch benchmark (http://bugs.python.org/msg228857): os.walk took 0.860s, scandir.walk took 0.268s -- 3.2x as fast New scandir-6.patch benchmark (http://bugs.python.org/msg235865) -- note that "1.3x faster" should actually read "1.3x as fast" here: bench: 1.3x faster (scandir: 164.9 ms, listdir: 216.3 ms) So again, the all-C implementation is 2.5x as fast on Linux too. And on Linux, the incremental improvement provided by scandir-6 over listdir is hardly worth it -- I'd use a new directory listing API for 3.2x as fast, but not for 1.3x as fast. Admittedly a 10x speed gain (!) on Windows is still very much worth going for, so I'm positive about scandir even with a half-Python implementation, but hopefully the above shows fairly clearly why the all-C implementation is important, especially on Linux. Also, if the consensus is in favour of slow but less C code, I think there are further tweaks we can make to the Python part of the code to improve things a bit more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 05:48:16 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 13 Feb 2015 04:48:16 +0000 Subject: [issue23457] make test failures In-Reply-To: <1423795676.28.0.704579624562.issue23457@psf.upfronthosting.co.za> Message-ID: <1423802896.67.0.717764139441.issue23457@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +David.Edelsohn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 06:00:37 2015 From: report at bugs.python.org (Tim Smith) Date: Fri, 13 Feb 2015 05:00:37 +0000 Subject: [issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs In-Reply-To: <1344422598.39.0.464686614779.issue15590@psf.upfronthosting.co.za> Message-ID: <1423803637.78.0.688918412763.issue15590@psf.upfronthosting.co.za> Tim Smith added the comment: On Darwin, it would be nice if LINKFORMODULE used "-undefined dynamic_lookup" instead of explicitly linking to a framework binary. Modules with explicit links to a framework cause segfaults when they are imported from a different, but compatible, framework interpreter -- i.e., building against the system Python 2.7 but importing from a user-installed Python 2.7 causes an immediate crash. I'm a maintainer of Homebrew, a package manager for OS X, and I spend a lot of time tracking down and eliminating errant explicit framework links because they make packaging binaries much harder for us and cause crashes for users. ---------- nosy: +tdsmith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 06:50:55 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 05:50:55 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1423806655.55.0.643557359907.issue23350@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the clarification Martin. After giving this some further thought, I think that the best way to go is to /only/ calculate and add the Content-Length header if each element in the list or tuple is pre-encoded. If it's mixed or only strings, then there are one of three options: 1. Don't try to compute the Content-Length automatically as encoding may change the number of bytes being sent across as the body (which is what the Content-Length represents) 2. Encode the entire body twice, once during the computation of the Content-Length and again on the fly as the body is being written to the socket. This will incur 2x the CPU cost, which can be costly if the body is sufficiently large. 3. Encode the entire body once and store it in memory. Given body sizes can be quite large, I don't think that duplicating the body would be a good approach. The attached patch uses option 1 in order to not add any CPU or memory cost to the operation, but still fix the Content-Length issue as reported. I've also updated the docs to indicate as much. ---------- Added file: http://bugs.python.org/file38125/list_content_length_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 07:03:06 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 13 Feb 2015 06:03:06 +0000 Subject: [issue22430] Build failure if configure flags --prefix or --exec-prefix is set In-Reply-To: <1410960816.78.0.977499217062.issue22430@psf.upfronthosting.co.za> Message-ID: <1423807386.02.0.968655332671.issue22430@psf.upfronthosting.co.za> Ned Deily added the comment: Since there has been no followup to this issue, I'm going to close it. Feel free to reopen if you can document a reproducible problem with a Python source release. ---------- resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 07:37:59 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 13 Feb 2015 06:37:59 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1423809479.87.0.806880056793.issue15914@psf.upfronthosting.co.za> Nick Coghlan added the comment: 3.2 is in security-fix only mode, so nothing's going to change there. For 3.3+, the per-module import lock design means the issue doesn't happen. However, I wonder if there may be some now dead code relating to the global import lock that could be deleted. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 07:38:30 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Feb 2015 06:38:30 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1423809510.14.0.21132795433.issue23350@psf.upfronthosting.co.za> Martin Panter added the comment: The length of an encoded Latin-1 string should equal the length of the unencoded text string, since it is a one-to-one character-to-byte encoding. So encoding should not actually be needed to determine the Latin-1 encoded length. Though I?m not particularly excited by silently Latin-1 encoding text bodies in the first place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 09:31:46 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 08:31:46 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) Message-ID: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch tries to make the private random file descriptor non-inheritable. It should fix the following issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197376 I tried to write an unit test, but since the PEP 446 is not implemented, unexpected file descriptors are inherited. The test should maybe be run in a subprocess to not inherit all file descriptors created by other unit tests. Note: I removed the stat.S_ISDOOR(st.st_mode) check from Lib/test/subprocessdata/fd_status.py, because stat.S_ISDOOR is not defined in Python 2.7. ---------- components: Interpreter Core files: pep446_random.patch keywords: patch messages: 235880 nosy: alex, haypo, pitrou priority: normal severity: normal status: open title: [2.7] random: make the file descriptor non-inheritable (on POSIX) versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38126/pep446_random.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 09:31:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 08:31:52 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1423816312.51.0.0379757719101.issue23458@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file38127/test_fd_status.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 09:31:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 08:31:58 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1423816318.19.0.518723401189.issue23458@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 09:32:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Feb 2015 08:32:15 +0000 Subject: [issue17711] Persistent id in pickle with protocol version 0 In-Reply-To: <1365853309.55.0.468755952624.issue17711@psf.upfronthosting.co.za> Message-ID: <1423816335.67.0.321418259146.issue17711@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch is updated to current sources. Also optimized writing ASCII strings and fixed tests. ---------- versions: +Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file38128/fix_bad_persid_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 09:33:21 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 13 Feb 2015 08:33:21 +0000 Subject: [issue23435] installation with full path as prefix incomplete In-Reply-To: <1423592981.49.0.0894192959587.issue23435@psf.upfronthosting.co.za> Message-ID: <1423816401.31.0.866897468594.issue23435@psf.upfronthosting.co.za> Ned Deily added the comment: So the real problem here is configuring with --prefix=/ and then using make install DESTDIR to install to a temporary location. This is a duplicate of Issue9674; the problem is that --prefix=/ results in build variable the start with '//', like '//lib', and that confuses os.path.join as used in Distutils. You might want to try the patch available there and comment on that issue. ---------- resolution: works for me -> duplicate superseder: -> make install DESTDIR=/home/blah fails when the prefix specified is / _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 10:08:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 09:08:49 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423818529.93.0.529574950994.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: Note: bench_scandir2.py is a micro-benchmark. Ben's benchmark using walk() is more realistic, but I'm interested by micro-benchmark results. scandir-2.patch is faster than scandir-6.patch, much fast on Windows. Result of bench (cached): scandir-6.patch => scandir-2.patch * Windows 7 VM using NTFS: 14.0x faster => 44.6x faster * laptop using NFS share: 1.3x faster => 5.2x faster *** warning: unstable results *** * desktop PC using /tmp: 1.3x faster => 3.8x faster * laptop using SSD and ext4: 1.3x faster => 2.8x faster * desktop PC using HDD and ext4: 1.4x faster => 1.4x faster Benchmark using scandir-2.patch ------------------------------- Benchmark results with the full C implementation, scandir-2.patch. [ C implementation ] Results of bench_scandir2.py on my desktop PC using HDD and ext4: - 110,100 entries (100,000 files, 100 symlinks, 10,000 directories) - bench: 3.5x faster than listdir (scandir: 63.6 ms, listdir: 219.9 ms) - bench_nostat: 0.8x faster than listdir (scandir: 52.8 ms, listdir: 42.4 ms) - bench_nocache: 1.4x faster than listdir (scandir: 3745.2 ms, listdir: 5217.6 ms) - bench_nostat_nocache: 1.4x faster than listdir (scandir: 3834.1 ms, listdir: 5380.7 ms) [ C implementation ] Results of bench_scandir2.py on my desktop PC using /tmp (tmpfs): - 110,100 entries (100,000 files, 100 symlinks, 10,000 directories) - bench: 3.8x faster than listdir (scandir: 46.7 ms, listdir: 176.4 ms) - bench_nostat: 0.7x faster than listdir (scandir: 38.6 ms, listdir: 28.6v) [ C implementation ] Results of bench_scandir2.py on my Windows 7 VM using NTFS: - 110,100 entries (100,000 files, 100 symlinks, 10,000 directories) - bench: 44.6x faster than listdir (scandir: 125.0 ms, listdir: 5574.9 ms) - bench_nostat: 0.8x faster than listdir (scandir: 92.4 ms, listdir: 74.7 ms) [ C implementation ] Results of bench_scandir2.py on my laptop using SSD and ext4: - 110,100 entries (100,000 files, 100 symlinks, 10,000 directories) - bench: 3.6x faster (scandir: 59.4 ms, listdir: 213.3 ms) - bench_nostat: 0.8x faster than listdir (scandir: 50.0 ms, listdir: 38.6) - bench_nocache: 2.8x faster than listdir (scandir: 377.5 ms, listdir: 1073.1) - bench_nostat_nocache: 2.8x faster than listdir (scandir: 370.9 ms, listdir: 1055.0) [ C implementation ] Results of bench_scandir2.py on my laptop using tmpfs: - 110,100 entries (100,000 files, 100 symlinks, 10,000 directories) - bench: 4.0x faster than listdir (scandir: 43.7 ms, listdir: 174.1) - bench_nostat: 0.7x faster than listdir (scandir: 35.2 ms, listdir: 24.5) [ C implementation ] Results of bench_scandir2.py on my laptop using NFS share and slow wifi: - 11,010 entries (10,000 files, 10 symlinks, 1,000 directories) - bench: 5.2x faster than listdir (scandir: 4.2 ms, listdir: 21.7 ms) - bench_nostat: 0.6x faster than listdir (scandir: 3.3 ms, listdir: 1.9 ms) *** Again, results with NFS are not reliable. Sometimes listing a directory conten takes 40 seconds. It's maybe a network issue. *** It looks like d_type can be DT_UNKNOWN on NFS. Benchmark using scandir-6.patch ------------------------------- I rerun benchmark with scandir-6.patch with more files to compare the two benchmarks. [ C implementation ] Results of bench_scandir2.py on my Windows 7 VM using NTFS: - 110,100 entries (100,000 files, 100 symlinks, 10,000 directories) - bench: 14.0x faster than listdir (scandir: 399.0 ms, listdir: 5578.7 ms) - bench_nostat: 0.3x faster than listdir (scandir: 279.2 ms, listdir: 76.1 ms) [ C implementation ] Results of bench_scandir2.py on my laptop using NFS share and slow wifi: - 11,010 entries (10,000 files, 10 symlinks, 1,000 directories) - bench: 1.5x faster than listdir (scandir: 14.8 ms, listdir: 21.4 ms) - bench_nostat: 0.2x faster than listdir (scandir: 10.6 ms, listdir: 2.2 ms) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 10:27:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 09:27:45 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1423819665.66.0.215629607521.issue23458@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 2.7 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 10:28:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 09:28:29 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1423802365.04.0.822831901186.issue22524@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Hi Ben, 2015-02-13 4:51 GMT+01:00 Ben Hoyt : > Hi Victor, I thank you for your efforts here, especially your addition of DirEntry.inode() and your work on the tests. The addition of inode() should still be discussed on python-dev. The remaining question is if the inode number (st_ino) is useful even if st_dev is missing. I didn't added the inode() method yet to the PEP because of that. > However, I'm a bit frustrated that you just re-implemented the whole thing without discussion: (...) > So it was a bit of a let down for a first-time Python contributor. Even a simple question would have been helpful here: "Ben, I really think this much C code for a first version is bug-prone; what do you think about me re-implementing it and comparing?" I'm really sorry, I didn't want to frustrate you :-( Sorry for not being available, I also expected someone else to review your code, but it didn't happen. And I *want* your opinon on design choices. Sorry if I wasn't explicit about that in my last emails. Sorry, I was very busy last months on other projects (like asyncio). I want scandir() to be included in Python 3.5! The3.5 alpha 1 release was a reminder for me. I didn't reimplement everything. Almost all code comes from your work. I just adapted it to Python 3.5. > I've been behind scandir and written the first couple of implementations, and I asked if you could review my code, but instead of reviewing it or interacting with my fairly clear desire for the all-C version, you simply turn up and say "I've rewritten it, can you please review?" I'm not happy of the benchmark results of the C+Python implementation (scandir-6.patch is supposed to be the fasted implementation of C+Python). I tried to produce as much benchmark results as possible to be able to take a decision. I used: * hardware: SSD, HDD and tmpfs (RAM) * file system: ext4, tmpfs, NFS/ext4 * operating systems: Linux (Fedora 21), Windows 7 I will try to summarize benchmark results to write an email to python-dev, to make a choice between the full C implementation vs C+Python implementation. (ctypes is not an option, it's not reliable, portability matters.) > To continue the actual "which implementation" discussion: as I mentioned last week in http://bugs.python.org/msg235458, I think the benchmarks above show pretty clearly we should use the all-C version. It's quite clear that the C implementation is always faster than C+Python. My point is that we have to make a choice, C+Python is a nice compromise because it uses less C code, and C code is more expensive to *maintain*. > For background: PEP 471 doesn't add any new functionality, and especially with the new pathlib module, it doesn't make directory iteration syntax nicer either: os.scandir() is all about letting the OS give you whatever info it can *for performance*. Most of the Rationale for adding scandir given in PEP 471 is because it can be so so much faster than listdir + stat. Good point :-) In many setup (hardware, operating system, file system), I see a low speedup (less than 2x faster). The whole purpose of the PEP 471 becomes unclear if the speedup is not at least 2x. Quicky summary of benchmarks: * using C+Python (scandir-6.patch), the benchmark ("bench") is only faster than 2x on Windows, in the other cases it's between 1.3x and 1.4x faster * using C (scandir-2.patch), the benchmark ("bench") is at least 3.5x faster, it's between 3.5x and 44.6x faster, the most interesting speedup is on Windows (44.6x faster!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 10:53:09 2015 From: report at bugs.python.org (Alexei Romanov) Date: Fri, 13 Feb 2015 09:53:09 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423821189.15.0.485119429231.issue22524@psf.upfronthosting.co.za> Changes by Alexei Romanov : ---------- nosy: +alexei.romanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 11:13:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Feb 2015 10:13:33 +0000 Subject: [issue21840] Fix os.path in unicodeless build In-Reply-To: <1403594110.07.0.0949253630199.issue21840@psf.upfronthosting.co.za> Message-ID: <20150213101327.43803.51057@psf.io> Roundup Robot added the comment: New changeset 8e2388b1e875 by Serhiy Storchaka in branch '2.7': Issue #21840: Fixed expanding unicode variables of form $var in https://hg.python.org/cpython/rev/8e2388b1e875 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 11:14:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Feb 2015 10:14:19 +0000 Subject: [issue21840] Fix os.path in unicodeless build In-Reply-To: <1403594110.07.0.0949253630199.issue21840@psf.upfronthosting.co.za> Message-ID: <1423822459.87.0.11233870831.issue21840@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka dependencies: -Fix unicodeless build of Python resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 11:47:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Feb 2015 10:47:52 +0000 Subject: [issue21840] Fix os.path in unicodeless build In-Reply-To: <1403594110.07.0.0949253630199.issue21840@psf.upfronthosting.co.za> Message-ID: <20150213104746.11114.37281@psf.io> Roundup Robot added the comment: New changeset 544c5d4f4084 by Serhiy Storchaka in branch '2.7': Issue #21840: Fixed a typo. https://hg.python.org/cpython/rev/544c5d4f4084 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 12:03:36 2015 From: report at bugs.python.org (Ivailo Monev) Date: Fri, 13 Feb 2015 11:03:36 +0000 Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix specified is / In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za> Message-ID: <1423825416.38.0.788452257987.issue9674@psf.upfronthosting.co.za> Ivailo Monev added the comment: Can you please apply fix-root-prefix.patch? Or the updated version fof issue9674.patch that I've attached? sysconfig tests will still fail and it will return bogus paths with double slash (e.g. //lib/python2.7) but at least Python will be installable with prefix=/ and will not mess up with files on root (/) when DESTDIR is set. That may not be complete solution but it's a step forward to that. ---------- nosy: +Ivailo.Monev Added file: http://bugs.python.org/file38129/issue9674-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 12:37:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 11:37:34 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423827454.88.0.179378219159.issue22524@psf.upfronthosting.co.za> STINNER Victor added the comment: > Result of bench (cached): scandir-6.patch => scandir-2.patch > (...) > laptop using SSD and ext4: 1.3x faster => 2.8x faster > desktop PC using HDD and ext4: 1.4x faster => 1.4x faster Oops, I copied the wrong numbers. scandir-2.patch is faster than that! * laptop using SSD and ext4: 1.3x faster => 3.6x faster * desktop PC using HDD and ext4: 1.4x faster => 3.5x faster ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 13:32:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 12:32:39 +0000 Subject: [issue23459] Linux: expose the new execveat() syscall Message-ID: <1423830759.75.0.255479243543.issue23459@psf.upfronthosting.co.za> New submission from STINNER Victor: execveat() was added to Linux in kernel 3.19: http://man7.org/linux/man-pages/man2/execveat.2.html It may be interesting to expose it in Python. "The primary aim of adding an execveat syscall is to allow an implementation of fexecve(3) that does not rely on the /proc filesystem. The current glibc version of fexecve(3) is implemented via /proc, which causes problems in sandboxed or otherwise restricted environments." http://lwn.net/Articles/600344/ ---------- components: Extension Modules messages: 235889 nosy: haypo priority: normal severity: normal status: open title: Linux: expose the new execveat() syscall versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 14:21:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Feb 2015 13:21:00 +0000 Subject: [issue21849] Fix multiprocessing for non-ascii data In-Reply-To: <1403595158.76.0.418417977176.issue21849@psf.upfronthosting.co.za> Message-ID: <20150213132046.29544.98152@psf.io> Roundup Robot added the comment: New changeset a4a3a8b3f37f by Serhiy Storchaka in branch '2.7': Issue #21849: Fixed xmlrpclib serialization of non-ASCII unicode strings in https://hg.python.org/cpython/rev/a4a3a8b3f37f New changeset 908533d5a427 by Serhiy Storchaka in branch '3.4': Issue #21849: Ported from 2.7 tests for non-ASCII data. https://hg.python.org/cpython/rev/908533d5a427 New changeset 1784c1901af6 by Serhiy Storchaka in branch 'default': Issue #21849: Ported from 2.7 tests for non-ASCII data. https://hg.python.org/cpython/rev/1784c1901af6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 15:28:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Feb 2015 14:28:24 +0000 Subject: [issue23147] Possible error in _header_value_parser.py In-Reply-To: <1420194679.08.0.467668822135.issue23147@psf.upfronthosting.co.za> Message-ID: <1423837704.35.0.130155592978.issue23147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 15:28:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Feb 2015 14:28:55 +0000 Subject: [issue23148] Missing the charset parameter in as_encoded_word() In-Reply-To: <1420195099.17.0.393236049779.issue23148@psf.upfronthosting.co.za> Message-ID: <1423837735.5.0.515387214791.issue23148@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 16:46:57 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 15:46:57 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1423809510.14.0.21132795433.issue23350@psf.upfronthosting.co.za> Message-ID: <54DE1C6C.80704@gmail.com> Demian Brecht added the comment: Thanks for the review Martin, I've addressed your comments. > The length of an encoded Latin-1 string should equal the length of the unencoded text string, since it is a one-to-one character-to-byte encoding. Once in a while, I want to stop what I'm doing, put my head in my hands and think to myself "how did that escape me"?! Of course you're right and thanks for the catch. I've reverted the handling to how it was being done in the previous patch. > Though I?m not particularly excited by silently Latin-1 encoding text bodies in the first place. Truth be told, I'm more fond of only accepting pre-encoded byte strings as input. However, that backwards incompatible change would likely break many things. Request bodies can currently be strings, byte strings, iterables or file objects. In the cases of string and file objects, encoding is already supported. The change I made makes handling iterables consistent with the other accepted data types. I'm not sure why, but the auto-encoding of the raw string input object was being done higher up in the general use case callstack (Lib/http/client.py:1064). I've moved this handling to send() for consistency with the auto-encoding of other input types. This also ensures consistent behavior between calling request() with a string body and calling send() directly. ---------- Added file: http://bugs.python.org/file38130/list_content_length_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e548ab4ce71d Doc/library/http.client.rst --- a/Doc/library/http.client.rst Mon Feb 09 19:49:00 2015 +0000 +++ b/Doc/library/http.client.rst Fri Feb 13 07:45:43 2015 -0800 @@ -212,8 +212,10 @@ contents of the file is sent; this file object should support ``fileno()`` and ``read()`` methods. The header Content-Length is automatically set to the length of the file as reported by stat. The *body* argument may also be - an iterable and Content-Length header should be explicitly provided when the - body is an iterable. + an iterable. If the iterable is a tuple or list, the Content-Length will + automatically be set if not already supplied in the request headers. + In all other iterable cases, the Content-Length header should be explicitly + provided. The *headers* argument should be a mapping of extra HTTP headers to send with the request. @@ -221,6 +223,10 @@ .. versionadded:: 3.2 *body* can now be an iterable. + .. versionadded:: 3.5 + The Content-Length header will be set when *body* is a list or tuple. + + .. method:: HTTPConnection.getresponse() Should be called after a request is sent to get the response from the server. diff -r e548ab4ce71d Lib/http/client.py --- a/Lib/http/client.py Mon Feb 09 19:49:00 2015 +0000 +++ b/Lib/http/client.py Fri Feb 13 07:45:43 2015 -0800 @@ -836,11 +836,19 @@ datablock = datablock.encode("iso-8859-1") self.sock.sendall(datablock) return + + if isinstance(data, str): + # RFC 2616 Section 3.7.1 says that text default has a + # default charset of iso-8859-1. + data = data.encode('iso-8859-1') + try: self.sock.sendall(data) except TypeError: if isinstance(data, collections.Iterable): for d in data: + if hasattr(d, 'encode'): + d = d.encode('iso-8859-1') self.sock.sendall(d) else: raise TypeError("data should be a bytes-like object " @@ -1031,20 +1039,25 @@ def _set_content_length(self, body): # Set the content-length based on the body. - thelen = None - try: - thelen = str(len(body)) - except TypeError as te: - # If this is a file-like object, try to - # fstat its file descriptor + size = None + if isinstance(body, (list, tuple)): + # the body will either be already encoded or will be latin-1 + # encoded when being sent. as latin-1 and ascii strings are of + # equal size, there isn't a need to make a distinction here. + size = sum(len(line) for line in body) + else: try: - thelen = str(os.fstat(body.fileno()).st_size) - except (AttributeError, OSError): - # Don't send a length if this failed - if self.debuglevel > 0: print("Cannot stat!!") + size = len(body) + except TypeError: + try: + size = os.fstat(body.fileno()).st_size + except (AttributeError, OSError): + if self.debuglevel > 0: + print("Cannot stat!!") + size = None - if thelen is not None: - self.putheader('Content-Length', thelen) + if size is not None: + self.putheader('Content-Length', size) def _send_request(self, method, url, body, headers): # Honor explicitly requested Host: and Accept-Encoding: headers. @@ -1061,10 +1074,6 @@ self._set_content_length(body) for hdr, value in headers.items(): self.putheader(hdr, value) - if isinstance(body, str): - # RFC 2616 Section 3.7.1 says that text default has a - # default charset of iso-8859-1. - body = body.encode('iso-8859-1') self.endheaders(body) def getresponse(self): diff -r e548ab4ce71d Lib/test/test_httplib.py --- a/Lib/test/test_httplib.py Mon Feb 09 19:49:00 2015 +0000 +++ b/Lib/test/test_httplib.py Fri Feb 13 07:45:43 2015 -0800 @@ -1161,7 +1161,6 @@ def setUp(self): self.conn = client.HTTPConnection('example.com') self.conn.sock = self.sock = FakeSocket("") - self.conn.sock = self.sock def get_headers_and_fp(self): f = io.BytesIO(self.sock.data) @@ -1226,6 +1225,25 @@ self.assertEqual("5", message.get("content-length")) self.assertEqual(b'body\xc1', f.read()) + def test_list_body(self): + cases = ( + ([b'foo', b'bar'], b'foobar'), + ((b'foo', b'bar'), b'foobar'), + ((b'foo', 'bar'), b'foobar'), + ([b'foo', 'bar'], b'foobar'), + ) + for body, expected in cases: + with self.subTest(body): + self.conn = client.HTTPConnection('example.com') + self.conn.sock = self.sock = FakeSocket('') + + self.conn.request('PUT', '/url', body) + msg, f = self.get_headers_and_fp() + self.assertNotIn('Content-Type', msg) + self.assertIsNone(msg.get_charset()) + self.assertEqual(len(expected), int(msg.get('content-length'))) + self.assertEqual(expected, f.read()) + class HTTPResponseTest(TestCase): From report at bugs.python.org Fri Feb 13 16:51:55 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 13 Feb 2015 15:51:55 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1423842715.23.0.151153276303.issue23458@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure what the point is - there are many child descriptors which may inherited, why care about this one? The right way to avoid this on 2.7 is to call subprocess.Popen(..., close_fds=True). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 16:59:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Feb 2015 15:59:57 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1423843197.71.0.84082821333.issue23458@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'm not sure what the point is - there are many child descriptors which may inherited, why care about this one? The bug report comes from FreeBSD, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197376 They use os.system(), at least in the bug report. The random file descriptor is a little suprising because it's not obvious than os.urandom() opens a file, nor that the file remains open. It's also a change in a minor Python version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 17:05:05 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 16:05:05 +0000 Subject: [issue18295] Possible integer overflow in PyCode_New() In-Reply-To: <1372108745.44.0.114375127897.issue18295@psf.upfronthosting.co.za> Message-ID: <1423843505.39.0.753955236631.issue18295@psf.upfronthosting.co.za> Steve Dower added the comment: Other than my one query on the review, code_ssize_t_2.patch.patch looks good to me. ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 17:07:11 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 16:07:11 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1423843631.08.0.0706952049566.issue23450@psf.upfronthosting.co.za> Steve Dower added the comment: int_overflows.patch looks good to me. I really appreciate that these patches have been done properly too - I've seen far too much code where people just throw in casts to silence the warnings. This is why I like working on Python :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 17:07:52 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 16:07:52 +0000 Subject: [issue9566] Compilation warnings under x64 Windows In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za> Message-ID: <1423843672.11.0.216530795152.issue9566@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 17:10:52 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 16:10:52 +0000 Subject: [issue21107] Add pgen.vcxproj to allow regenerating grammar files on Windows In-Reply-To: <1396238659.26.0.487973987032.issue21107@psf.upfronthosting.co.za> Message-ID: <1423843852.85.0.321070817951.issue21107@psf.upfronthosting.co.za> Steve Dower added the comment: I don't even know what pgen is or why I'd want to build it... If running it updates a file that would trigger a rebuild, then I'd really like it to copy what _freeze_importlib currently does as far as writing to a temporary file and conditionally overwriting the actual one. That is the most reliable way to avoid unnecessary rebuilds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 17:12:31 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 16:12:31 +0000 Subject: [issue21568] Win32 pip doesn't use relative path to found site-packages. In-Reply-To: <1400898605.95.0.696955822975.issue21568@psf.upfronthosting.co.za> Message-ID: <1423843951.82.0.575561232406.issue21568@psf.upfronthosting.co.za> Steve Dower added the comment: Already reported at https://github.com/pypa/pip/issues/1889 ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 17:14:05 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 16:14:05 +0000 Subject: [issue20523] global .pdbrc on windows 7 not reachable out of the box In-Reply-To: <1391637453.5.0.977818995818.issue20523@psf.upfronthosting.co.za> Message-ID: <1423844045.94.0.591326746022.issue20523@psf.upfronthosting.co.za> Steve Dower added the comment: expanduser() sounds like the better choice here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 17:18:01 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 13 Feb 2015 16:18:01 +0000 Subject: [issue21107] Add pgen.vcxproj to allow regenerating grammar files on Windows In-Reply-To: <1396238659.26.0.487973987032.issue21107@psf.upfronthosting.co.za> Message-ID: <1423844281.71.0.41760814422.issue21107@psf.upfronthosting.co.za> Zachary Ware added the comment: > I don't even know what pgen is or why I'd want to build it... pgen is the parser generator, taking Grammar/Grammar as input and generating Include/graminit.h and Python/graminit.c. Only useful when you're changing Python's grammar, but without the ability to build pgen, it's hard for Windows developers to play with the grammar at all. > If running it updates a file that would trigger a rebuild, then I'd > really like it to copy what _freeze_importlib currently does as far as > writing to a temporary file and conditionally overwriting the actual > one. That is the most reliable way to avoid unnecessary rebuilds. _freeze_importlib was what I used for a guide initially, and will be again when I get around to redoing the patch :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 17:38:43 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 13 Feb 2015 16:38:43 +0000 Subject: [issue7200] multiprocessing deadlock on Mac OS X when queue collected before process terminates In-Reply-To: <1256425837.07.0.628633816678.issue7200@psf.upfronthosting.co.za> Message-ID: <1423845523.98.0.96428460481.issue7200@psf.upfronthosting.co.za> Davin Potts added the comment: This issue was marked as "not a bug" by OP a while back but for whatever reason it did not also get marked as "closed". Going ahead with closing it now. ---------- nosy: +davin stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 18:13:07 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 17:13:07 +0000 Subject: [issue23452] Build errors using VS Express 2013 in win32 mode In-Reply-To: <1423723559.86.0.395515662536.issue23452@psf.upfronthosting.co.za> Message-ID: <1423847587.41.0.33373377652.issue23452@psf.upfronthosting.co.za> Steve Dower added the comment: I can't reproduce this easily. Could you delete the externals/tcltk folder and the Debug_VC12 folders under tk.../win, tix.../win and tcl-core.../win, rebuild and capture the output from the VS Output window? Apparently something in one of these external projects is not building properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 18:15:21 2015 From: report at bugs.python.org (Ian Kelly) Date: Fri, 13 Feb 2015 17:15:21 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules Message-ID: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> New submission from Ian Kelly: >>> '{:g}'.format(D('0.000001')) '0.000001' Formatted with '{:e}', the exponent would be -6, so per the formatting rules described under the 'g' specifier at https://docs.python.org/3/library/string.html#format-specification-mini-language the above should be formatted using exponential notation. ---------- components: Library (Lib) messages: 235904 nosy: ikelly priority: normal severity: normal status: open title: Decimals do not obey ':g' exponential notation formatting rules type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 18:16:22 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 13 Feb 2015 17:16:22 +0000 Subject: [issue23447] Import fails when doing a circular import involving an `import *` In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> Message-ID: <1423847782.32.0.418462104555.issue23447@psf.upfronthosting.co.za> Brett Cannon added the comment: If you want to take a stab at it, Steven, go for it and I will review the patch, but as you pointed out this is such an edge case that I'm personally not going to worry about fixing it and still don't consider it a bug. ---------- title: Relative imports with __all__ attribute -> Import fails when doing a circular import involving an `import *` _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 18:17:30 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 13 Feb 2015 17:17:30 +0000 Subject: [issue15914] multiprocessing.SyncManager connection hang In-Reply-To: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za> Message-ID: <1423847850.35.0.470884983783.issue15914@psf.upfronthosting.co.za> Brett Cannon added the comment: Dead code deletion should be a separate issue, so I'm going to close this as fixed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 18:17:52 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 17:17:52 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes In-Reply-To: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> Message-ID: <1423847872.44.0.092544752448.issue23410@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 18:44:50 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 17:44:50 +0000 Subject: [issue23440] Extend http.server.SimpleHTTPRequestHandler testing In-Reply-To: <1423640571.78.0.653754704207.issue23440@psf.upfronthosting.co.za> Message-ID: <1423849490.53.0.459521967108.issue23440@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 18:48:48 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 17:48:48 +0000 Subject: [issue23418] Keep http.server.__all__ up to date In-Reply-To: <1423465423.93.0.840073300907.issue23418@psf.upfronthosting.co.za> Message-ID: <1423849728.21.0.510651755253.issue23418@psf.upfronthosting.co.za> Demian Brecht added the comment: > LGTM. +1 ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 18:54:39 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 13 Feb 2015 17:54:39 +0000 Subject: [issue17229] unable to discover preferred HTTPConnection class In-Reply-To: <1361222471.81.0.536204108906.issue17229@psf.upfronthosting.co.za> Message-ID: <1423850079.45.0.600447203793.issue17229@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: -demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 19:30:41 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 13 Feb 2015 18:30:41 +0000 Subject: [issue23425] Windows getlocale unix-like with french, german, portuguese, spanish In-Reply-To: <1423515310.7.0.637877209066.issue23425@psf.upfronthosting.co.za> Message-ID: <1423852241.34.0.754239640415.issue23425@psf.upfronthosting.co.za> R. David Murray added the comment: This is either related to or effectively a duplicate of issue 10466, which contains a fair amount of discussion of the underlying problems. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 19:39:28 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 13 Feb 2015 18:39:28 +0000 Subject: [issue23434] RFC6266 support (Content-Disposition for HTTP) In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za> Message-ID: <1423852768.42.0.341511925546.issue23434@psf.upfronthosting.co.za> R. David Murray added the comment: Since that library is not part of the stdlib, this is not an appropriate patch for CPython. Note that this issue is also relevant to the email library, which intends to support RFC2616 header parsing/generation, and therefore should also be enhanced to support RFC 6266. ---------- components: +email nosy: +barry, r.david.murray versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 19:48:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Feb 2015 18:48:32 +0000 Subject: [issue23418] Keep http.server.__all__ up to date In-Reply-To: <1423465423.93.0.840073300907.issue23418@psf.upfronthosting.co.za> Message-ID: <20150213184816.37933.42421@psf.io> Roundup Robot added the comment: New changeset d2dbec7d74d0 by Berker Peksag in branch '3.4': Issue #23418: Add missing entries to http.server.__all__. https://hg.python.org/cpython/rev/d2dbec7d74d0 New changeset 03e3e78014ea by Berker Peksag in branch 'default': Issue #23418: Add missing entries to http.server.__all__. https://hg.python.org/cpython/rev/03e3e78014ea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 19:53:18 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Feb 2015 18:53:18 +0000 Subject: [issue23418] Keep http.server.__all__ up to date In-Reply-To: <1423465423.93.0.840073300907.issue23418@psf.upfronthosting.co.za> Message-ID: <1423853598.25.0.283638180053.issue23418@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thanks Martin (also thanks to Demian for the review). ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 20:01:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Feb 2015 19:01:58 +0000 Subject: [issue21717] Exclusive mode for ZipFile and TarFile In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za> Message-ID: <20150213190148.11138.88524@psf.io> Roundup Robot added the comment: New changeset ed9e9e6b3c1e by Berker Peksag in branch 'default': Issue #21717: tarfile.open() now supports 'x' (exclusive creation) mode. https://hg.python.org/cpython/rev/ed9e9e6b3c1e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 20:04:36 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Feb 2015 19:04:36 +0000 Subject: [issue21717] Exclusive mode for ZipFile and TarFile In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za> Message-ID: <1423854276.75.0.707588189411.issue21717@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review, Serhiy. I'll take a look at the zipfile patch tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 20:23:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Feb 2015 19:23:25 +0000 Subject: [issue14652] Better error messages for wsgiref validator failures In-Reply-To: <1335203283.28.0.579235394721.issue14652@psf.upfronthosting.co.za> Message-ID: <1423855405.8.0.412046948782.issue14652@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is an updated patch. For InputWrapper.read(), see issue 18610. ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file38131/issue14652.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 20:26:11 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Feb 2015 19:26:11 +0000 Subject: [issue17527] PATCH as valid request method in wsgiref.validator In-Reply-To: <1364034217.66.0.106174829986.issue17527@psf.upfronthosting.co.za> Message-ID: <1423855571.85.0.43158143181.issue17527@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. ---------- nosy: +berker.peksag stage: -> commit review versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 20:48:27 2015 From: report at bugs.python.org (albertjan) Date: Fri, 13 Feb 2015 19:48:27 +0000 Subject: [issue23425] Windows getlocale unix-like with french, german, portuguese, spanish In-Reply-To: <1423515310.7.0.637877209066.issue23425@psf.upfronthosting.co.za> Message-ID: <1423856907.39.0.333138163785.issue23425@psf.upfronthosting.co.za> albertjan added the comment: I agree that the two issues are related, but I don't see how they could be duplicates. But maybe that's because I do not know the underlying code. issue 10466 is mostly about getdefaultlocale() and whether it's desirable or not that its return value is always uniq-esque, including on windows. The failed call to locale.py*) as a script would demonstrate that the getdefaultlocale() return value ought to be platform-specific and ready for consumption by setlocale(). That's how I read that issue. I personally find it useful to have getdefaultlocale() --a nice, harmonized locale string. With getlocale in Windows, however, the return value is sometimes unix-like, sometimes windows-specific. Until a couple of days ago I thought getlocale was entirely platform-specific. Why should locale.setlocale(locale.LC_ALL, ".".join(locale.getlocale())) succeed on my Dutch windows system, but fail on my neighbour's German windows system? In my humble opinion: -setlocale should return nothing. It's a setter -getlocale should return a platform-specific locale specification, probably what is currently returned by setlocale. The output should be ready for consumption by setlocale. -getdefaultlocale should ALWAYS return a harmonized/unix-like locale specification. In Unix, but not in Windows, it could be used as an argument for setlocale. My two cents. Best wishes, Albert-Jan *) which also fails on Python 2.7 and 3.4 on my Dutch Windows 7 64, btw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 20:59:08 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Feb 2015 19:59:08 +0000 Subject: [issue17349] wsgiref.simple_server.demo_app is not PEP-3333 compatible In-Reply-To: <1362400053.87.0.0342035983925.issue17349@psf.upfronthosting.co.za> Message-ID: <1423857548.21.0.289086259391.issue17349@psf.upfronthosting.co.za> Berker Peksag added the comment: I'm not sure this needs to be fixed in 2.7. I would only use demo_app to test WSGI servers. Otherwise, you need to create your own application. However, the code is correct in Python 3: https://hg.python.org/cpython/file/default/Lib/wsgiref/simple_server.py#l146 (Note: PEP 3333 is for Python 3. In Python 2, the correct quote is "When called by the server, the application object must return an iterable yielding zero or more strings." See PEP 333.) ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 21:04:00 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 13 Feb 2015 20:04:00 +0000 Subject: [issue23425] Windows getlocale unix-like with french, german, portuguese, spanish In-Reply-To: <1423515310.7.0.637877209066.issue23425@psf.upfronthosting.co.za> Message-ID: <1423857840.02.0.513049214552.issue23425@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, when I said "effectively a duplicate" I didn't mean *actually* a duplicate, I meant that fixing one will either result in or require fixing the other (same core cause: the disconnect between the Windows names and the unix names and the need for a *consistent* mapping between them). But, I didn't fully reread that issue or the docs, so maybe I'm wrong about that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 22:12:00 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 13 Feb 2015 21:12:00 +0000 Subject: [issue23452] Build errors using VS Express 2013 in win32 mode In-Reply-To: <1423723559.86.0.395515662536.issue23452@psf.upfronthosting.co.za> Message-ID: <1423861920.64.0.753898442837.issue23452@psf.upfronthosting.co.za> Mark Lawrence added the comment: I don't have externals/tcltk, only externals/tcltk64. There is a Debug_VC12 folder under tix.../win. There is no Debug_VC12 folder under tk.../win, tcl-core.../win or for that matter tcl.../win, only Debug_AMD64_VC12. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 22:42:39 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 13 Feb 2015 21:42:39 +0000 Subject: [issue23424] Unicode character ends interactive session In-Reply-To: <1423514239.73.0.0631467799432.issue23424@psf.upfronthosting.co.za> Message-ID: <1423863759.45.0.79646685327.issue23424@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> windows console doesn't print or input Unicode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 22:58:25 2015 From: report at bugs.python.org (Akira Li) Date: Fri, 13 Feb 2015 21:58:25 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423864705.57.0.0257800406341.issue22524@psf.upfronthosting.co.za> Akira Li added the comment: As I've mentioned in http://bugs.python.org/issue22524#msg231703 os.walk size 7925376343, scandir.walk size 5534939617 -- NOT EQUAL! os.walk and scandir.walk do a different work here. I don't see that it is acknowledged so I assume the benchmark is not fixed. If the fixed (same work) benchmark is used then there is no performance difference on Linux. See the attached file http://bugs.python.org/file37292/get_tree_size_listdir.diff Note: the performance improvements on Windows along should be enough to accept os.scandir() even if Linux version won't be improved (if the behavior is documented). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 13 23:58:43 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Feb 2015 22:58:43 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1423868323.47.0.725908379471.issue17852@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:02:54 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 23:02:54 +0000 Subject: [issue23452] Build errors using VS Express 2013 in win32 mode In-Reply-To: <1423723559.86.0.395515662536.issue23452@psf.upfronthosting.co.za> Message-ID: <1423868574.07.0.685447430482.issue23452@psf.upfronthosting.co.za> Steve Dower added the comment: Hmm, so maybe it only happens after you build the 64-bit version first. But apparently it's more complex than that, since that doesn't repro either. When I get some more time I'll run though and double check all the rebuild conditions, but it has worked fine for me every time I've done it across 8-10 machines and 3-4 VS versions. I think you've ended up in a very unlikely situation that is probably going to be fixed by "hg purge --all && PCBuild\build -e -d && PCBuild\build -e -d -p x64". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:10:48 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 13 Feb 2015 23:10:48 +0000 Subject: [issue23461] Building on windows modifies importlib.h Message-ID: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> New submission from Paul Moore: When building Python (cpython repository, tip revision on the default branch) using Visual Studio 2015 (version downloaded 12/02/2015) I get a message in the build: C:\Work\Projects\cpython\PCbuild\_freeze_importlib.vcxproj(98,5): error : importlib.h has been updated. You will need to rebuild pythoncore to see the changes. This is using the command "PCBuild\build.bat -p x64". When I check hg status after the build, Python\importlib.h shows as modified. (I have 2 changed files in the repo, one a documentation file and the other launcher.c. Neither change should affect importlib). ---------- messages: 235922 nosy: pmoore priority: normal severity: normal status: open title: Building on windows modifies importlib.h versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:17:43 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 13 Feb 2015 23:17:43 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423869463.79.0.225599250036.issue23461@psf.upfronthosting.co.za> Eric Snow added the comment: This implies to me that someone didn't include importlib.h in their commit when they changed something that required it to be rebuilt. However, if it's a Windows-only thing then perhaps there is something else afoot. Steve? ---------- nosy: +brett.cannon, eric.snow, steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:19:31 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 13 Feb 2015 23:19:31 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423869571.93.0.486101557465.issue23461@psf.upfronthosting.co.za> Zachary Ware added the comment: What does the diff to importlib.h look like? Does it look like a real change to importlib or is it something innocuous like a change in whitespace or the path separator in the heading? ---------- components: +Build, Windows nosy: +tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:38:54 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 13 Feb 2015 23:38:54 +0000 Subject: [issue19829] _pyio.BufferedReader and _pyio.TextIOWrapper destructor don't emit ResourceWarning if the file is not closed In-Reply-To: <1385721421.95.0.384748799117.issue19829@psf.upfronthosting.co.za> Message-ID: <1423870734.33.0.688036566078.issue19829@psf.upfronthosting.co.za> Martin Panter added the comment: It looks like the C _io close() implementations delegate to the wrapped object?s undocumented _dealloc_warn() method to emit the warning if ?self->finalizing? is set. For wrapped objects like BytesIO that do not have it, I guess the error due to the missing method is ignored. There is no Python implementation of FileIO yet (see Issue 21859), so the Python file wrapper classes still use the C FileIO implementation, which emits a resource warning. However for the wrapper classes, _pyio.IOBase.__del__() explicitly invokes the wrapper?s close() method, which will invoke FileIO.close() method, which bypasses the warning. Similarly, any object inheriting from the C implmentation?s _io.IOBase will also have close() explicitly invoked when being finalized, bypassing any warnings of the underlying wrapped object. The SocketIO instances returned by socket.makefile() are an example of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:39:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Feb 2015 23:39:01 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <20150213233850.37927.17336@psf.io> Roundup Robot added the comment: New changeset 99302634d756 by Berker Peksag in branch 'default': Issue #14910: Add allow_abbrev parameter to argparse.ArgumentParser. https://hg.python.org/cpython/rev/99302634d756 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:39:11 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 23:39:11 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423870751.16.0.755565704566.issue23461@psf.upfronthosting.co.za> Steve Dower added the comment: Windows is probably the only platform that detects when _freeze_importlib makes a change and aborts the build :) I'd be interested to see what the diff is though. My guess is some of the recent marshal changes may have affected the output. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:41:44 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Feb 2015 23:41:44 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1423870904.35.0.908463250113.issue14910@psf.upfronthosting.co.za> Berker Peksag added the comment: Committed. Thank you all for patches and reviews :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:45:03 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 13 Feb 2015 23:45:03 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423871103.35.0.0139144165027.issue23461@psf.upfronthosting.co.za> Paul Moore added the comment: Ah. It's 4K lines of everything changing. Looks like it might be an EOL issue. The build seems to be changing it from LF line endings to CRLF line endings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:50:08 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 13 Feb 2015 23:50:08 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423871103.35.0.0139144165027.issue23461@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Ah ha. Do you have the hg eol extension enabled? If not, you probably should; it makes for far fewer headaches on Windows, and should make this issue go away. We should probably try to mitigate the problem anyway; Steve, how hard would it be to change the 'see if the newly generated file actually changed anything' logic to check line endings? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:55:31 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 13 Feb 2015 23:55:31 +0000 Subject: [issue13637] binascii.a2b_* functions could accept unicode strings In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za> Message-ID: <1423871731.5.0.27142069938.issue13637@psf.upfronthosting.co.za> Berker Peksag added the comment: The binascii documentation already says ``a2b_*`` functions accept Unicode strings containing only ASCII characters. [...] .. versionchanged:: 3.3 ASCII-only unicode strings are now accepted by the ``a2b_*`` functions. I think we can just remove versionchanged directives in fix_doc_binascii_unhexlify.v2.patch. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 00:58:47 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 13 Feb 2015 23:58:47 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423871927.07.0.111767460681.issue23461@psf.upfronthosting.co.za> Steve Dower added the comment: It's possible, but the eol extension is the best way to handle it. Doing the comparison is relatively easy (we can just strip all '\r' and '\n' characters and compare), but if it has changed, it's much harder to update the new file to match whatever the old file had. With eol, it'll always be \r\n and it Just Works. Leave this on me to update the check. If someone does try and push a change with EOL changes it'll be blocked anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 01:06:08 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 14 Feb 2015 00:06:08 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423872368.88.0.910724822948.issue23461@psf.upfronthosting.co.za> Paul Moore added the comment: I'm just about finished for the night but I'll try the eol extension tomorrow. I don't really use it much, though, my practice is generally to make all my tools use LF. I certainly didn't do anything that would change that file, so something in the build must be writing it in CRLF line ending mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 01:12:59 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 00:12:59 +0000 Subject: [issue13637] binascii.a2b_* functions could accept unicode strings In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za> Message-ID: <1423872779.05.0.798467669956.issue13637@psf.upfronthosting.co.za> Martin Panter added the comment: That?s another option. Someone might wonder why a2b_hex() and a2b_qp() actually accept text strings in Python 3.1 when the documentation says you need 3.3, but I guess that?s not such a big deal. Posting patch v3 which removes the 3.2 notices. ---------- Added file: http://bugs.python.org/file38132/fix_doc_binascii_unhexlify.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 01:23:13 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 14 Feb 2015 00:23:13 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423872368.88.0.910724822948.issue23461@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: The other option would be to change _freeze_importlib to force it to use \n instead of \r\n; I'm not sure which change would be harder to do. Paul: fair enough; I've just found that keeping eol enabled reduces headaches due to line endings to almost nothing, just because I never have to think about them at all (except for the rare files that are marked as 'BIN' in .hgeol). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 01:56:51 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 00:56:51 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423875411.06.0.0428366500051.issue23461@psf.upfronthosting.co.za> Mark Lawrence added the comment: I noticed a few days ago that this file had changed as I got a merge conflict using the tortoisehg sychronize command. At the time I didn't think much of it and believe I simply let hg sort it out. The changeset was 8ab6b404248c #21295. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 02:06:23 2015 From: report at bugs.python.org (eryksun) Date: Sat, 14 Feb 2015 01:06:23 +0000 Subject: [issue23425] Windows getlocale unix-like with french, german, portuguese, spanish In-Reply-To: <1423515310.7.0.637877209066.issue23425@psf.upfronthosting.co.za> Message-ID: <1423875983.03.0.00767022442293.issue23425@psf.upfronthosting.co.za> eryksun added the comment: > -setlocale should return nothing. It's a setter > -getlocale should return a platform-specific locale specification, > probably what is currently returned by setlocale. The output > should be ready for consumption by setlocale. These functions are well documented, so it's pointless to talk about major changes to the API. Per the docs, getlocale should return an RFC 1766 language code. If you want the platform result, use something like the following: def getrawlocale(category=locale.LC_CTYPE): return locale.setlocale(category) >>> locale.setlocale(locale.LC_CTYPE, 'eng') 'English_United Kingdom.1252' >>> getrawlocale() 'English_United Kingdom.1252' >>> # the new CRT supports RFC1766 ... locale.setlocale(locale.LC_CTYPE, 'en-GB') 'en-GB' >>> getrawlocale() 'en-GB' As I mentioned in issue 20088, the locale_alias dict is based on X11's locale.alias file. It doesn't handle most Windows locale strings of the form language_country.codepage. On Windows, the _locale extension module could enumerate the system locales at startup to build a mapping. Here's a rough prototype using ctypes (requires Vista or later for the new locale functions): import locale from ctypes import * from ctypes.wintypes import * LOCALE_WINDOWS = 1 LOCALE_SENGLISHLANGUAGENAME = 0x1001 LOCALE_SENGLISHCOUNTRYNAME = 0x1002 LOCALE_IDEFAULTANSICODEPAGE = 0x1004 LCTYPES = (LOCALE_SENGLISHLANGUAGENAME, LOCALE_SENGLISHCOUNTRYNAME, LOCALE_IDEFAULTANSICODEPAGE) kernel32 = WinDLL('kernel32') EnumSystemLocalesEx = kernel32.EnumSystemLocalesEx GetLocaleInfoEx = kernel32.GetLocaleInfoEx EnumLocalesProcEx = WINFUNCTYPE(BOOL, LPWSTR, DWORD, LPARAM) def enum_system_locales(): alias = {} codepage = {} info = (WCHAR * 100)() @EnumLocalesProcEx def callback(locale, flags, param): if '-' not in locale: return True parts = [] for lctype in LCTYPES: if not GetLocaleInfoEx(locale, lctype, info, len(info)): raise WinError() parts.append(info.value) lang, ctry, code = parts if lang and ctry and code != '0': locale = locale.replace('-', '_') full = '{}_{}'.format(lang, ctry) alias[full] = locale codepage[locale] = 'cp' + code return True if not EnumSystemLocalesEx(callback, LOCALE_WINDOWS, None, None): raise WinError() return alias, codepage >>> alias, codepage = enum_system_locales() >>> alias["English_United Kingdom"] 'en_GB' >>> codepage['en_GB'] 'cp1252' >>> alias["Spanish_United States"] 'es_US' >>> codepage['es_US'] 'cp1252' >>> alias["Russian_Russia"] 'ru_RU' >>> codepage['ru_RU'] 'cp1251' >>> alias["Chinese (Simplified)_People's Republic of China"] 'zh_CN' >>> codepage['zh_CN'] 'cp936' ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 02:07:08 2015 From: report at bugs.python.org (Demian Brecht) Date: Sat, 14 Feb 2015 01:07:08 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1423876028.97.0.715206350455.issue22928@psf.upfronthosting.co.za> Demian Brecht added the comment: Here's a patch addressing the potential vulnerability as reported. The patch should also bring the implementation up to date with the most recent standards around header names and values. > There could be potential for breaking compatibility if people are intentionally sending values with folded lines (obsoleted by the new HTTP RFC). I think I'm okay with this given line folding seems to have been implemented by passing multiple value parameters (folding was automatically taken care of by the library). I don't think that this should be merged into anything pre 3.5 as safeguarding /should/ be accounted for by the developer, so I don't think I'd regard this as a high risk security issue. I'm definitely open to debate on that though. ---------- Added file: http://bugs.python.org/file38133/issue22928.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 02:25:50 2015 From: report at bugs.python.org (Demian Brecht) Date: Sat, 14 Feb 2015 01:25:50 +0000 Subject: [issue23440] Extend http.server.SimpleHTTPRequestHandler testing In-Reply-To: <1423640571.78.0.653754704207.issue23440@psf.upfronthosting.co.za> Message-ID: <1423877150.2.0.789745308246.issue23440@psf.upfronthosting.co.za> Demian Brecht added the comment: LGTM ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 02:26:08 2015 From: report at bugs.python.org (Ben Hoyt) Date: Sat, 14 Feb 2015 01:26:08 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1423877168.71.0.531304346931.issue22524@psf.upfronthosting.co.za> Ben Hoyt added the comment: Akari: yes, I'm aware of this, and it's definitely a concern to me -- it may be that scandir has a bug with counting the size of certain non-file directory entries, or my implementation of os.walk() via scandir is not quite correct. I'll look at it before too long! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 02:36:05 2015 From: report at bugs.python.org (Demian Brecht) Date: Sat, 14 Feb 2015 01:36:05 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes In-Reply-To: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> Message-ID: <1423877765.43.0.598694511631.issue23410@psf.upfronthosting.co.za> Demian Brecht added the comment: Minor comment in Rietveld, otherwise LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 02:52:46 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 01:52:46 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1423878766.14.0.547411032612.issue22928@psf.upfronthosting.co.za> Martin Panter added the comment: If we?re in the realm of 3.5 only changes, it might make sense to remove the multi-argument mode of putheader() altogether, and document it only generates a single line. (Currently still says it generates multiple lines.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 03:00:34 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 02:00:34 +0000 Subject: [issue19829] _pyio.BufferedReader and _pyio.TextIOWrapper destructor don't emit ResourceWarning if the file is not closed In-Reply-To: <1385721421.95.0.384748799117.issue19829@psf.upfronthosting.co.za> Message-ID: <1423879234.78.0.00240585748872.issue19829@psf.upfronthosting.co.za> Martin Panter added the comment: One option would be for any wrapper-type class (e.g. BufferedReader, SocketIO) to override __del__(). Instead of calling close(), it should call detach() or equivalent, and delete the returned reference to the underlying wrapped object without explicitly closing it, to allow a warning to be generated. Maybe a WrappedIO mixin class could help with this. I am posting del-detach.patch which roughly implements the above option. It only seems to break the test_override_destructor() tests for the TextIOWrapperTest and CommonBufferedTests classes, which expect close() to be called. Another more radical option might be to make IOBase.__del__() only call flush(), not close(), except for the actual implementations that really should emit a warning, like FileIO. I will have a go at doing this option in another patch. Both these options would change the behaviour in some cases that rely on the garbage collector to close objects. They would defer the automatic closing until all references of the underlying object are garbage collected, instead of just when the wrapped object is garbage collected. A third option would be to add explicit __del__() methods emitting a warning in each class, along with any exception supression needed due to Python interpreter finalization quirks. ---------- keywords: +patch Added file: http://bugs.python.org/file38134/del-detach.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 03:04:40 2015 From: report at bugs.python.org (Demian Brecht) Date: Sat, 14 Feb 2015 02:04:40 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1423878766.14.0.547411032612.issue22928@psf.upfronthosting.co.za> Message-ID: <54DEAD32.6010002@gmail.com> Demian Brecht added the comment: I think that keeping the public API as-is is the better way to go, at least for the shorter term given it won't require users to have to make code changes. Thanks for the catch on the docs though, will update that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 03:09:03 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 02:09:03 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1423879743.64.0.945548577855.issue22928@psf.upfronthosting.co.za> Martin Panter added the comment: Good point. Maybe join them with tabs rather than spaces then, since it was previously "\r\n\t". This way it is even closer to before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 03:12:59 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 02:12:59 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1423879979.97.0.507941248348.issue22351@psf.upfronthosting.co.za> Martin Panter added the comment: I believe this still leaves the socket open via the ?file? object. Just that there is no ResourceWarning generated due to the way IOBase.__del__() works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 03:48:40 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 02:48:40 +0000 Subject: [issue19829] _pyio.BufferedReader and _pyio.TextIOWrapper destructor don't emit ResourceWarning if the file is not closed In-Reply-To: <1385721421.95.0.384748799117.issue19829@psf.upfronthosting.co.za> Message-ID: <1423882120.49.0.312425396196.issue19829@psf.upfronthosting.co.za> Martin Panter added the comment: Posting del-flush.patch, which only calls flush() instead of close() from __del__(), except for the FileIO class. Quick analysis of resulting test failures: These tests fail because they are obviously written to test that __del__ calls close(): * IOTest.test_IOBase_destructor * IOTest.test_RawIOBase_destructor * IOTest.test_BufferedIOBase_destructor * IOTest.test_TextIOBase_destructor * test_override_destructor as mentioned above CBufferedReader/Writer/RandomTest.test_garbage_collection() fail because they do not free the reference to the wrapped raw file object. Similarly, CTextIOWrapperTest.test_garbage_collection() holds references to both levels of wrapped object. TextIOWrapperTest.test_destructor() fails because it assumes the wrapped close() will be called. The data is still written to the wrapped file though. MiscIOTest.test_warn_on_dealloc/_fd() fail because the warning message only refers to the FileIO object rather than the wrapper object. ---------- Added file: http://bugs.python.org/file38135/del-flush.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 03:51:53 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 02:51:53 +0000 Subject: [issue19829] _pyio.BufferedReader and _pyio.TextIOWrapper destructor don't emit ResourceWarning if the file is not closed In-Reply-To: <1385721421.95.0.384748799117.issue19829@psf.upfronthosting.co.za> Message-ID: <1423882313.92.0.2075473525.issue19829@psf.upfronthosting.co.za> Changes by Martin Panter : Removed file: http://bugs.python.org/file38135/del-flush.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 03:56:54 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 02:56:54 +0000 Subject: [issue19829] _pyio.BufferedReader and _pyio.TextIOWrapper destructor don't emit ResourceWarning if the file is not closed In-Reply-To: <1385721421.95.0.384748799117.issue19829@psf.upfronthosting.co.za> Message-ID: <1423882614.41.0.409174330082.issue19829@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file38136/del-flush.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 04:57:44 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 03:57:44 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1423886264.01.0.606442870508.issue22351@psf.upfronthosting.co.za> Martin Panter added the comment: Posting a new patch which closes the file object, and also does the same for the SSL class. ---------- Added file: http://bugs.python.org/file38137/issue22351_nntp_fail_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 05:38:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 04:38:22 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1423888702.94.0.960662141043.issue23350@psf.upfronthosting.co.za> Martin Panter added the comment: New patch looks good I think. Making the encoding code more consistent is nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 07:56:49 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 14 Feb 2015 06:56:49 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423897009.94.0.42838207524.issue23461@psf.upfronthosting.co.za> Paul Moore added the comment: No, enabling the eol extension didn't fix it :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 08:28:17 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 14 Feb 2015 07:28:17 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423898897.51.0.142706753135.issue23461@psf.upfronthosting.co.za> Paul Moore added the comment: Correction. Looks like if I enable the eol extension, then hg revert importlib.h, then rebuild, the problem then goes away. So basically you need the eol extension enabled *before* you update/clone your checkout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 09:45:26 2015 From: report at bugs.python.org (Jeremy Nicola) Date: Sat, 14 Feb 2015 08:45:26 +0000 Subject: [issue23462] All os.exec*e variants crash on Windows Message-ID: <1423903526.7.0.282245151833.issue23462@psf.upfronthosting.co.za> New submission from Jeremy Nicola: On Windows 7, using python 3.4.2 32 bits MSVCv.1600 or 3.4.1 64 bits, all the os.exec*e variants crash: os.execle('C:/Python34/python.exe','Python.exe','-V',{}) os.execve('C:/Python34/python.exe',['python.exe','-V'],{}) os.execlpe('C:/Python34/python.exe','python.exe','-V',{}) os.execvpe('C:/Python34/python.exe',['python.exe','-V'],{}) Without any error message, windows will just open a "Python.exe has stopped working" window, be the scripts run from an interactive shell or invoking python script.py On the other hand, os.execl('C:/Python34/python.exe','Python.exe','-V') os.execve('C:/Python34/python.exe',['python.exe','-V']) os.execlpe('C:/Python34/python.exe','python.exe','-V') os.execvpe('C:/Python34/python.exe',['python.exe','-V']) will work perfectly. ---------- components: Windows messages: 235952 nosy: nicolaje, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: All os.exec*e variants crash on Windows type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 09:47:44 2015 From: report at bugs.python.org (Jeremy Nicola) Date: Sat, 14 Feb 2015 08:47:44 +0000 Subject: [issue23462] All os.exec*e variants crash on Windows In-Reply-To: <1423903526.7.0.282245151833.issue23462@psf.upfronthosting.co.za> Message-ID: <1423903664.61.0.262509212727.issue23462@psf.upfronthosting.co.za> Jeremy Nicola added the comment: You should read: os.execv('C:/Python34/python.exe',['python.exe','-V']) os.execlp('C:/Python34/python.exe','python.exe','-V') os.execvp('C:/Python34/python.exe',['python.exe','-V']) for the "what works". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 10:02:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 09:02:38 +0000 Subject: [issue19105] pprint doesn't use all width In-Reply-To: <1380289834.62.0.88627838079.issue19105@psf.upfronthosting.co.za> Message-ID: <20150214090232.72263.2205@psf.io> Roundup Robot added the comment: New changeset 7a6671d491da by Serhiy Storchaka in branch 'default': Issue #19105: pprint now more efficiently uses free space at the right. https://hg.python.org/cpython/rev/7a6671d491da ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 10:06:07 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 09:06:07 +0000 Subject: [issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message In-Reply-To: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za> Message-ID: <1423904767.17.0.172276879899.issue20508@psf.upfronthosting.co.za> Mark Lawrence added the comment: Could someone review the attached patch please. I've looked at the test code and there is one assertRaises for IndexError which I'm assuming covers this case. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 10:10:58 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 09:10:58 +0000 Subject: [issue20657] OpenBSD: Merge patches In-Reply-To: <1392639207.52.0.881152822714.issue20657@psf.upfronthosting.co.za> Message-ID: <1423905058.11.0.790754099166.issue20657@psf.upfronthosting.co.za> Mark Lawrence added the comment: Do any patches still need merging into 3.x or is this out of date? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 10:24:16 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 09:24:16 +0000 Subject: [issue20833] scripts\pydocgui.pyw out of date In-Reply-To: <1393787654.65.0.406806459442.issue20833@psf.upfronthosting.co.za> Message-ID: <1423905856.42.0.220318082311.issue20833@psf.upfronthosting.co.za> Mark Lawrence added the comment: This file has already been removed from the default and 3.4 branches. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 10:46:44 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 09:46:44 +0000 Subject: [issue22071] Remove long-time deprecated attributes from smtpd In-Reply-To: <1406307098.0.0.954478358175.issue22071@psf.upfronthosting.co.za> Message-ID: <1423907204.95.0.12622526444.issue22071@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can we have a patch review on this please. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 10:52:24 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 09:52:24 +0000 Subject: [issue22211] Remove VMS specific code in expat.h & xmlrole.h In-Reply-To: <1408222450.15.0.0579194114943.issue22211@psf.upfronthosting.co.za> Message-ID: <1423907544.87.0.10776921024.issue22211@psf.upfronthosting.co.za> Mark Lawrence added the comment: @John can you provide a patch to remove the VMS specific code from the two files mentioned? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 10:58:01 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 09:58:01 +0000 Subject: [issue20575] Type handling policy for the statistics module In-Reply-To: <1391952583.31.0.349942146298.issue20575@psf.upfronthosting.co.za> Message-ID: <1423907881.21.0.927371396258.issue20575@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Steven would you please comment on this issue, thanks. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 11:12:14 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 10:12:14 +0000 Subject: [issue22633] Memory disclosure/buffer overread via bug in Py_FrozenMain In-Reply-To: <1413311714.85.0.507321102423.issue22633@psf.upfronthosting.co.za> Message-ID: <1423908734.76.0.448040286697.issue22633@psf.upfronthosting.co.za> Mark Lawrence added the comment: Would someone please review the inline patch, thanks. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 11:21:59 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 10:21:59 +0000 Subject: [issue22844] test_gdb failure on Debian Wheezy for Z In-Reply-To: <1415670788.7.0.445632155994.issue22844@psf.upfronthosting.co.za> Message-ID: <1423909319.84.0.665712174786.issue22844@psf.upfronthosting.co.za> Mark Lawrence added the comment: The inline patch seems fine to my eyes but who would usually comment on a proposed change to test_gdb.py? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 11:28:30 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 10:28:30 +0000 Subject: [issue22794] missing test for issue 22457 regression commit In-Reply-To: <1415113437.67.0.13245212924.issue22794@psf.upfronthosting.co.za> Message-ID: <1423909710.5.0.736373158057.issue22794@psf.upfronthosting.co.za> Mark Lawrence added the comment: Just a gentle reminder. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 12:54:00 2015 From: report at bugs.python.org (Tom Edwards) Date: Sat, 14 Feb 2015 11:54:00 +0000 Subject: [issue23463] Incorrect behaviour when opening files containing colons on Windows Message-ID: <1423914840.96.0.470956533091.issue23463@psf.upfronthosting.co.za> New submission from Tom Edwards: Consider this script: f = open("bug>test.txt",'w') f.write("hello") f.close() On Windows the first line will throw an OSError exception because the character '>' is not valid in an NTFS filename. This is correct. Now consider this script: f = open("bug:test.txt",'w') f.write("hello") f.close() This script will complete without error, and f.write will return 5. This despite the colon character also being invalid in NTFS filenames! The output of the second script is an empty file called "bug" in the working directory. I expect it to throw the same exception as the first script. ---------- components: IO messages: 235964 nosy: Artfunkel priority: normal severity: normal status: open title: Incorrect behaviour when opening files containing colons on Windows type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 13:02:18 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 14 Feb 2015 12:02:18 +0000 Subject: [issue23463] Incorrect behaviour when opening files containing colons on Windows In-Reply-To: <1423914840.96.0.470956533091.issue23463@psf.upfronthosting.co.za> Message-ID: <1423915338.43.0.512762679533.issue23463@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Windows nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 13:09:16 2015 From: report at bugs.python.org (Tim Golden) Date: Sat, 14 Feb 2015 12:09:16 +0000 Subject: [issue23463] Incorrect behaviour when opening files containing colons on Windows In-Reply-To: <1423914840.96.0.470956533091.issue23463@psf.upfronthosting.co.za> Message-ID: <1423915756.93.0.531077487255.issue23463@psf.upfronthosting.co.za> Tim Golden added the comment: Colons are valid in filenames to introduce Alternate Data Stream: https://msdn.microsoft.com/en-us/library/cc422524.aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 13:09:39 2015 From: report at bugs.python.org (Tim Golden) Date: Sat, 14 Feb 2015 12:09:39 +0000 Subject: [issue23463] Incorrect behaviour when opening files containing colons on Windows In-Reply-To: <1423914840.96.0.470956533091.issue23463@psf.upfronthosting.co.za> Message-ID: <1423915779.82.0.609009945671.issue23463@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 13:48:56 2015 From: report at bugs.python.org (Tom Edwards) Date: Sat, 14 Feb 2015 12:48:56 +0000 Subject: [issue23463] Incorrect behaviour when opening files containing colons on Windows In-Reply-To: <1423914840.96.0.470956533091.issue23463@psf.upfronthosting.co.za> Message-ID: <1423918136.34.0.200377742117.issue23463@psf.upfronthosting.co.za> Tom Edwards added the comment: Ha! What a feature. Thanks for the link. Maybe I'm rehashing old arguments, but I still think that Python's behaviour in this case is wrong. This is very surprising behaviour to anyone who isn't intimately familiar with NTFS and should not be something that in invoked silently. Currently *everyone* who wants to open a file is expected to perform their own test for colons in the path, particularly those who are generating filenames from user data. (Unless they actually want to write to an alternate stream of course, but how often does that happen?) This is behaviour also introduces a cross-platform inconsistency, as a filename on NTFS means something slightly different from a filename on any other file system. Would it be wise for open() to only accept NTFS alternate stream path syntax if a special character is present in the 'mode' argument? ---------- components: -Windows resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 13:54:58 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 14 Feb 2015 12:54:58 +0000 Subject: [issue23463] Incorrect behaviour when opening files containing colons on Windows In-Reply-To: <1423914840.96.0.470956533091.issue23463@psf.upfronthosting.co.za> Message-ID: <1423918498.83.0.880617485007.issue23463@psf.upfronthosting.co.za> R. David Murray added the comment: Python just exposes the OS filename semantics, it doesn't judge them :) This is just as true on linux as it is on Windows. ---------- nosy: +r.david.murray resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 14:10:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 13:10:45 +0000 Subject: [issue17530] pprint could use line continuation for long bytes literals In-Reply-To: <1364067577.46.0.261047534718.issue17530@psf.upfronthosting.co.za> Message-ID: <1423919445.35.0.834841125804.issue17530@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch based on current str formatting code (i.e. parenthesis are added only if needed, the space at the right is used more efficiently). It adds pprint support for bytes and bytearrays. Bytes are broken only at positions divisible by 4, so packed 32-bit ints are never broken. Examples: >>> pprint.pprint(bytes(range(128))) (b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13' b'\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !"#$%&\'()*+,-./01234567' b'89:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{' b'|}~\x7f') >>> pprint.pprint({'abcdefgh': bytes(range(128))}) {'abcdefgh': b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f' b'\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f' b' !"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[' b'\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f'} >>> pprint.pprint(bytearray(range(128))) bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f' b'\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f' b' !"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_' b'`abcdefghijklmnopqrstuvwxyz{|}~\x7f') >>> pprint.pprint({'abcdefgh': bytearray(range(128))}) {'abcdefgh': bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b' b'\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17' b'\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !"#$%&\'()*+,-./0123' b'456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefg' b'hijklmnopqrstuvwxyz{|}~\x7f')} ---------- nosy: +serhiy.storchaka Added file: http://bugs.python.org/file38138/pprint_bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 14:20:14 2015 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 14 Feb 2015 13:20:14 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423920014.91.0.244006342302.issue23461@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Paul: wrt. your statement "eol extension tomorrow. I don't really use it much,". This can't be really true: either you use it, or you don't. If you use it at all, then you also use it MUCH: Python is a heavy user of the eol extension, and the entire Python hg repository can't work without it. It's an absolute requirement that anybody working on the CPython repository has the eol extension enabled. In fact, the eol extension was added to Mercurial because of CPython, and was basically designed on python-dev. Look at CPython's .hgeol file to see what files are affected by it (it's basically every file under source control). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 14:45:21 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 14 Feb 2015 13:45:21 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423921521.01.0.288933380199.issue23461@psf.upfronthosting.co.za> Paul Moore added the comment: Martin, thanks for the clarification. When I said "I don't use it much" what I meant was that I've never had it enabled, and for all of the repositories I use, not doing so has never been a problem (until now). In contrast, git's autocrlf feature, which is enabled by default, *has* caused me issues, so I tend to work on the basis that I'm better making sure my tools interoperate properly with Unix-style line endings than making my VCS translate for me. I was reluctant to enable the eol extension globally because of this. I've just discovered however that extensions can be enabled on a per-repo basis, which is a nice compromise, or I may just enable it globally and learn how to use it properly for other projects. I recall the discussion when the eol extension was created. However, I had mistakenly got the impression that the extension was for people who needed to work with CRLF extensions locally (IIRC, Visual Studio was a tool that preferred CRLF). Clearly that was wrong, and I'll switch to using the eol extension now. (As an aside, one of the downsides of having lurked on the edges of the python-dev community for as long as I have is that you think you know the processes, when actually they've changed since you last checked. Lesson learned - I'll reread the docs next time :-)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 15:09:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 14:09:23 +0000 Subject: [issue19105] pprint doesn't use all width In-Reply-To: <1380289834.62.0.88627838079.issue19105@psf.upfronthosting.co.za> Message-ID: <1423922963.52.0.110535540623.issue19105@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 15:18:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 14:18:26 +0000 Subject: [issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message In-Reply-To: <1391519371.56.0.280883005316.issue20508@psf.upfronthosting.co.za> Message-ID: <1423923506.9.0.367778482276.issue20508@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy, needs review stage: -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 15:35:14 2015 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Sat, 14 Feb 2015 14:35:14 +0000 Subject: [issue23464] Remove or deprecate JoinableQueue in asyncio docs Message-ID: <1423924514.61.0.0196289031224.issue23464@psf.upfronthosting.co.za> New submission from A. Jesse Jiryu Davis: asyncio.JoinableQueue was once a distinct subclass of asyncio.Queue, now it's just a deprecated alias. Once this is merged into CPython: https://code.google.com/p/tulip/issues/detail?id=220 ...then remove or deprecate JoinableQueue in asyncio-sync.rst ---------- components: asyncio messages: 235971 nosy: emptysquare, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Remove or deprecate JoinableQueue in asyncio docs versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 15:37:54 2015 From: report at bugs.python.org (F.) Date: Sat, 14 Feb 2015 14:37:54 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1423924674.22.0.138346280656.issue11245@psf.upfronthosting.co.za> F. added the comment: IMAP polling hurts, just merge imaplib2 into standard library as imaplib. Piers Lauder authored imaplib IMAP4 client, part of python standard library, back in December 1997 based on RFC 2060. In 2003 RFC 2060 was made obsolete by RFC 3501 adding important features and Piers released imaplib2 which receives feature updates since. Last feature updates to the standard library imaplib were before Piers retired from Sydney University a decade ago. imaplib2 presents an almost identical API as that provided by the standard library imaplib, the main difference being that imaplib2 allows parallel execution of commands on the IMAP4 server, and implements the IDLE extension, so NO POLLING IS REQUIRED. IMAP server will push new mail notifications to the client. Imaplib2 also supports COMPRESS, ID, better timeout handling etc. There is 975 more lines of code all doing useful things a modern IMAP client needs. imaplib2 can be substituted for imaplib in existing clients with no changes in the code apart from required logout call to shutdown the threads. Old imaplib was ported to Python 3 with the rest of the standard library. I am working to port imaplib2 to py3, stuck on receiving bytes v strings. References: imaplib2 code and docs http://sourceforge.net/p/imaplib2/code/ci/master/tree/ also http://sydney.edu.au/engineering/it/~piers/python/imaplib2.html imaplib https://hg.python.org/cpython/file/3.4/Lib/imaplib.py Ruby stdlib support for idle (not that it hurts python performance, just my pride) http://ruby-doc.org/stdlib-2.0.0/libdoc/net/imap/rdoc/Net/IMAP.html#method-i-idle ---------- nosy: +Malina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 15:39:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 14:39:25 +0000 Subject: [issue22844] test_gdb failure on Debian Wheezy for Z In-Reply-To: <1415670788.7.0.445632155994.issue22844@psf.upfronthosting.co.za> Message-ID: <1423924765.52.0.653934547016.issue22844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please show tests logs David? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 15:59:15 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 14 Feb 2015 14:59:15 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments Message-ID: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> New submission from Paul Moore: Implementation of PEP 486 (Make the Python Launcher aware of virtual environments). Tested manually on my local PC - there aren't currently any tests for the launcher that I can see (and I'm not entirely sure how I'd write such a test) so the patch includes code and docs but no tests. ---------- assignee: steve.dower files: pep486.patch keywords: patch messages: 235974 nosy: pmoore, steve.dower, vinay.sajip priority: normal severity: normal stage: patch review status: open title: Implement PEP 486 - Make the Python Launcher aware of virtual environments type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38139/pep486.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 16:41:31 2015 From: report at bugs.python.org (eryksun) Date: Sat, 14 Feb 2015 15:41:31 +0000 Subject: [issue23462] All os.exec*e variants crash on Windows In-Reply-To: <1423903526.7.0.282245151833.issue23462@psf.upfronthosting.co.za> Message-ID: <1423928491.6.0.502621327637.issue23462@psf.upfronthosting.co.za> eryksun added the comment: Calling nt.execv works with a unicode string because it creates a bytes path via PyUnicode_FSConverter. OTOH, nt.execve uses path_converter, which doesn't convert unicode to bytes on Windows. Thus in posixmodule.c, for the call execve(path->narrow, argvlist, envlist), path->narrow is NULL, and the CRT kills the process due to a bad argument: (70.135c): Break instruction exception - code 80000003 (first chance) ntdll!LdrpDoDebuggerBreak+0x30: 00000000`7733cb70 cc int 3 0:000> bp ntdll!ZwTerminateProcess 0:000> bp desktopcrt140!execve 0:000> g ModLoad: 000007fe`fc850000 000007fe`fc868000 C:\Windows\system32\CRYPTSP.dll ModLoad: 000007fe`fc550000 000007fe`fc597000 C:\Windows\system32\rsaenh.dll ModLoad: 000007fe`fceb0000 000007fe`fcebf000 C:\Windows\system32\CRYPTBASE.dll Python 3.5.0a1 (v3.5.0a1:5d4b6a57d5fd, Feb 7 2015, 18:15:14) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import nt, sys >>> path = sys.executable >>> nt.execve(path, ['python', '-V'], {}) Breakpoint 1 hit DESKTOPCRT140!_execve: 000007fe`fa5ac43c 4d8bc8 mov r9,r8 0:000> r rcx rcx=0000000000000000 The first argument is passed in AMD64 register rcx, which you can see is NULL here. 0:000> g Breakpoint 0 hit ntdll!NtTerminateProcess: 00000000`772e1570 4c8bd1 mov r10,rcx 0:000> k 8 Child-SP RetAddr Call Site 00000000`0038f5c8 000007fe`fd11402f ntdll!NtTerminateProcess 00000000`0038f5d0 000007fe`f54e003a KERNELBASE!TerminateProcess+0x2f 00000000`0038f600 000007fe`f54e0055 APPCRT140!_invalid_parameter+0x76 00000000`0038f640 000007fe`fa5abbd8 APPCRT140!_invalid_parameter_noinfo+0x19 00000000`0038f680 00000000`6aa116a7 DESKTOPCRT140!common_spawnv+0x44 00000000`0038f6e0 00000000`6aa115a8 python35!os_execve_impl+0xb7 00000000`0038f720 00000000`6aa9ff3b python35!os_execve+0xa8 00000000`0038f7d0 00000000`6ab14aed python35!PyCFunction_Call+0xfb Using a bytes path with nt.execve will work, but it's deprecated on Windows: C:\>py -3.5 -Wall Python 3.5.0a1 (v3.5.0a1:5d4b6a57d5fd, Feb 7 2015, 18:15:14) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os, nt, sys >>> path = os.fsencode(sys.executable) >>> nt.execve(path, ['python', '-V'], {}) __main__:1: DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead C:\>Python 3.5.0a1 Since bytes paths are deprecated on Windows, these calls should be using wexecv and wexecve. https://msdn.microsoft.com/en-us/library/431x4c1w%28v=vs.100%29.aspx ---------- nosy: +eryksun versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 18:11:05 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 17:11:05 +0000 Subject: [issue17753] test_zipfile: requires write access to test and email.test In-Reply-To: <1366109637.36.0.807884734436.issue17753@psf.upfronthosting.co.za> Message-ID: <1423933865.56.0.0777007834208.issue17753@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. ---------- nosy: +berker.peksag stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 18:31:36 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 14 Feb 2015 17:31:36 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1423935096.31.0.778148970391.issue23465@psf.upfronthosting.co.za> Steve Dower added the comment: I don't think there are any tests for the launcher at all, though it would be fairly simple to write a Python script that runs ``py -c "import sys; print(sys.prefix)"`` and checks the output. The patch looks fine to me, once I noticed that venv_python is a static local :). When the PEP is accepted I'll apply the patch (I don't think I've been appointed BDFL-delegate for this yet as Nick suggested, but if I am then I don't see any reason not to accept it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 18:32:53 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 17:32:53 +0000 Subject: [issue22735] Fix various crashes exposed through mro() customization In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za> Message-ID: <1423935173.28.0.725492438655.issue22735@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 18:38:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 17:38:54 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <20150214173838.126606.7013@psf.io> Roundup Robot added the comment: New changeset f9a43e2a3877 by Steve Dower in branch 'default': Issue #23461: Normalise line endings when comparing old and new contents of importlib.h https://hg.python.org/cpython/rev/f9a43e2a3877 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 18:39:00 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 17:39:00 +0000 Subject: [issue23399] venv should create relative symlinks where possible In-Reply-To: <1423180981.46.0.156182357728.issue23399@psf.upfronthosting.co.za> Message-ID: <1423935540.65.0.265501559381.issue23399@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 18:45:13 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 14 Feb 2015 17:45:13 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423935913.24.0.0699504862197.issue23461@psf.upfronthosting.co.za> Steve Dower added the comment: The changeset will skip updating importlib.h if the only change is line endings, but if there are other changes it will be updated to a CRLF file. This will be fine if the eol extension is enabled, and h.p.o will reject pushes that have CRLF line endings. However, this will make it much easier for non-core devs to build from source, whether from h.p.o or the tarballs. ---------- resolution: -> fixed status: open -> closed type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 18:53:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 17:53:05 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <20150214175247.62565.32808@psf.io> Roundup Robot added the comment: New changeset add998f98e31 by Steve Dower in branch 'default': Closes #23437: Make user scripts directory versioned on Windows (patch by pmoore) https://hg.python.org/cpython/rev/add998f98e31 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 18:55:16 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 17:55:16 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1423936516.2.0.683624844476.issue23406@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 19:17:14 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 18:17:14 +0000 Subject: [issue12955] urllib.request example should use "with ... as:" In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za> Message-ID: <1423937834.67.0.624841811664.issue12955@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 19:19:33 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 14 Feb 2015 18:19:33 +0000 Subject: [issue23414] seek(count, whence) accepts bogus whence on windows, python2.7 In-Reply-To: <1423431538.2.0.390923477638.issue23414@psf.upfronthosting.co.za> Message-ID: <1423937973.44.0.60405735525.issue23414@psf.upfronthosting.co.za> Steve Dower added the comment: I can't say why 2.7 doesn't use _fseeki64, but 3.5 certainly does. Possibly it's a significant change of behaviour that would break backwards compatibility? Making a currently working call raise new exceptions is certainly worth double-checking before introducing into a maintenance release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 19:27:56 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 18:27:56 +0000 Subject: [issue23420] python -m cProfile -s fails with non informative message In-Reply-To: <1423483542.47.0.873331461969.issue23420@psf.upfronthosting.co.za> Message-ID: <1423938476.05.0.919079506909.issue23420@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +Library (Lib) -Extension Modules nosy: +berker.peksag stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 19:34:37 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 18:34:37 +0000 Subject: [issue4773] HTTPMessage not documented and has inconsistent API across Py2/Py3 In-Reply-To: <1230586952.45.0.591912771259.issue4773@psf.upfronthosting.co.za> Message-ID: <1423938877.84.0.198305458154.issue4773@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 19:39:44 2015 From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=) Date: Sat, 14 Feb 2015 18:39:44 +0000 Subject: [issue23420] python -m cProfile -s fails with non informative message In-Reply-To: <1423483542.47.0.873331461969.issue23420@psf.upfronthosting.co.za> Message-ID: <1423939184.68.0.811739865084.issue23420@psf.upfronthosting.co.za> Changes by Mat?j Stuchl?k : ---------- nosy: +sYnfo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 19:48:37 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 14 Feb 2015 18:48:37 +0000 Subject: [issue23461] Building on windows modifies importlib.h In-Reply-To: <1423869048.38.0.453011208999.issue23461@psf.upfronthosting.co.za> Message-ID: <1423939717.76.0.237014945836.issue23461@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks, Steve! ---------- assignee: -> steve.dower stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 19:51:50 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 14 Feb 2015 18:51:50 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <1423939910.82.0.633574317364.issue23437@psf.upfronthosting.co.za> Zachary Ware added the comment: This one could use a NEWS entry, and possibly what's new as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 19:53:37 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 14 Feb 2015 18:53:37 +0000 Subject: [issue23460] Decimals do not obey ':g' exponential notation formatting rules In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za> Message-ID: <1423940017.24.0.920265574106.issue23460@psf.upfronthosting.co.za> Stefan Krah added the comment: For Decimal the cutoff point is -6 instead of -4 (following the decimal specification instead of the C standard). ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python, skrah type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 21:08:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 20:08:22 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <20150214200818.60736.4412@psf.io> Roundup Robot added the comment: New changeset a2217106ca5e by Steve Dower in branch 'default': Issue #23437: Update NEWS and whatsnew/3.5 https://hg.python.org/cpython/rev/a2217106ca5e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 21:08:57 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 14 Feb 2015 20:08:57 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <1423944537.58.0.15824535925.issue23437@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks. I always forget about those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 21:10:25 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 14 Feb 2015 20:10:25 +0000 Subject: [issue23437] Make user scripts directory versioned on Windows In-Reply-To: <1423601186.31.0.692326413397.issue23437@psf.upfronthosting.co.za> Message-ID: <1423944625.83.0.0535642400392.issue23437@psf.upfronthosting.co.za> Paul Moore added the comment: Sorry, I should probably have added them to the patch in the first place :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 21:17:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 20:17:55 +0000 Subject: [issue22633] Memory disclosure/buffer overread via bug in Py_FrozenMain In-Reply-To: <1413311714.85.0.507321102423.issue22633@psf.upfronthosting.co.za> Message-ID: <20150214201751.71248.24105@psf.io> Roundup Robot added the comment: New changeset d0b6efed4766 by Benjamin Peterson in branch '3.4': avoid reading unallocated memory when argc == 0 (closes #22633) https://hg.python.org/cpython/rev/d0b6efed4766 New changeset 687b970c8ba9 by Benjamin Peterson in branch '2.7': avoid reading unallocated memory when argc == 0 (closes #22633) https://hg.python.org/cpython/rev/687b970c8ba9 New changeset ba2da33d2654 by Benjamin Peterson in branch 'default': merge 3.4 (#22633) https://hg.python.org/cpython/rev/ba2da33d2654 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 21:28:16 2015 From: report at bugs.python.org (David Edelsohn) Date: Sat, 14 Feb 2015 20:28:16 +0000 Subject: [issue22844] test_gdb failure on Debian Wheezy for Z In-Reply-To: <1415670788.7.0.445632155994.issue22844@psf.upfronthosting.co.za> Message-ID: <1423945696.47.0.846197298641.issue22844@psf.upfronthosting.co.za> David Edelsohn added the comment: The errors are of the form: ====================================================================== FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "/mnt/DREAMStorage/dje/cpython-buildarea/3.x.edelsohn-zwheezy-z/build/Lib/test/test_gdb.py", line 470, in test_NULL_ob_type 'set v->ob_type=0') File "/mnt/DREAMStorage/dje/cpython-buildarea/3.x.edelsohn-zwheezy-z/build/Lib/test/test_gdb.py", line 441, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File "/mnt/DREAMStorage/dje/cpython-buildarea/3.x.edelsohn-zwheezy-z/build/Lib/test/test_gdb.py", line 227, in get_gdb_repr import_site=import_site) File "/mnt/DREAMStorage/dje/cpython-buildarea/3.x.edelsohn-zwheezy-z/build/Lib/test/test_gdb.py", line 205, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['warning: Could not load shared library symbols for linux-vdso64.so.1.'] != [] First list contains 1 additional elements. First extra element 0: warning: Could not load shared library symbols for linux-vdso64.so.1. - ['warning: Could not load shared library symbols for linux-vdso64.so.1.'] + [] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 21:37:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 20:37:51 +0000 Subject: [issue22844] test_gdb failure on Debian Wheezy for Z In-Reply-To: <1415670788.7.0.445632155994.issue22844@psf.upfronthosting.co.za> Message-ID: <1423946271.21.0.150621191209.issue22844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks. The patch LGTM. ---------- assignee: -> serhiy.storchaka stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 21:38:56 2015 From: report at bugs.python.org (David Edelsohn) Date: Sat, 14 Feb 2015 20:38:56 +0000 Subject: [issue23457] make test failures In-Reply-To: <1423795676.28.0.704579624562.issue23457@psf.upfronthosting.co.za> Message-ID: <1423946336.02.0.00205502483527.issue23457@psf.upfronthosting.co.za> David Edelsohn added the comment: The Python testsuite does not produce completely clean results on AIX. You can see the AIX tester for comparison. Some are caused by assumptions in the testcases that are correct for Linux but not for some Unix systems, and some are caused by incorrect behavior of corner cases in AIX system libraries. Python works on AIX and should work for your purposes to build Firefox. I don't understand why you think that the problems must be fixed for you to make progress on your project. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 21:49:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 20:49:35 +0000 Subject: [issue22844] test_gdb failure on Debian Wheezy for Z In-Reply-To: <1415670788.7.0.445632155994.issue22844@psf.upfronthosting.co.za> Message-ID: <20150214204926.60736.10976@psf.io> Roundup Robot added the comment: New changeset ae5d868513fd by Serhiy Storchaka in branch '3.4': Issue #22844: Fized test_gdb failure on Debian Wheezy for Z. https://hg.python.org/cpython/rev/ae5d868513fd New changeset df696b544b3c by Serhiy Storchaka in branch 'default': Issue #22844: Fized test_gdb failure on Debian Wheezy for Z. https://hg.python.org/cpython/rev/df696b544b3c New changeset eb3a6243af33 by Serhiy Storchaka in branch '2.7': Issue #22844: Fized test_gdb failure on Debian Wheezy for Z. https://hg.python.org/cpython/rev/eb3a6243af33 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 22:18:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 21:18:00 +0000 Subject: [issue17753] test_zipfile: requires write access to test and email.test In-Reply-To: <1366109637.36.0.807884734436.issue17753@psf.upfronthosting.co.za> Message-ID: <20150214211754.62575.62584@psf.io> Roundup Robot added the comment: New changeset 6ad5909319e0 by Serhiy Storchaka in branch '3.4': Issue #17753: Skip test_zipfile tests which require write access to test https://hg.python.org/cpython/rev/6ad5909319e0 New changeset 174f24d33bfe by Serhiy Storchaka in branch 'default': Issue #17753: Skip test_zipfile tests which require write access to test https://hg.python.org/cpython/rev/174f24d33bfe New changeset dfe75713f152 by Serhiy Storchaka in branch '2.7': Issue #17753: Skip test_zipfile tests which require write access to test https://hg.python.org/cpython/rev/dfe75713f152 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:01:45 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 22:01:45 +0000 Subject: [issue12639] msilib Directory.start_component() fails if keyfile is not None In-Reply-To: <1311611007.28.0.321431208072.issue12639@psf.upfronthosting.co.za> Message-ID: <1423951305.12.0.263880917675.issue12639@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Steve can you take a look at the patch please, it only changes one line. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:02:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 22:02:32 +0000 Subject: [issue23233] TypeError in ./setup.py In-Reply-To: <1421180295.13.0.16794585619.issue23233@psf.upfronthosting.co.za> Message-ID: <1423951352.7.0.947388063262.issue23233@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It was old _sysconfigdata.py in the Lib/ directory. Now it is generated in build directory (build/lib.linux-i686-3.5 in my case). All works after removing Lib/_sysconfigdata.py. This issue may be considered as misconfiguration. No fix needed. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:05:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 22:05:39 +0000 Subject: [issue13637] binascii.a2b_* functions could accept unicode strings In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za> Message-ID: <20150214220535.72269.47734@psf.io> Roundup Robot added the comment: New changeset 8d32453dd0f7 by Berker Peksag in branch '3.4': Issue #13637: Remove outdated versionchanged directives. https://hg.python.org/cpython/rev/8d32453dd0f7 New changeset d3ca674cf716 by Berker Peksag in branch 'default': Issue #13637: Remove outdated versionchanged directives. https://hg.python.org/cpython/rev/d3ca674cf716 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:06:11 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 22:06:11 +0000 Subject: [issue12239] msilib VT_EMPTY SummaryInformation properties raise an error (suggest returning None) In-Reply-To: <1307024024.44.0.716968870376.issue12239@psf.upfronthosting.co.za> Message-ID: <1423951571.74.0.00678409503413.issue12239@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can we have a patch review please. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:12:49 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 22:12:49 +0000 Subject: [issue21898] .hgignore: Missing ignores for Eclipse/pydev In-Reply-To: <1404223695.39.0.861504959592.issue21898@psf.upfronthosting.co.za> Message-ID: <1423951969.64.0.153093977925.issue21898@psf.upfronthosting.co.za> Mark Lawrence added the comment: Could someone review the patch please. It simply adds the three lines to the .hgignore file that are listed in msg222032. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:21:55 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 14 Feb 2015 22:21:55 +0000 Subject: [issue9740] Support for HTTP 1.1 persistent connections throughout the standard library In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za> Message-ID: <1423952515.7.0.257644002083.issue9740@psf.upfronthosting.co.za> Martin Panter added the comment: Opened Issue 23377 about losing the buffer at the end of a response ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:31:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 22:31:08 +0000 Subject: [issue13637] binascii.a2b_* functions could accept unicode strings In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za> Message-ID: <20150214223054.126618.96491@psf.io> Roundup Robot added the comment: New changeset ad4a8176a71a by Berker Peksag in branch '3.4': Issue #13637: Improve exception message of a2b_* functions. https://hg.python.org/cpython/rev/ad4a8176a71a New changeset 55f5e960cc40 by Berker Peksag in branch 'default': Issue #13637: Improve exception message of a2b_* functions. https://hg.python.org/cpython/rev/55f5e960cc40 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:33:10 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 22:33:10 +0000 Subject: [issue13637] binascii.a2b_* functions could accept unicode strings In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za> Message-ID: <1423953190.23.0.52347467197.issue13637@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you to both Vajrasky and Martin. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:45:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Feb 2015 22:45:31 +0000 Subject: [issue22003] BytesIO copy-on-write In-Reply-To: <1405635937.15.0.406925083031.issue22003@psf.upfronthosting.co.za> Message-ID: <20150214224525.60720.19415@psf.io> Roundup Robot added the comment: New changeset 7ae156f07a90 by Berker Peksag in branch 'default': Add a whatsnew entry for issue #22003. https://hg.python.org/cpython/rev/7ae156f07a90 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:47:15 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 22:47:15 +0000 Subject: [issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <1423954035.01.0.814227345777.issue15381@psf.upfronthosting.co.za> Berker Peksag added the comment: Can this be closed now? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:51:27 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 22:51:27 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1423954287.63.0.223501496318.issue22107@psf.upfronthosting.co.za> Mark Lawrence added the comment: changeset 035b61b52caa has this:- return (fd, _os.path.abspath(file)) except FileExistsError: continue # try again + except PermissionError: + # This exception is thrown when a directory with the chosen name + # already exists on windows. + if _os.name == 'nt': + continue + else: + raise raise FileExistsError(_errno.EEXIST, "No usable temporary file name found") Could we simply set a flag saying it's a PermissionError and then raise the appropriate PermissionError or FileExistsError at the end of the loop? ---------- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 14 23:55:43 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 22:55:43 +0000 Subject: [issue22035] Fatal error in dbm.gdbm In-Reply-To: <1406024440.03.0.44171364302.issue22035@psf.upfronthosting.co.za> Message-ID: <1423954543.23.0.363747269745.issue22035@psf.upfronthosting.co.za> Mark Lawrence added the comment: Would somebody please review Serhiy's patch. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:00:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 23:00:29 +0000 Subject: [issue17753] test_zipfile: requires write access to test and email.test In-Reply-To: <1366109637.36.0.807884734436.issue17753@psf.upfronthosting.co.za> Message-ID: <1423954829.44.0.0150648034254.issue17753@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:00:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 23:00:46 +0000 Subject: [issue22844] test_gdb failure on Debian Wheezy for Z In-Reply-To: <1415670788.7.0.445632155994.issue22844@psf.upfronthosting.co.za> Message-ID: <1423954846.37.0.0901250122012.issue22844@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:01:09 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 23:01:09 +0000 Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid port values? In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za> Message-ID: <1423954869.07.0.523852355177.issue20059@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:03:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 23:03:50 +0000 Subject: [issue22035] Fatal error in dbm.gdbm In-Reply-To: <1406024440.03.0.44171364302.issue22035@psf.upfronthosting.co.za> Message-ID: <1423955030.38.0.758353338627.issue22035@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, Mark, please stop shaking up bug tracker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:05:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Feb 2015 23:05:25 +0000 Subject: [issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <1423955125.48.0.690507285305.issue15381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, I'm working on more advanced patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:09:07 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 23:09:07 +0000 Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch exiting exceptions In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za> Message-ID: <1423955347.49.0.202540859856.issue23430@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:13:55 2015 From: report at bugs.python.org (Brian Curtin) Date: Sat, 14 Feb 2015 23:13:55 +0000 Subject: [issue12239] msilib VT_EMPTY SummaryInformation properties raise an error (suggest returning None) In-Reply-To: <1307024024.44.0.716968870376.issue12239@psf.upfronthosting.co.za> Message-ID: <1423955635.64.0.115798865412.issue12239@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:17:11 2015 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 14 Feb 2015 23:17:11 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1423955831.32.0.855872495473.issue23465@psf.upfronthosting.co.za> Vinay Sajip added the comment: The patch looks good to me, too. The standalone launcher has basic tests: https://bitbucket.org/pypa/pylauncher/src/4613e10e26a8ca98d4fa4609c6659ef6b623baef/tests.py?at=default To do a proper job, you need to have multiple Pythons installed, ideally 32- and 64-bit - so it's not really a job for the standard Python test suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:29:26 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 14 Feb 2015 23:29:26 +0000 Subject: [issue12639] msilib Directory.start_component() fails if keyfile is not None In-Reply-To: <1311611007.28.0.321431208072.issue12639@psf.upfronthosting.co.za> Message-ID: <1423956566.7.0.0563385298497.issue12639@psf.upfronthosting.co.za> Steve Dower added the comment: I guess it's okay, but I have literally zero knowledge or experience with the msilib module. Martin is still maintainer for that, as far as I know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:34:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 14 Feb 2015 23:34:03 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <1423956843.6.0.229350993969.issue23400@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Davin. I left a couple of comments on Rietveld. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 00:44:13 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 14 Feb 2015 23:44:13 +0000 Subject: [issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <1423957453.68.0.690277036559.issue15381@psf.upfronthosting.co.za> Mark Lawrence added the comment: Oh, Berker, please stop shaking up bug tracker. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 01:12:09 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 00:12:09 +0000 Subject: [issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__ In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za> Message-ID: <1423959129.96.0.94808466869.issue4395@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 21408 has been committed to 3.4 and 3.5 branches, so my patch can now be considered to document the newly fixed behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 01:18:02 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 00:18:02 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1423959482.21.0.690758355848.issue1508475@psf.upfronthosting.co.za> Martin Panter added the comment: I suggest resolving Issue 15955 first, then the GzipFile API could be used without fear of decompression bombs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 02:26:33 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 01:26:33 +0000 Subject: [issue21257] Document parse_headers function of http.client In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za> Message-ID: <1423963593.87.0.646795119497.issue21257@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 23439, about updating __all__ (or not updating __all__, as it seems to be turning into) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 02:45:50 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Feb 2015 01:45:50 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1423964750.83.0.262368493278.issue23458@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +0 This seems like a reasonable change with some upside and no obvious downside. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 02:59:12 2015 From: report at bugs.python.org (Dwight) Date: Sun, 15 Feb 2015 01:59:12 +0000 Subject: [issue23457] make test failures In-Reply-To: <1423795676.28.0.704579624562.issue23457@psf.upfronthosting.co.za> Message-ID: <1423965552.12.0.342620380051.issue23457@psf.upfronthosting.co.za> Dwight added the comment: Thanks for the response. What is the "AIX tester"? Appreciate the explanation of what might be causing the problem. I do have at least three other version of python installed on my AIX 7.1 system. Have no idea if these versions produced "test" errors. These version of python were supplied to me. The only reason I am trying to create a new version of python is because when I tried to build a gnome module which is required to build gtk+ is did not like any of the version of python that I have installed. The only reason that I am asking about these test failures is because I have no idea if they will cause problems in all my follow on builds. firefox acts funny in AIX (maybe other UNIX builds)! Somewhere in the final linked module there are bugs that can cause firefox to hang. Just wanted to make sure everything up to the point before the build of firefox is OK. As you probably know mozilla will not provide any support in my efforts to build a working firefox. (Not sure I can even build a working version. Definitely not a C++ programmer and am just a novice C programmer. Need to eliminate all possible of errors I can.) I really need a working browser. (I have an open PMR with AIX support because firefox can not access the online documentation for AIX. Just great. Documentation is only available online and I can not get to it. AIX support say they do not support firefox so it my fault I can not access the online documentation.) I guess I could just install python and continue trying to build firefox. Oh! By the way. Do you know if when I install this version of pyhton the gmake install will remove the older version of pyhton? Not talking about the AIX or Linux toolkit version; but the one that is installed in the directory where I will be installing this version of python. Appreciate the help! Dwight ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 03:33:24 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 02:33:24 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1423967604.78.0.326167430674.issue23439@psf.upfronthosting.co.za> Martin Panter added the comment: Posting a new patch which explicitly omits HTTPMessage, parse_headers(), and the status codes. Also added and documented the LineTooLong exception. It is already somewhat covered in the test suite. See also Issue 21257 about the status of parse_headers(). ---------- Added file: http://bugs.python.org/file38140/http.client-all.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 05:00:28 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 04:00:28 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes In-Reply-To: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> Message-ID: <1423972828.81.0.174916601973.issue23410@psf.upfronthosting.co.za> Martin Panter added the comment: Posting another patch which hopefully explains the ?requestline? attribute a bit better. Let me know if you have any ideas for better wording. ---------- Added file: http://bugs.python.org/file38141/http-attributes.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 05:26:24 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 04:26:24 +0000 Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za> Message-ID: <1423974384.08.0.670022028597.issue5054@psf.upfronthosting.co.za> Martin Panter added the comment: Posting a patch for this so that we can get rid of the broken HTTPMessage.getallmatchingheaders() method in Issue 5053. ---------- keywords: +patch nosy: +vadmium Added file: http://bugs.python.org/file38142/cgi-accept.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 05:34:53 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 04:34:53 +0000 Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za> Message-ID: <1423974893.34.0.658996246846.issue5054@psf.upfronthosting.co.za> Martin Panter added the comment: BTW in the original code, I think line[:1] in "\t\n\r " might have been correct. It looks like the getallmatchinheaders() method was actually meant to return continued lines separately, prefixed with whitespace. My patch is probably only appropriate for Python 3; maybe Mike?s code will work for Python 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 05:58:10 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 04:58:10 +0000 Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns [] In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za> Message-ID: <1423976290.42.0.353043366804.issue5053@psf.upfronthosting.co.za> Martin Panter added the comment: Posting a patch to remove the entire HTTPMessage class. This assumes my patch for Issue 5054 is accepted, which will remove the only existing reference to getallmatchingheaders(). ---------- Added file: http://bugs.python.org/file38143/remove-HTTPMessage.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 06:22:12 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 05:22:12 +0000 Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch exiting exceptions In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za> Message-ID: <1423977732.02.0.475784274219.issue23430@psf.upfronthosting.co.za> Martin Panter added the comment: Looking at this again, I think I should make the forking server?s handle_error() method only be called for Exception subclasses as well. So I am posting a new patch that also does this. ---------- Added file: http://bugs.python.org/file38144/socketserver-exit.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 06:51:28 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 15 Feb 2015 05:51:28 +0000 Subject: [issue21387] Memory leaks when embedded interpreter is reinitialized In-Reply-To: <1398772537.74.0.909134635776.issue21387@psf.upfronthosting.co.za> Message-ID: <1423979488.81.0.863256681469.issue21387@psf.upfronthosting.co.za> Nick Coghlan added the comment: For the record, the open issues about applying 3121 and 384 to the standard libary: http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=pep+3121&submit=search&status=-1%2C1%2C3 ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 06:58:27 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 05:58:27 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1423979907.38.0.188212360891.issue12319@psf.upfronthosting.co.za> Martin Panter added the comment: One interesting question is how to convey data to the chunked encoder. There are two sets of options in my mind, a pull interface: * iterable: seems to be the popular way amoung commenters here * file reader object: encoder calls into stream?s read() method and a push interface: * chunked encoder is a file writer object: user calls encoder?s write() and close() methods. This would suit APIs like saxutils.XMLGenerator and TextIOWrapper. * chunked encoder has a ?feed parser? interface, codecs.IncrementalEncoder interface, or something else. The advantage of the push interface is that you could fairly easily feed data from an iterable or file reader into it simply by just doing shutil.copyfileobj() or equivalent. But to adapt the pull interface to a push interface would require ?asyncio? support or a separate thread or something to invert the flow of control. So I think building the encoder with a push interface would be best. Rolf?s ChunkedHTTPConnectionMixin class appears to only support the pull interface (iterables and stream readers). I would welcome support for chunked uploading in Python?s ?http.client? module, especially with push or stream writer support. I don?t think overwriting _send_request should be necessary; just call putrequest(), putheader() etc manually, and then call send() for each chunk. Perhaps there is scope for sharing the code with the ?http.server? module (for encoding chunked responses). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 07:02:10 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 15 Feb 2015 06:02:10 +0000 Subject: [issue22633] Memory disclosure/buffer overread via bug in Py_FrozenMain In-Reply-To: <1413311714.85.0.507321102423.issue22633@psf.upfronthosting.co.za> Message-ID: <1423980130.82.0.232915708536.issue22633@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 08:31:08 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 15 Feb 2015 07:31:08 +0000 Subject: [issue23452] Build errors using VS Express 2013 in win32 mode In-Reply-To: <1423723559.86.0.395515662536.issue23452@psf.upfronthosting.co.za> Message-ID: <1423985468.24.0.36199999933.issue23452@psf.upfronthosting.co.za> Mark Lawrence added the comment: Having run the "hg purge..." command previously given everything seemed fine. Both release and debug win32 builds then successfully completed from VS but the 64 bit builds failed. I now have externals/tcltk but not externals/tcltk64. I did a bit of digging and in tcltk.props there are these two lines which appear relevant. $(ExternalsDir)tcltk\ $(ExternalsDir)tcltk64\ I'm now way out of my depth and hoping this isn't a red herring. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 08:38:38 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 15 Feb 2015 07:38:38 +0000 Subject: [issue19050] crash while writing to a closed file descriptor In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za> Message-ID: <1423985918.03.0.258369095398.issue19050@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is this still an issue with later versions of 2.7? I'm sorry, I can't try this myself as I no longer run 2.7. ---------- nosy: +BreamoreBoy, steve.dower, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 08:54:58 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 15 Feb 2015 07:54:58 +0000 Subject: [issue16361] HTTPS/TLS Problem in Python 3.3 In-Reply-To: <1351551122.11.0.0678496091034.issue16361@psf.upfronthosting.co.za> Message-ID: <1423986898.39.0.182251915473.issue16361@psf.upfronthosting.co.za> Mark Lawrence added the comment: On Windows 3.4.2 ssl.OPENSSL_VERSION is 'OpenSSL 1.0.1i 6 Aug 2014' and 3.5 is currently being built with 1.0.1l so is there anything that our windows developers need to do here with 3.3? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 10:03:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 09:03:34 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1423991014.86.0.743088851458.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What exceptions are raised on Windows when try to open a file in bad directory? open('foo').close() open('foo/bar') # what raised? open('nonexistent/bar') # what raised? If raised the same exceptions as on Linux, then perhaps the following patch fixes this issue. ---------- keywords: +patch nosy: +serhiy.storchaka stage: -> patch review Added file: http://bugs.python.org/file38145/tempfile_bad_tempdir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 10:13:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 09:13:25 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1423991605.88.0.632649028813.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And what returns os.access for writable directories and non-existent files? os.mkdir('dir') os.access('dir', os.W_OK) # what returns? os.access('nonexistent', os.W_OK) # what returns or raises? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 10:36:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 09:36:30 +0000 Subject: [issue16124] fcntl_ioctl still not 100% sane with unsigned longs In-Reply-To: <1349322414.95.0.371484313067.issue16124@psf.upfronthosting.co.za> Message-ID: <1423992990.59.0.284340545264.issue16124@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks as a duplicate of issue521723 and issue1471. Do you have tests that demonstrate a failure with using ioctl on OpenBSD? May be there are problems on 64-bit big-endian platforms (or even on 64-bit little-endian if additional parameters are passed to ioctl). ---------- nosy: +gregory.p.smith, loewis, serhiy.storchaka stage: -> test needed versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 10:57:46 2015 From: report at bugs.python.org (Garrett Cooper) Date: Sun, 15 Feb 2015 09:57:46 +0000 Subject: [issue16124] fcntl_ioctl still not 100% sane with unsigned longs In-Reply-To: <1349322414.95.0.371484313067.issue16124@psf.upfronthosting.co.za> Message-ID: <1423994266.33.0.0720285565896.issue16124@psf.upfronthosting.co.za> Garrett Cooper added the comment: Yes, it's a duplicate. That being said, documentation alone it should be unsigned long for Darwin (OS/X), FreeBSD, OpenBSD. Looking at the definition for ioctl(2), the below example would cause a failure. I need to hunt around for a practical example as I don't have one offhand (it's something that was found a long time ago in a couple of python 2.6 at my current employer because they have ioctl's that go beyond the 32-bit boundary IIRC...) fuji:~ ngie$ clang -Wall -c test_ioctl.c fuji:~ ngie$ clang -DBROKEN -Wall -c test_ioctl.c test_ioctl.c:9:9: warning: incompatible pointer types initializing 'ioctl_t' (aka 'int (*)(int, int, ...)') with an expression of type 'int (int, unsigned long, ...)' [-Wincompatible-pointer-types] ioctl_t _ioctl = ioctl; ^ ~~~~~ 1 warning generated. fuji:~ ngie$ cat test_ioctl.c #include #ifdef BROKEN typedef int (*ioctl_t)(int, int, ...); #else typedef int (*ioctl_t)(int, unsigned long, ...); #endif ioctl_t _ioctl = ioctl; fuji:~ ngie$ uname -a Darwin fuji.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Dec 17 19:05:52 PST 2014; root:xnu-2422.115.10~1/RELEASE_X86_64 x86_64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 11:00:39 2015 From: report at bugs.python.org (Garrett Cooper) Date: Sun, 15 Feb 2015 10:00:39 +0000 Subject: [issue16124] fcntl_ioctl still not 100% sane with unsigned longs In-Reply-To: <1349322414.95.0.371484313067.issue16124@psf.upfronthosting.co.za> Message-ID: <1423994439.81.0.0966235979306.issue16124@psf.upfronthosting.co.za> Garrett Cooper added the comment: Another note: mixed endianness might have been a factor as previous versions of the product that were shipped used bi-arch x86 (32-bit userland on 64-bit kernel. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 11:34:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 10:34:18 +0000 Subject: [issue21934] OpenBSD has no /dev/full device In-Reply-To: <1404747013.93.0.393614299649.issue21934@psf.upfronthosting.co.za> Message-ID: <1423996458.95.0.608132465331.issue21934@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 12:26:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Feb 2015 11:26:50 +0000 Subject: [issue21934] OpenBSD has no /dev/full device In-Reply-To: <1404747013.93.0.393614299649.issue21934@psf.upfronthosting.co.za> Message-ID: <20150215112645.71234.18343@psf.io> Roundup Robot added the comment: New changeset 354c3b65e245 by Serhiy Storchaka in branch '2.7': Issue #21934: test_file2k no longer create regular file /dev/full on OpenBSD https://hg.python.org/cpython/rev/354c3b65e245 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 13:05:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 12:05:02 +0000 Subject: [issue21849] Fix multiprocessing for non-ascii data In-Reply-To: <1403595158.76.0.418417977176.issue21849@psf.upfronthosting.co.za> Message-ID: <1424001902.0.0.837926379161.issue21849@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: -Fix unicodeless build of Python resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 13:07:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 12:07:12 +0000 Subject: [issue23408] Pickle tests use incorrect test data In-Reply-To: <1423386346.84.0.92397011471.issue23408@psf.upfronthosting.co.za> Message-ID: <1424002032.25.0.432200946843.issue23408@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 13:07:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 12:07:42 +0000 Subject: [issue23096] Implementation-depended pickling floats with protocol 0 In-Reply-To: <1419149433.29.0.802482425543.issue23096@psf.upfronthosting.co.za> Message-ID: <1424002062.98.0.940339960372.issue23096@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 13:08:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 12:08:41 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <1424002121.54.0.784767903647.issue23374@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 13:34:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Feb 2015 12:34:41 +0000 Subject: [issue23096] Implementation-depended pickling floats with protocol 0 In-Reply-To: <1419149433.29.0.802482425543.issue23096@psf.upfronthosting.co.za> Message-ID: <20150215123416.71238.37340@psf.io> Roundup Robot added the comment: New changeset 8c9121993eb5 by Serhiy Storchaka in branch 'default': Issue #23096: Pickle representation of floats with protocol 0 now is the same https://hg.python.org/cpython/rev/8c9121993eb5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 13:34:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 12:34:53 +0000 Subject: [issue23408] Pickle tests use incorrect test data In-Reply-To: <1423386346.84.0.92397011471.issue23408@psf.upfronthosting.co.za> Message-ID: <1424003693.52.0.910932203673.issue23408@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed in d92a067464a0 and 3e4ed1a23cfc. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 13:35:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 12:35:43 +0000 Subject: [issue23096] Implementation-depended pickling floats with protocol 0 In-Reply-To: <1419149433.29.0.802482425543.issue23096@psf.upfronthosting.co.za> Message-ID: <1424003743.7.0.361608244938.issue23096@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 13:59:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 12:59:01 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <1424005141.28.0.427683667142.issue23374@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added a test. ---------- Added file: http://bugs.python.org/file38146/pydoc_encoding_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 14:00:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 13:00:00 +0000 Subject: [issue23146] Incosistency in pathlib between / and \ In-Reply-To: <1420191625.18.0.999730856462.issue23146@psf.upfronthosting.co.za> Message-ID: <1424005200.92.0.515413126758.issue23146@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 14:10:20 2015 From: report at bugs.python.org (Rolf Krahl) Date: Sun, 15 Feb 2015 13:10:20 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1424005820.11.0.824852415466.issue12319@psf.upfronthosting.co.za> Rolf Krahl added the comment: The design goal for my implementation was compatibility. My version can be used as a drop in replacement for the existing urllib's HTTPHandler. The only thing that need to be changed in the calling code is that it must call build_opener() to select the chunked handler in the place of the default HTTPHandler. After this, the calling code can use the returned opener in the very same way as usual. I guess, switching to a push interface would require major changes in the calling code. In principle, you could certainly support both schemes at the same time: you could change the internal design to a push interface and than wrap this by a pull interface for the compatibility with existing code. But I'm not sure whether this would be worth the effort. If, as Piotr suggests, the current urllib is going to be replaced by urllib3, then I guess, its questionable if it makes sense to add major design changes that are incompatible with existing code to the current standard lib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 14:23:54 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 15 Feb 2015 13:23:54 +0000 Subject: [issue23452] Build errors using VS Express 2013 in win32 mode In-Reply-To: <1423723559.86.0.395515662536.issue23452@psf.upfronthosting.co.za> Message-ID: <1424006634.26.0.810291742896.issue23452@psf.upfronthosting.co.za> Steve Dower added the comment: There's nothing wrong with that line, it's probably the Tk or Tcl build failing. Zach may have some ideas, or I'll play with it some more in the next few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 15:05:43 2015 From: report at bugs.python.org (Tim Golden) Date: Sun, 15 Feb 2015 14:05:43 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424009143.15.0.5852465942.issue23465@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- components: +Windows nosy: +tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 15:12:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 14:12:07 +0000 Subject: [issue5700] io.FileIO calls flush() after file closed In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za> Message-ID: <1424009527.76.0.390507152661.issue5700@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added comments as Antoine suggested. ---------- versions: +Python 2.7 Added file: http://bugs.python.org/file38147/fileio_flush_closed_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 15:16:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 14:16:11 +0000 Subject: [issue5700] io.FileIO calls flush() after file closed In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za> Message-ID: <1424009771.84.0.946985301395.issue5700@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And here is a patch for 2.7. ---------- Added file: http://bugs.python.org/file38148/fileio_flush_closed-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 15:22:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Feb 2015 14:22:56 +0000 Subject: [issue19681] test_repr (test.test_functools.TestPartialC) failures In-Reply-To: <1385044476.32.0.977131973544.issue19681@psf.upfronthosting.co.za> Message-ID: <20150215142248.62563.53937@psf.io> Roundup Robot added the comment: New changeset 138c2afd9f1f by Serhiy Storchaka in branch '3.4': Issue #19681: Test the repr of partial with more than one keyword argument. https://hg.python.org/cpython/rev/138c2afd9f1f New changeset 6f80e8bcb5ad by Serhiy Storchaka in branch 'default': Issue #19681: Test the repr of partial with more than one keyword argument. https://hg.python.org/cpython/rev/6f80e8bcb5ad ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 15:24:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 14:24:28 +0000 Subject: [issue19681] test_repr (test.test_functools.TestPartialC) failures In-Reply-To: <1385044476.32.0.977131973544.issue19681@psf.upfronthosting.co.za> Message-ID: <1424010268.94.0.805952991432.issue19681@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 15:35:18 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Feb 2015 14:35:18 +0000 Subject: [issue21934] OpenBSD has no /dev/full device In-Reply-To: <1404747013.93.0.393614299649.issue21934@psf.upfronthosting.co.za> Message-ID: <1424010918.0.0.736442793536.issue21934@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why the complication? You could just use open mode "r+". ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 15:37:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 14:37:58 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1424011078.97.0.473505133089.issue15178@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Doctest still failed with backtrace if argument is a file name. $ ./python -m doctest aaa.py Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/serhiy/py/cpython/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/serhiy/py/cpython/Lib/doctest.py", line 2795, in sys.exit(_test()) File "/home/serhiy/py/cpython/Lib/doctest.py", line 2773, in _test m = __import__(filename[:-3]) ImportError: No module named 'aaa' It would be good to have tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 15:44:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 14:44:03 +0000 Subject: [issue21934] OpenBSD has no /dev/full device In-Reply-To: <1404747013.93.0.393614299649.issue21934@psf.upfronthosting.co.za> Message-ID: <1424011443.05.0.958370988257.issue21934@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This was my first idea. But this would be different test. The behavior of files opened with "w" and "r+" modes can be different. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 16:27:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 15:27:43 +0000 Subject: [issue6639] turtle: _tkinter.TclError: invalid command name ".10170160" In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za> Message-ID: <1424014063.19.0.0979550425441.issue6639@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 16:45:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 15:45:04 +0000 Subject: [issue6639] turtle: _tkinter.TclError: invalid command name ".10170160" In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za> Message-ID: <1424015104.73.0.00531012544583.issue6639@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 17:09:18 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 15 Feb 2015 16:09:18 +0000 Subject: [issue20575] Type handling policy for the statistics module In-Reply-To: <1391952583.31.0.349942146298.issue20575@psf.upfronthosting.co.za> Message-ID: <1424016558.15.0.276387109548.issue20575@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Thanks for the note Mark. I need to give Oscar's comments some careful and distraction-free thought, but off the top of my head I think Oscar's suggestion to require consistent types seems reasonable, except that mixing int with any other type should be allowed. Otherwise, I think that the coercion rules for mixed float/Decimal/Fraction rapidly become intractable. ---------- assignee: -> steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 17:28:32 2015 From: report at bugs.python.org (Brian Curtin) Date: Sun, 15 Feb 2015 16:28:32 +0000 Subject: [issue19050] crash while writing to a closed file descriptor In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za> Message-ID: <1424017712.47.0.896084494108.issue19050@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 17:54:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 16:54:19 +0000 Subject: [issue22687] horrible performance of textwrap.wrap() with a long word In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za> Message-ID: <1424019259.45.0.151599723476.issue22687@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: wordsplit_3.patch is wordsplit_2.patch with few added comments in tests. Is it enough? ---------- Added file: http://bugs.python.org/file38149/wordsplit_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 17:58:13 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 15 Feb 2015 16:58:13 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424019493.65.0.117328773928.issue22107@psf.upfronthosting.co.za> Mark Lawrence added the comment: >>> os.mkdir('dir') >>> os.access('dir', os.W_OK) True >>> os.access('nonexistent', os.W_OK) False >>> open('dir/bar') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'dir/bar' >>> open('nonexistent/bar') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'nonexistent/bar' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 18:05:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 17:05:39 +0000 Subject: [issue23215] MemoryError with custom error handlers and multibyte codecs In-Reply-To: <1420860783.67.0.50434618074.issue23215@psf.upfronthosting.co.za> Message-ID: <1424019939.01.0.491129415779.issue23215@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 18:07:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Feb 2015 17:07:14 +0000 Subject: [issue23146] Incosistency in pathlib between / and \ In-Reply-To: <1420191625.18.0.999730856462.issue23146@psf.upfronthosting.co.za> Message-ID: <20150215170700.62555.37082@psf.io> Roundup Robot added the comment: New changeset 0f8f24dab34b by Antoine Pitrou in branch '3.4': Issue #23146: Fix mishandling of absolute Windows paths with forward slashes in pathlib. https://hg.python.org/cpython/rev/0f8f24dab34b New changeset 0de45993c21c by Antoine Pitrou in branch 'default': Issue #23146: Fix mishandling of absolute Windows paths with forward slashes in pathlib. https://hg.python.org/cpython/rev/0de45993c21c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 18:07:32 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Feb 2015 17:07:32 +0000 Subject: [issue23146] Incosistency in pathlib between / and \ In-Reply-To: <1420191625.18.0.999730856462.issue23146@psf.upfronthosting.co.za> Message-ID: <1424020052.85.0.902267599217.issue23146@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 18:08:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 17:08:59 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424020139.63.0.00774876309877.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Mark. Could you please make first test in msg236028 (when first part of the path is a file, not a directory)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 18:13:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Feb 2015 17:13:17 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <20150215171226.62581.73659@psf.io> Roundup Robot added the comment: New changeset b15a5f239e8a by Antoine Pitrou in branch 'default': Issue #23239: ssl.match_hostname() now supports matching of IP addresses. https://hg.python.org/cpython/rev/b15a5f239e8a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 18:15:44 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Feb 2015 17:15:44 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1424020544.42.0.592491791322.issue23239@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 18:34:06 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 15 Feb 2015 17:34:06 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424021646.38.0.90142395983.issue22107@psf.upfronthosting.co.za> Mark Lawrence added the comment: >>> open('README').close() >>> open('README/bar') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'README/bar' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 18:36:44 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 15 Feb 2015 17:36:44 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424021804.6.0.396780816608.issue22107@psf.upfronthosting.co.za> Steve Dower added the comment: Is there a difference if you do open(..., 'w')? It's a different enough operation that it may have a different error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 18:45:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 17:45:42 +0000 Subject: [issue23215] MemoryError with custom error handlers and multibyte codecs In-Reply-To: <1420860783.67.0.50434618074.issue23215@psf.upfronthosting.co.za> Message-ID: <1424022342.0.0.525690964237.issue23215@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patch Aleksi. It LGTM in general. Updated patch just moves the test to Lib/test/test_multibytecodec.py where it can reuse ALL_CJKENCODINGS and fixes few other minor bugs in multibyte codecs. ---------- Added file: http://bugs.python.org/file38150/python_codec_crash_fix_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 19:03:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 18:03:14 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424023394.09.0.125931708066.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Is there a difference if you do open(..., 'w')? It's a different enough operation that it may have a different error. Oh, yes, I forgot the 'w' mode. Mark, could you please run following test on Windows? import os open('foo', 'wb').close() flags = os.O_RDWR | os.O_CREAT | os.O_EXCL | getattr(os, 'O_NOFOLLOW', 0) | getattr(os, 'O_BINARY', 0) os.open('foo/bar', flags, 0o600) # what raised? os.open('nonexistent/bar', flags, 0o600) # what raised? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 19:21:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 18:21:46 +0000 Subject: [issue23466] Inconsistency between str and bytes formatting of integers Message-ID: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: PEP 461 says that all numeric bytes formatting codes will work as they do for str. In particular b"%x" % val is equivalent to ("%x" % val).encode("ascii"). But this is wrong with current implementation: >>> '%x' % 3.14 Traceback (most recent call last): File "", line 1, in TypeError: %x format: an integer is required, not float >>> b'%x' % 3.14 b'3' The same is for %X, %o and %c. Raising TypeError on non-integer input to %c, %o, %x, and %X was added in issue19995. ---------- components: Interpreter Core messages: 236056 nosy: ethan.furman, serhiy.storchaka priority: normal severity: normal status: open title: Inconsistency between str and bytes formatting of integers type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 19:33:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 18:33:27 +0000 Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3 Message-ID: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The main motivation of PEP 461 was to help ease migration from, and/or have a single code base with, Python 2. But bytes formatting don't support the %r code supported in Python 2. Instead it supports the %a code which is exactly equivalent to the %r code in Python 2 but doesn't supported in Python 2. So it is not so easy to migrate from or have a single code base with Python 2 it the code uses the %r opcode. As far as bytes formatting supports the %s code (an alias to %b) purely for compatibility with Python 2, it would be good to support the %r as an alias to %a. ---------- components: Interpreter Core messages: 236057 nosy: ethan.furman, gvanrossum, serhiy.storchaka priority: normal severity: normal status: open title: Improve byte formatting compatibility between Py2 and Py3 type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 19:44:58 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 15 Feb 2015 18:44:58 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424025898.83.0.0713691686515.issue22107@psf.upfronthosting.co.za> Mark Lawrence added the comment: >>> open('foo', 'wb').close() >>> flags = os.O_RDWR | os.O_CREAT | os.O_EXCL | getattr(os, 'O_NOFOLLOW', 0) | getattr(os, 'O_BINARY', 0) >>> os.open('foo/bar', flags, 0o600) Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'foo/bar' >>> os.open('nonexistent/bar', flags, 0o600) Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'nonexistent/bar' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 19:46:48 2015 From: report at bugs.python.org (Stoneagee) Date: Sun, 15 Feb 2015 18:46:48 +0000 Subject: [issue23468] ISO 8601 datetime process Message-ID: <1424026008.92.0.265262924683.issue23468@psf.upfronthosting.co.za> New submission from Stoneagee: Code: import dateutil.parser from datetime import datetime a='0001-01-01T00:00:00+02:00' b='1964-01-01T00:00:00+02:00' ia=dateutil.parser.parse(a) ib=dateutil.parser.parse(b) print a print ia print b print ib output: 0001-01-01T00:00:00+02:00 2001-01-01 00:00:00+02:00 1964-01-01T00:00:00+02:00 1964-01-01 00:00:00+02:00 On wiki ISO 8601, under Combined date and time representations: If a time zone designator is required, it follows the combined date and time. For example "2007-04-05T14:30Z" or "2007-04-05T12:30-02:00" I know you may have to fall back template on date such as 1/1/1, but this is ISO and according to my reading, it does not require one. BTW, my input comes from public posted information. Thanks, ---------- messages: 236059 nosy: Stoneagee priority: normal severity: normal status: open title: ISO 8601 datetime process type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 20:03:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 19:03:52 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424027032.58.0.342477935175.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Great. There is only one difference between Windows and Linux, but it affects only error type in tests. Here is a patch with updated test. It should now work on Windows. ---------- Added file: http://bugs.python.org/file38151/tempfile_bad_tempdir_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 20:08:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 19:08:18 +0000 Subject: [issue23468] ISO 8601 datetime process In-Reply-To: <1424026008.92.0.265262924683.issue23468@psf.upfronthosting.co.za> Message-ID: <1424027298.56.0.503471388116.issue23468@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 20:31:00 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 15 Feb 2015 19:31:00 +0000 Subject: [issue23468] ISO 8601 datetime process In-Reply-To: <1424026008.92.0.265262924683.issue23468@psf.upfronthosting.co.za> Message-ID: <1424028660.25.0.596063349688.issue23468@psf.upfronthosting.co.za> SilentGhost added the comment: Perhaps I'm misinterpreting your message, but this doesn't seem like a problem with datetime module. The issue is with dateutil module, which is not the part of the standard library and is not developed here. Also, I can reproduce this issue on 3.4 (though I doubt it's awfully relevant). ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 20:40:24 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 15 Feb 2015 19:40:24 +0000 Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3 In-Reply-To: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za> Message-ID: <1424029224.21.0.668768978777.issue23467@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yeah, we probably got carried away by purity concerns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:00:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Feb 2015 20:00:42 +0000 Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3 In-Reply-To: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za> Message-ID: <1424030442.31.0.168708679579.issue23467@psf.upfronthosting.co.za> STINNER Victor added the comment: "As far as bytes formatting supports the %s code (an alias to %b) purely for compatibility with Python 2, it would be good to support the %r as an alias to %a." I don't like this idea. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:01:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Feb 2015 20:01:30 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1424030490.99.0.3870751593.issue23466@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Inconsistency between str and bytes formatting of integers -> PEP 461: Inconsistency between str and bytes formatting of integers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:08:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Feb 2015 20:08:27 +0000 Subject: [issue22211] Remove VMS specific code in expat.h & xmlrole.h In-Reply-To: <1408222450.15.0.0579194114943.issue22211@psf.upfronthosting.co.za> Message-ID: <1424030907.51.0.800622141775.issue22211@psf.upfronthosting.co.za> STINNER Victor added the comment: Modules/expat is not a copy of a module hosted somewhere else? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:13:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Feb 2015 20:13:49 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1424031229.8.0.465244850911.issue21998@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: asyncio: a new self-pipe should be created in the child process after fork -> asyncio: support fork _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:16:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Feb 2015 20:16:12 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1424031372.01.0.0344364845357.issue21998@psf.upfronthosting.co.za> STINNER Victor added the comment: Can someone review at_fork-2.patch? Martin: Can you please try my patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:19:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Feb 2015 20:19:18 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1424031558.89.0.946100858303.issue18932@psf.upfronthosting.co.za> STINNER Victor added the comment: @Giampaolo: I'm not sure that I understood your proposition? Can you please write a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:19:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Feb 2015 20:19:39 +0000 Subject: [issue22087] asyncio: support multiprocessing (support fork=) In-Reply-To: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za> Message-ID: <1424031579.41.0.63344309933.issue22087@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: asyncio: support multiprocessing -> asyncio: support multiprocessing (support fork=) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:19:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Feb 2015 20:19:43 +0000 Subject: [issue22087] asyncio: support multiprocessing (support fork) In-Reply-To: <1406397670.19.0.283234608675.issue22087@psf.upfronthosting.co.za> Message-ID: <1424031583.02.0.790774898181.issue22087@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: asyncio: support multiprocessing (support fork=) -> asyncio: support multiprocessing (support fork) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:23:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Feb 2015 20:23:20 +0000 Subject: [issue19050] crash while writing to a closed file descriptor In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za> Message-ID: <1424031800.16.0.951634420057.issue19050@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'm sorry, I can't try this myself as I no longer run 2.7. You should install Python 2.7 if you want to work on Python 2.7 only issue. It's not so hard to install Python, especially on Windows (this issue looks to be specific to Windows). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 21:28:09 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 15 Feb 2015 20:28:09 +0000 Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3 In-Reply-To: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za> Message-ID: <1424032089.62.0.129143217271.issue23467@psf.upfronthosting.co.za> Ethan Furman added the comment: Sometimes practicality wins; it's why we allow %s, and we should also allow %r. Both %s and %r need to be clearly documented as an aid to Py2/3 code bases, and not recommended for new code. Serhiy, do you have time to take of this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 22:00:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 21:00:03 +0000 Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3 In-Reply-To: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za> Message-ID: <1424034003.6.0.370867604878.issue23467@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The implementation is easy -- just add "case 'r':" before "case 'a':". The hard (to me) part is the documentation, so that I'm out of the game. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 22:05:59 2015 From: report at bugs.python.org (David Edelsohn) Date: Sun, 15 Feb 2015 21:05:59 +0000 Subject: [issue23457] make test failures In-Reply-To: <1423795676.28.0.704579624562.issue23457@psf.upfronthosting.co.za> Message-ID: <1424034359.06.0.612304917148.issue23457@psf.upfronthosting.co.za> David Edelsohn added the comment: When you configure Python, you can specify an installation directory, which defaults to /usr/local. "make install" will overwrite the Python installation in the specified (possibly default) installation location, but not versions installed in other locations on the systems. The focus of AIX is as a server system, not a deskside system with a graphical user interface. AIX also has many differences from Linux and other SVR4 systems in the way that libraries and shared libraries are built and linked. Firefox is a very complicated application and I doubt that you will have a lot of success building and running it on AIX. If you really need Firefox web browser on your AIX desktop, I strongly suggest that you run Firefox on another system and use the "display" option to instruct the window to appear on the AIX X Window System. In other words, you can have the web browser appear on the AIX system display without running the web browser on the AIX system. If you need access to local files, you can mount the AIX filesystems on the remote system running the web browser. The Python testsuite errors probably are not the cause of your Firefox build problems. And fixing Python or trying to build Firefox on AIX probably are not effective use of your time and not the best way to solve the real problem of access to a web browser on an AIX display. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 22:15:38 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 15 Feb 2015 21:15:38 +0000 Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3 In-Reply-To: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za> Message-ID: <1424034938.04.0.510175589997.issue23467@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- assignee: -> ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 22:25:33 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 15 Feb 2015 21:25:33 +0000 Subject: [issue23440] Extend http.server.SimpleHTTPRequestHandler testing In-Reply-To: <1423640571.78.0.653754704207.issue23440@psf.upfronthosting.co.za> Message-ID: <1424035533.77.0.750694118042.issue23440@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 22:31:55 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 15 Feb 2015 21:31:55 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za> Message-ID: <1424035915.31.0.156723174627.issue18932@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Attached is a patch (for epoll only) which updates the SelectorKey. This introduces a considerable slowdown compared to my first patch: no patch: 16.2 usec per loop your patch: 12.4 usec per loop my patch: 10.9 usec per loop first patch: 3.07 usec per loop The culprit is the new nameduple's _replace() call. It's a shame a single line adds such a great slowdown. I think it makes sense to investigate whether we can introduce a faster replace mechanism for namedtuple. ---------- nosy: +rhettinger Added file: http://bugs.python.org/file38152/epoll.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 23:19:45 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 15 Feb 2015 22:19:45 +0000 Subject: [issue23468] ISO 8601 datetime process In-Reply-To: <1424026008.92.0.265262924683.issue23468@psf.upfronthosting.co.za> Message-ID: <1424038785.85.0.508083030878.issue23468@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 23:31:23 2015 From: report at bugs.python.org (John Malmberg) Date: Sun, 15 Feb 2015 22:31:23 +0000 Subject: [issue22211] Remove VMS specific code in expat.h & xmlrole.h In-Reply-To: <1408222450.15.0.0579194114943.issue22211@psf.upfronthosting.co.za> Message-ID: <1424039483.46.0.592948323531.issue22211@psf.upfronthosting.co.za> John Malmberg added the comment: These files are identical to the files in the expat git repository. So it looks like I need to submit the fix and get it accepted to that repository first. And then at some point cPython will pick up the change. I can still provide diffs if desired, but based on Victor's comment, they would not be applied. Historical Note: That VMS specific code is only needed for building on VAX/VMS 5.5-1 and earlier with the long obsolete VAX C. VAX/VMS 5.5-1 was released in June 1992. VAX/VMS 5.5-2 was released November 1992, and around that time a new DEC C compiler release appeared that no longer needed that hack, but used it as the default mode for backwards compatibility. That default mode is not compatible with many Open Source projects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 23:34:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Feb 2015 22:34:36 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <20150215223322.126596.86919@psf.io> Roundup Robot added the comment: New changeset 02865d22a98d by Serhiy Storchaka in branch '2.7': Issue #22885: Fixed arbitrary code execution vulnerability in the dumbdbm https://hg.python.org/cpython/rev/02865d22a98d New changeset 693bf15b4314 by Serhiy Storchaka in branch '3.4': Issue #22885: Fixed arbitrary code execution vulnerability in the dbm.dumb https://hg.python.org/cpython/rev/693bf15b4314 New changeset cf6a62b0ef3b by Serhiy Storchaka in branch 'default': Issue #22885: Fixed arbitrary code execution vulnerability in the dbm.dumb https://hg.python.org/cpython/rev/cf6a62b0ef3b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 23:38:27 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 22:38:27 +0000 Subject: [issue5700] io.FileIO calls flush() after file closed In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za> Message-ID: <1424039907.6.0.133356356946.issue5700@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, the python-dev thread referenced in the original post is . The obvious fix to me is to have FileIO.close() call IOBase.close() to invoke the flush() before continuing with its own closing. This is what Serhiy?s patches appear to do, so I agree with them in general. I do wonder what the point of duplicating test code in test_io and test_fileio is. The only difference seems to be calling open() versus calling FileIO() directly. Wouldn?t it be better to merge the code together, or maybe just assert open() returns a FileIO instance? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 23:40:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 22:40:44 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1424040044.93.0.842806445835.issue22885@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed issue22885.patch with modified test which demonstrates vulnerability of unpatched dbm.dumb. If you want to change exception type raised by dbm.dumb, you can open new issue. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 23:49:05 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Feb 2015 22:49:05 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <1424040545.81.0.200341498621.issue23374@psf.upfronthosting.co.za> Martin Panter added the comment: Patch looks sensible to me. This is another example of where Issue 15216 would be useful (a standard way to modify the encoding settings of a stream). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 15 23:53:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 22:53:08 +0000 Subject: [issue20140] UnicodeDecodeError in ntpath.py when home dir contains non-ascii signs In-Reply-To: <1389005031.99.0.692658963376.issue20140@psf.upfronthosting.co.za> Message-ID: <1424040788.63.0.694847720978.issue20140@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, the implementation of os.path is alright. There is a bug in distlib.resources. And the lack of os.path documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 00:11:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Feb 2015 23:11:53 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <1424041913.53.0.153653967914.issue23374@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In the case of this issue pydoc needs change not the encoding of stdout, but errors handler of stdout. There is similar issue with pprint (issue19100). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 00:51:18 2015 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 15 Feb 2015 23:51:18 +0000 Subject: [issue20140] UnicodeDecodeError in ntpath.py when home dir contains non-ascii signs In-Reply-To: <1389005031.99.0.692658963376.issue20140@psf.upfronthosting.co.za> Message-ID: <1424044278.83.0.747801861063.issue20140@psf.upfronthosting.co.za> Vinay Sajip added the comment: > There is a bug in distlib.resources. As far as I know, this is no longer the case - a change was made in distlib.resources to get around the problem: https://bitbucket.org/vinay.sajip/distlib/src/471427909ebbba2f4fa9f4cbc34f17bd2d31b8e3/distlib/resources.py?at=default#cl-31 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 01:19:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 00:19:00 +0000 Subject: [issue22390] test.regrtest should complain if a test doesn't remove temporary files In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za> Message-ID: <1424045940.69.0.702454748532.issue22390@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What about this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 01:36:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 16 Feb 2015 00:36:57 +0000 Subject: [issue21898] .hgignore: Missing ignores for Eclipse/pydev In-Reply-To: <1404223695.39.0.861504959592.issue21898@psf.upfronthosting.co.za> Message-ID: <1424047017.89.0.0532528635873.issue21898@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch! I'm -1 to adding IDE/editor specific files to .hgignore. You can create a global .hgignore instead. ---------- nosy: +berker.peksag resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 01:59:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 16 Feb 2015 00:59:03 +0000 Subject: [issue23469] Delete Misc/*.wpr files Message-ID: <1424048342.99.0.00819785192711.issue23469@psf.upfronthosting.co.za> New submission from Berker Peksag: Config/plugin/readme files for Emacs and Vim in Misc have been deleted. The only remaining ones are for Wing IDE. Here is a patch to remove these files. ---------- files: wpr.diff keywords: patch messages: 236082 nosy: berker.peksag priority: normal severity: normal stage: patch review status: open title: Delete Misc/*.wpr files versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38153/wpr.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 02:09:40 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 16 Feb 2015 01:09:40 +0000 Subject: [issue12782] Multiple context expressions do not support parentheses for continuation across lines In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za> Message-ID: <1424048980.23.0.984798443451.issue12782@psf.upfronthosting.co.za> Steven D'Aprano added the comment: This has come up on Python-Ideas again: http://permalink.gmane.org/gmane.comp.python.ideas/32002 https://mail.python.org/pipermail/python-ideas/2015-February/032000.html ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 02:30:12 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 16 Feb 2015 01:30:12 +0000 Subject: [issue17753] test_zipfile: requires write access to test and email.test In-Reply-To: <1366109637.36.0.807884734436.issue17753@psf.upfronthosting.co.za> Message-ID: <1424050212.38.0.608117959486.issue17753@psf.upfronthosting.co.za> Berker Peksag added the comment: Buildbots are not happy: ====================================================================== ERROR: test_write_filtered_python_package (test.test_zipfile.PyZipFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_zipfile.py", line 733, in test_write_filtered_python_package self.requiresWriteAccess(packagedir) File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_zipfile.py", line 683, in requiresWriteAccess if not os.access(path, os.W_OK, effective_ids=True): NotImplementedError: access: effective_ids unavailable on this platform http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/9269/steps/test/logs/stdio ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 02:41:32 2015 From: report at bugs.python.org (Dwight) Date: Mon, 16 Feb 2015 01:41:32 +0000 Subject: [issue23457] make test failures In-Reply-To: <1423795676.28.0.704579624562.issue23457@psf.upfronthosting.co.za> Message-ID: <1424050892.2.0.721098148371.issue23457@psf.upfronthosting.co.za> Dwight added the comment: Hi David, Thanks for the feed back. I must have a defective distribution because when installed python 3 it did not remove the older python 2. Also for some reason I have to set the LIBPATH to include the path to python libarary. Don't know why; but the build does not build a python module that know where the library is installed. I understand that IBM no longer sells workstations based on the Power processor; but there are a few of us out here that have been working on RT/PC, RS/6000 and pSeries system for close to 20 years. It is not a simple project to just up and move to a different environment even if it is another UNIX system. (I have a number of assembly applications that I use every day! Optimized for the Power processor!) I have used the new python to successfully build atk; but am having problems with GObject-Introspection 1.42. It seems that python 3 broke something in that distribution. So far I have not been able to determine if there is a fix for the problem. I have two power systems. A 9114-275 Intellistation and a pSeries 520. Both are configured as workstations. I certaily would rather not have to spend my time trying to build firefox; but I need firefox to access the AIX support site and the H/W and S/W documentation site. (It took about a year for someone to fix it so that I could access the online support site. They at least admitted it was there fault that I could not access the site. However; the current support person/group will not even admit that there is a problem.) Well enough of this off the subject stuff. Thanks for the information and comments. I guess I am now off to solving the GObject-Introspection 1.42 problem. Humm! Have you heard about this incompatability problem? Thanks, Dwight ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 03:36:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Feb 2015 02:36:15 +0000 Subject: [issue17753] test_zipfile: requires write access to test and email.test In-Reply-To: <1366109637.36.0.807884734436.issue17753@psf.upfronthosting.co.za> Message-ID: <20150216023607.62577.24240@psf.io> Roundup Robot added the comment: New changeset 59716f28ed30 by Berker Peksag in branch '3.4': Issue #17753: effective_ids unavailable on Windows. https://hg.python.org/cpython/rev/59716f28ed30 New changeset 964753cf09de by Berker Peksag in branch 'default': Issue #17753: effective_ids unavailable on Windows. https://hg.python.org/cpython/rev/964753cf09de ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 06:42:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 05:42:26 +0000 Subject: [issue17753] test_zipfile: requires write access to test and email.test In-Reply-To: <1366109637.36.0.807884734436.issue17753@psf.upfronthosting.co.za> Message-ID: <1424065346.34.0.227575312321.issue17753@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Berker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 06:42:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 05:42:58 +0000 Subject: [issue17753] test_zipfile: requires write access to test and email.test In-Reply-To: <1366109637.36.0.807884734436.issue17753@psf.upfronthosting.co.za> Message-ID: <1424065378.47.0.29652171495.issue17753@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 07:06:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Feb 2015 06:06:28 +0000 Subject: [issue23115] Backport #22585 -- getentropy for urandom to Python 2.7 In-Reply-To: <1419610873.69.0.17447907262.issue23115@psf.upfronthosting.co.za> Message-ID: <20150216060553.72253.51322@psf.io> Roundup Robot added the comment: New changeset a1391786abcd by Serhiy Storchaka in branch '2.7': Issue #23115: Fixed compilation on OpenBSD (Py_MIN is not defined in 2.7). https://hg.python.org/cpython/rev/a1391786abcd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 07:10:13 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 16 Feb 2015 06:10:13 +0000 Subject: [issue22071] Remove long-time deprecated attributes from smtpd In-Reply-To: <1406307098.0.0.954478358175.issue22071@psf.upfronthosting.co.za> Message-ID: <1424067013.63.0.199459604533.issue22071@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 07:22:43 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 16 Feb 2015 06:22:43 +0000 Subject: [issue10818] pydoc: Remove old server and tk panel In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za> Message-ID: <1424067763.14.0.664514781094.issue10818@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 07:24:00 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 16 Feb 2015 06:24:00 +0000 Subject: [issue14512] Pydocs module docs server not working on Windows. In-Reply-To: <1333645625.74.0.578211515784.issue14512@psf.upfronthosting.co.za> Message-ID: <1424067840.86.0.232086571454.issue14512@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 07:24:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 16 Feb 2015 06:24:25 +0000 Subject: [issue20833] scripts\pydocgui.pyw out of date In-Reply-To: <1393787654.65.0.406806459442.issue20833@psf.upfronthosting.co.za> Message-ID: <1424067865.42.0.0784316792722.issue20833@psf.upfronthosting.co.za> Berker Peksag added the comment: pydocgui.pyw was removed in https://hg.python.org/cpython/rev/2e578b80c2f3. msi.py was updated in issue 14512. Closing this as "out of date". ---------- nosy: +berker.peksag resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 07:32:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 06:32:37 +0000 Subject: [issue20069] Add unit test for os.chown In-Reply-To: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za> Message-ID: <1424068357.21.0.40251279977.issue20069@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Tests failed on Solaris: http://buildbot.python.org/all/builders/AMD64%20Solaris%2011%20%5BSB%5D%203.x/builds/3895/steps/test/logs/stdio ====================================================================== FAIL: test_chown_without_permission (test.test_os.ChownFileTests) ---------------------------------------------------------------------- PermissionError: [Errno 1] Not owner: '@test_18916_tmp' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/test/test_os.py", line 1080, in test_chown_without_permission os.chown(support.TESTFN, uid_2, gid) AssertionError: "Operation not permitted" does not match "[Errno 1] Not owner: '@test_18916_tmp'" ---------------------------------------------------------------------- ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 07:37:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Feb 2015 06:37:22 +0000 Subject: [issue20069] Add unit test for os.chown In-Reply-To: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za> Message-ID: <20150216063602.126618.66923@psf.io> Roundup Robot added the comment: New changeset 4cea99f51bfe by Serhiy Storchaka in branch 'default': Issue #20069: Fixed test_os on Solaris: error message is platform depended. https://hg.python.org/cpython/rev/4cea99f51bfe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 07:52:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 06:52:13 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za> Message-ID: <1424069533.83.0.967460983447.issue22834@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Tests failed on Solaris: http://buildbot.python.org/all/builders/AMD64%20Solaris%2011%20%5BSB%5D%203.x/builds/3895/steps/test/logs/stdio ====================================================================== ERROR: test_deleted_cwd (test.test_importlib.import_.test_path.Source_FinderTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/test/test_importlib/import_/test_path.py", line 167, in test_deleted_cwd os.chdir(path) File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/tempfile.py", line 711, in __exit__ self.cleanup() File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/tempfile.py", line 715, in cleanup _shutil.rmtree(self.name) File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/shutil.py", line 474, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/shutil.py", line 472, in rmtree os.rmdir(path) OSError: [Errno 22] Invalid argument: '/tmp/tmpsx3fm0t4' ---------------------------------------------------------------------- ---------- nosy: +serhiy.storchaka resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 07:54:16 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 16 Feb 2015 06:54:16 +0000 Subject: [issue11717] conflicting definition of ssize_t in pyconfig.h In-Reply-To: <1301443864.94.0.799403342642.issue11717@psf.upfronthosting.co.za> Message-ID: <1424069656.62.0.739461009177.issue11717@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can we have a formal patch review please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 09:18:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 08:18:36 +0000 Subject: [issue23470] OpenBSD buildbot uses wrong stdlib Message-ID: <1424074716.69.0.694325234594.issue23470@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Looks as OpenBSD buildbot imports xml.sax.saxutils from wrong place. http://buildbot.python.org/all/builders/x86%20OpenBSD%205.5%202.7/builds/511/steps/test/logs/stdio ====================================================================== ERROR: test_xmlgen_encoding_bytes (test.test_sax.StringXmlgenTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/python-builds/2.7.borja-openbsd-x86/build/Lib/test/test_sax.py", line 297, in test_xmlgen_encoding_bytes gen.characters(u"\u20ac".encode(encoding)) File "/usr/local/lib/python2.7/site-packages/_xmlplus/sax/saxutils.py", line 309, in characters writetext(self._out, content) File "/usr/local/lib/python2.7/site-packages/_xmlplus/sax/saxutils.py", line 188, in writetext stream.write(escape(text, entities)) File "/home/python-builds/2.7.borja-openbsd-x86/build/Lib/codecs.py", line 357, in write data, consumed = self.encode(object, self.errors) File "/home/python-builds/2.7.borja-openbsd-x86/build/Lib/encodings/iso8859_15.py", line 12, in encode return codecs.charmap_encode(input,errors,encoding_table) UnicodeDecodeError: 'ascii' codec can't decode byte 0xa4 in position 0: ordinal not in range(128) saxutils.py is imported from /usr/local/lib/python2.7/ instead of the build directory. The error that causes UnicodeDecodeError was fixed in issue17606. May be other test failures have the same cause. ---------- components: Tests messages: 236094 nosy: serhiy.storchaka priority: normal severity: normal status: open title: OpenBSD buildbot uses wrong stdlib type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 09:30:29 2015 From: report at bugs.python.org (Daniel) Date: Mon, 16 Feb 2015 08:30:29 +0000 Subject: [issue23471] 404 Not Found when downloading Python 3.4.3rc1 Documentation Message-ID: <1424075429.03.0.707318894375.issue23471@psf.upfronthosting.co.za> New submission from Daniel: Via Chrome on Android 4.4. ---------- assignee: docs at python components: Documentation messages: 236095 nosy: docs at python, stringsonfire priority: normal severity: normal status: open title: 404 Not Found when downloading Python 3.4.3rc1 Documentation type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 09:42:27 2015 From: report at bugs.python.org (SilentGhost) Date: Mon, 16 Feb 2015 08:42:27 +0000 Subject: [issue23471] 404 Not Found when downloading Python 3.4.3rc1 Documentation In-Reply-To: <1424075429.03.0.707318894375.issue23471@psf.upfronthosting.co.za> Message-ID: <1424076147.32.0.806821845539.issue23471@psf.upfronthosting.co.za> SilentGhost added the comment: This is the page: https://docs.python.org/3/download.html also true about the 3.5 at https://docs.python.org/3.5/download.html All the links in the table result in 404. Clearly the files are not at https://docs.python.org/3/archives/ ---------- nosy: +SilentGhost versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 10:01:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 16 Feb 2015 09:01:48 +0000 Subject: [issue23471] 404 Not Found when downloading Python 3.4.3rc1 Documentation In-Reply-To: <1424075429.03.0.707318894375.issue23471@psf.upfronthosting.co.za> Message-ID: <1424077308.54.0.921655679064.issue23471@psf.upfronthosting.co.za> STINNER Victor added the comment: I confirm that all links on this page lead to HTTP 404 errors: https://docs.python.org/3/download.html Same error for "dev" (3.5) version: https://docs.python.org/dev/download.html Python 2 doc can be downloaded: https://docs.python.org/2/download.html ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 10:20:23 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 16 Feb 2015 09:20:23 +0000 Subject: [issue23471] 404 Not Found when downloading Python 3.4.3rc1 Documentation In-Reply-To: <1424075429.03.0.707318894375.issue23471@psf.upfronthosting.co.za> Message-ID: <1424078423.87.0.0126167334368.issue23471@psf.upfronthosting.co.za> Berker Peksag added the comment: I thought this was fixed by issue 22484 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 11:10:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 10:10:22 +0000 Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is required In-Reply-To: <1387382366.37.0.964927896158.issue20015@psf.upfronthosting.co.za> Message-ID: <1424081422.96.0.971872183455.issue20015@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is your decision Guido and Benjamin? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 12:35:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Feb 2015 11:35:27 +0000 Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc In-Reply-To: <1423675815.31.0.721977402363.issue23446@psf.upfronthosting.co.za> Message-ID: <20150216113449.60710.55230@psf.io> Roundup Robot added the comment: New changeset d83884b3a427 by Serhiy Storchaka in branch '2.7': Issue #23446: Use PyMem_New instead of PyMem_Malloc to avoid possible integer https://hg.python.org/cpython/rev/d83884b3a427 New changeset 036a2aceae93 by Serhiy Storchaka in branch '3.4': Issue #23446: Use PyMem_New instead of PyMem_Malloc to avoid possible integer https://hg.python.org/cpython/rev/036a2aceae93 New changeset d12c7938c4b0 by Serhiy Storchaka in branch 'default': Issue #23446: Use PyMem_New instead of PyMem_Malloc to avoid possible integer https://hg.python.org/cpython/rev/d12c7938c4b0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 13:52:23 2015 From: report at bugs.python.org (Myroslav Opyr) Date: Mon, 16 Feb 2015 12:52:23 +0000 Subject: [issue23434] RFC6266 support (Content-Disposition for HTTP) In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za> Message-ID: <1424091143.11.0.320295502818.issue23434@psf.upfronthosting.co.za> Myroslav Opyr added the comment: Hi David, According to "Test Cases for HTTP Content-Disposition header field" overview [1], this is not about email headers, but only about HTTP headers. It look like email standards and http standars are different in this area. I do know that my patch is poor. It is just proof of concept, to show that there is an issue in stdlib and one of the possible fast patches to get functionality needed. Regards, Myroslav Ref: [1] http://greenbytes.de/tech/tc2231/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 14:04:44 2015 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 16 Feb 2015 13:04:44 +0000 Subject: [issue16361] HTTPS/TLS Problem in Python 3.3 In-Reply-To: <1351551122.11.0.0678496091034.issue16361@psf.upfronthosting.co.za> Message-ID: <1424091884.09.0.242901692227.issue16361@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Python 3.3 no longer receives Windows releases, so closing this issue as out of date. Phil, if the issue persists in a newer Python version, please re-report. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 14:45:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 13:45:59 +0000 Subject: [issue18295] Possible integer overflow in PyCode_New() In-Reply-To: <1372108745.44.0.114375127897.issue18295@psf.upfronthosting.co.za> Message-ID: <1424094359.49.0.172084791327.issue18295@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is possible to reproduce original bug without hacking the code object or bytecode: >>> eval('lambda %s, *args, **kwargs: (lambda:args)' % (', '.join('a%d'%i for i in range(253)),))(*range(256))() (253, 254, 255) >>> eval('lambda %s, *args, **kwargs: (lambda:args)' % (', '.join('a%d'%i for i in range(254)),))(*range(256))() (254, 255) >>> eval('lambda %s, *args, **kwargs: (lambda:args)' % (', '.join('a%d'%i for i in range(255)),))(*range(256))() Traceback (most recent call last): File "", line 1, in File "", line 1, in NameError: free variable 'args' referenced before assignment in enclosing scope >>> eval('lambda %s, *args, **kwargs: (lambda:kwargs)' % (', '.join('a%d'%i for i in range(253)),))(*range(256))() {} >>> eval('lambda %s, *args, **kwargs: (lambda:kwargs)' % (', '.join('a%d'%i for i in range(254)),))(*range(256))() Traceback (most recent call last): File "", line 1, in File "", line 1, in NameError: free variable 'kwargs' referenced before assignment in enclosing scope >>> eval('lambda %s, *args, **kwargs: (lambda:kwargs)' % (', '.join('a%d'%i for i in range(255)),))(*range(256))() 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 15:31:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 14:31:52 +0000 Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc In-Reply-To: <1423675815.31.0.721977402363.issue23446@psf.upfronthosting.co.za> Message-ID: <1424097112.42.0.980550017699.issue23446@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 15:51:56 2015 From: report at bugs.python.org (David Edelsohn) Date: Mon, 16 Feb 2015 14:51:56 +0000 Subject: [issue23457] make test failures In-Reply-To: <1423795676.28.0.704579624562.issue23457@psf.upfronthosting.co.za> Message-ID: <1424098316.96.0.303486713602.issue23457@psf.upfronthosting.co.za> David Edelsohn added the comment: A Python3 installation will not overwrite a Python2 installation because they are different major releases and not completely compatible. If Firefox needs Python2, you should build the latest, stable release of Python 2.7. I previously used AIX workstations, but now access AIX servers remotely from Linux workstations. If you log in remotely to an AIX system, you can access all of your scripts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 17:24:11 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 16 Feb 2015 16:24:11 +0000 Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3 In-Reply-To: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za> Message-ID: <1424103851.82.0.724805469023.issue23467@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 17:26:33 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 16 Feb 2015 16:26:33 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1424103993.3.0.64989804788.issue18986@psf.upfronthosting.co.za> Demian Brecht added the comment: Some refactoring that I'm working on for http.client could use this (currently I have it as part of my patch set). I haven't run into any issues using it and it's definitely useful. Would be nice to get this merged. ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 18:44:54 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 16 Feb 2015 17:44:54 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1423879743.64.0.945548577855.issue22928@psf.upfronthosting.co.za> Message-ID: <54E22C8F.2050701@gmail.com> Demian Brecht added the comment: > Maybe join them with tabs rather than spaces then, since it was previously "\r\n\t". This way it is even closer to before. After thinking about this a little more, I think I'd prefer to keep spaces rather than tabs. The reason being is that, in my mind, now that continuations have been made obsolete it's more natural to do something like this: putheader('Authorization', 'Bearer', 'my_token') than putheader('Authorization', 'Bearer my_token') I realize it's a semantic change from previous behavior, but it seems to me to be preferable given the latest RFCs. I'd think that at some point in the future, we'd want to remove \x20 from the valid header value range to entirely conform to the spec. This is the first step in allowing for graceful deprecation. ---------- Added file: http://bugs.python.org/file38154/issue22928_1.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r d12c7938c4b0 Doc/library/http.client.rst --- a/Doc/library/http.client.rst Mon Feb 16 13:33:32 2015 +0200 +++ b/Doc/library/http.client.rst Mon Feb 16 09:42:20 2015 -0800 @@ -292,10 +292,10 @@ .. method:: HTTPConnection.putheader(header, argument[, ...]) - Send an :rfc:`822`\ -style header to the server. It sends a line to the server - consisting of the header, a colon and a space, and the first argument. If more - arguments are given, continuation lines are sent, each consisting of a tab and - an argument. + Send an :rfc:`7230`\ -style header to the server. It sends a line to the server + consisting of the header, a colon and a space, and the first argument. If + more arguments are given, they are appended to the header value, each + prepended with a single space. .. method:: HTTPConnection.endheaders(message_body=None) diff -r d12c7938c4b0 Lib/http/client.py --- a/Lib/http/client.py Mon Feb 16 13:33:32 2015 +0200 +++ b/Lib/http/client.py Mon Feb 16 09:42:20 2015 -0800 @@ -71,6 +71,7 @@ import http import io import os +import re import socket import collections from urllib.parse import urlsplit @@ -87,6 +88,7 @@ _UNKNOWN = 'UNKNOWN' + # connection states _CS_IDLE = 'Idle' _CS_REQ_STARTED = 'Request-started' @@ -107,6 +109,35 @@ _MAXLINE = 65536 _MAXHEADERS = 100 +# Header name/value ABNF (http://tools.ietf.org/html/rfc7230#section-3.2) +# +# VCHAR = %x21-7E +# obs-text = %x80-FF +# header-field = field-name ":" OWS field-value OWS +# field-name = token +# field-value = *( field-content / obs-fold ) +# field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] +# field-vchar = VCHAR / obs-text +# +# obs-fold = CRLF 1*( SP / HTAB ) +# ; obsolete line folding +# ; see Section 3.2.4 + +# token = 1*tchar +# +# tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" +# / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" +# / DIGIT / ALPHA +# ; any VCHAR, except delimiters +# +# VCHAR defined in http://tools.ietf.org/html/rfc5234#appendix-B.1 + +_HEADER_LEGAL_NAME = re.compile(b'^[!#$%&\'*+-.^_`|~a-zA-z0-9]+$') +# 0x20 (sp) is included in the valid character range for backwards +# compatibility, where header values with spaces (i.e. auth headers) are passed +# through to putheader as single values +_HEADER_LEGAL_VALUE = re.compile(b'^\s*[\x20-\x7E]*\s*$') + class HTTPMessage(email.message.Message): # XXX The only usage of this method is in @@ -1000,13 +1031,32 @@ if hasattr(header, 'encode'): header = header.encode('ascii') + + if not _HEADER_LEGAL_NAME.match(header): + raise ValueError('Invalid header name {}'.format(header)) + values = list(values) for i, one_value in enumerate(values): if hasattr(one_value, 'encode'): - values[i] = one_value.encode('latin-1') + encoded_value = one_value.encode('latin-1') elif isinstance(one_value, int): - values[i] = str(one_value).encode('ascii') - value = b'\r\n\t'.join(values) + encoded_value = str(one_value).encode('ascii') + else: + encoded_value = one_value + + if not _HEADER_LEGAL_VALUE.match(encoded_value): + raise ValueError( + 'Invalid header value {}'.format(encoded_value)) + + values[i] = encoded_value + + # http://tools.ietf.org/html/rfc7230#section-3.2.4 states that line + # folding is obsolete, unless message/http MIME type is used and rules + # are conformed to. otherwise, spaces should be used. it might be a + # good idea to put validation for this rule in sometime in the future. + # as it currently stands, there's no way to determine the MIME type of + # the message at this point. + value = b' '.join(values) header = header + b': ' + value self._output(header) diff -r d12c7938c4b0 Lib/test/test_httplib.py --- a/Lib/test/test_httplib.py Mon Feb 16 13:33:32 2015 +0200 +++ b/Lib/test/test_httplib.py Mon Feb 16 09:42:20 2015 -0800 @@ -171,6 +171,15 @@ conn.putheader('Content-length', 42) self.assertIn(b'Content-length: 42', conn._buffer) + conn.putheader('Foo', ' bar ') + self.assertIn(b'Foo: bar ', conn._buffer) + conn.putheader('Bar', '\tbaz\t') + self.assertIn(b'Bar: \tbaz\t', conn._buffer) + conn.putheader('Authorization', 'Bearer mytoken') + self.assertIn(b'Authorization: Bearer mytoken', conn._buffer) + conn.putheader('IterHeader', 'IterA', 'IterB') + self.assertIn(b'IterHeader: IterA IterB', conn._buffer) + def test_ipv6host_header(self): # Default host header on IPv6 transaction should wrapped by [] if # its actual IPv6 address @@ -200,6 +209,22 @@ self.assertEqual(resp.getheader('First'), 'val') self.assertEqual(resp.getheader('Second'), 'val') + def test_invalid_control_characters(self): + conn = client.HTTPConnection('example.com') + conn.sock = FakeSocket('') + conn.putrequest('GET', '/') + + # http://tools.ietf.org/html/rfc7230#section-3.2.4, whitespace is no + # longer allowed in header names + self.assertRaises( + ValueError, conn.putheader, b' InvalidName ', b'foo') + self.assertRaises( + ValueError, conn.putheader, b'Invalid\x80Name', b'foo') + # issue22928 + self.assertRaises( + ValueError, conn.putheader, b'User-agent', + 'Mozilla/5.0' + chr(0x0A) + 'Location: header injection') + class BasicTest(TestCase): def test_status_lines(self): diff -r d12c7938c4b0 Misc/NEWS --- a/Misc/NEWS Mon Feb 16 13:33:32 2015 +0200 +++ b/Misc/NEWS Mon Feb 16 09:42:20 2015 -0800 @@ -44,6 +44,9 @@ argument which, if set to True, will pass messages to handlers taking handler levels into account. +- Issue #22928: HTTPConnection.putheader has been updated to conform to RFC + 7230. + Build ----- From report at bugs.python.org Mon Feb 16 20:01:21 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 16 Feb 2015 19:01:21 +0000 Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns [] In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za> Message-ID: <1424113281.82.0.514781721167.issue5053@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 20:01:36 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 16 Feb 2015 19:01:36 +0000 Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za> Message-ID: <1424113296.33.0.881751187942.issue5054@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 20:01:59 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 16 Feb 2015 19:01:59 +0000 Subject: [issue21257] Document parse_headers function of http.client In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za> Message-ID: <1424113319.33.0.348543442687.issue21257@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 20:14:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Feb 2015 19:14:27 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <20150216191413.60730.37533@psf.io> Roundup Robot added the comment: New changeset a84ae2ccd220 by Serhiy Storchaka in branch 'default': Issue #23450: Fixed possible integer overflows. https://hg.python.org/cpython/rev/a84ae2ccd220 New changeset 1eee26b74e4b by Serhiy Storchaka in branch 'default': Issue #23450: Silenced compiler warnings and added asserts in peephole optimizer. https://hg.python.org/cpython/rev/1eee26b74e4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 20:19:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 19:19:59 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <1424114399.01.0.0885309409123.issue23450@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 20:31:27 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 16 Feb 2015 19:31:27 +0000 Subject: [issue18932] Optimize selectors.EpollSelector.modify() In-Reply-To: <1424035915.31.0.156723174627.issue18932@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Does anyone have a realistic use case where modify() is actually a non-negligible part? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 21:26:12 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Feb 2015 20:26:12 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1424118372.77.0.917191924581.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So, PEP 3149 claims EXT_SUFFIX will always contain the ABI tag, but configure.ac makes it Linux-specific (?!): AC_SUBST(EXT_SUFFIX) case $ac_sys_system in Linux*|GNU*) EXT_SUFFIX=.${SOABI}${SHLIB_SUFFIX};; *) EXT_SUFFIX=${SHLIB_SUFFIX};; esac ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 22:00:55 2015 From: report at bugs.python.org (Julian Berman) Date: Mon, 16 Feb 2015 21:00:55 +0000 Subject: [issue20598] argparse docs: '7'.split() is confusing magic In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za> Message-ID: <1424120455.36.0.738631040883.issue20598@psf.upfronthosting.co.za> Julian Berman added the comment: +1 to lists all over, this is just confusing. ---------- nosy: +Julian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 22:08:53 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Feb 2015 21:08:53 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1424120933.45.0.582085847816.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch adding the bitness to the ABI tag under Linux. This is permitted by PEP 3149: """Python implementations MAY include additional flags in the file name tag as appropriate""". ---------- Added file: http://bugs.python.org/file38155/abi_bitness.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 22:45:15 2015 From: report at bugs.python.org (Roger Upole) Date: Mon, 16 Feb 2015 21:45:15 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424123115.05.0.0125210525045.issue22107@psf.upfronthosting.co.za> Roger Upole added the comment: os.access doesn't check filesystem permissions, so the patch will not catch the condition that creates the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 22:50:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 21:50:29 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1424123429.89.0.288713322155.issue23466@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. The difference between string and bytes formatting is that %c with out of the range integer raises OverflowError for str and TypeError for bytes. May be ValueError is more suitable in both cases. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file38156/bytes_int_format.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 22:59:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Feb 2015 21:59:32 +0000 Subject: [issue23450] Possible loss of data warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423696864.41.0.743234937427.issue23450@psf.upfronthosting.co.za> Message-ID: <20150216215927.62569.38958@psf.io> Roundup Robot added the comment: New changeset f47d683b6c9e by Serhiy Storchaka in branch 'default': Fixed sizeof tests for ElementTree (issue #23450). https://hg.python.org/cpython/rev/f47d683b6c9e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 23:06:14 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 16 Feb 2015 22:06:14 +0000 Subject: [issue19985] Not so correct error message when initializing Struct with ill argument In-Reply-To: <1387099730.06.0.788825958744.issue19985@psf.upfronthosting.co.za> Message-ID: <1424124374.47.0.976262379537.issue19985@psf.upfronthosting.co.za> Martin Panter added the comment: Closely related: * Issue 16349: document byte string format argument support * Issue 21071: should the Struct.format property be bytes or text? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 23:26:16 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 16 Feb 2015 22:26:16 +0000 Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is required In-Reply-To: <1387382366.37.0.964927896158.issue20015@psf.upfronthosting.co.za> Message-ID: <1424125576.03.0.770574847249.issue20015@psf.upfronthosting.co.za> Guido van Rossum added the comment: Let's not do this. The time to meddle with Python 2.7 details is long gone. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 23:35:33 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 16 Feb 2015 22:35:33 +0000 Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is required In-Reply-To: <1387382366.37.0.964927896158.issue20015@psf.upfronthosting.co.za> Message-ID: <1424126133.93.0.624516375688.issue20015@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 23:44:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 22:44:14 +0000 Subject: [issue21548] pydoc -k IndexError on empty docstring In-Reply-To: <1400661783.43.0.558471008968.issue21548@psf.upfronthosting.co.za> Message-ID: <1424126654.09.0.425123933005.issue21548@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- nosy: +serhiy.storchaka stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 16 23:52:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Feb 2015 22:52:51 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424127171.43.0.00582480712889.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is best that we can do. How else we can check filesystem permissions? Only trying to create a file, But we just tried this and it failed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 01:17:26 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 17 Feb 2015 00:17:26 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1424132245.99.0.271145806668.issue22928@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 01:45:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Feb 2015 00:45:49 +0000 Subject: [issue21548] pydoc -k IndexError on empty docstring In-Reply-To: <1400661783.43.0.558471008968.issue21548@psf.upfronthosting.co.za> Message-ID: <20150217004547.21000.81490@psf.io> Roundup Robot added the comment: New changeset 9436f43b6df2 by Benjamin Peterson in branch '3.4': fix pydoc.apropos and pydoc.synopsis on modules with empty docstrings (#21548) https://hg.python.org/cpython/rev/9436f43b6df2 New changeset 534b26837a13 by Benjamin Peterson in branch 'default': merge 3.4 (#21548) https://hg.python.org/cpython/rev/534b26837a13 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 03:09:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 17 Feb 2015 02:09:43 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1424138983.24.0.934950398701.issue22555@psf.upfronthosting.co.za> Nick Coghlan added the comment: Slavek et al - you folks may be interested in this one, as it tracks several issues that I consider relevant to the Python 2 -> 3 migration effort. Redoing the list in a way that should render the strike-throughs for closed issues: * Improved Windows console Unicode support (see https://pypi.python.org/pypi/win_unicode_console for details) * Changing the encoding and error handling of an existing stream (issue 15216) * Allowing "backslashreplace" to be used on input (issue 22286) * Adding "codecs.convert_surrogates" (issue 18814) * Adding "wsgiref.util.dump_wsgistr" and "wsgiref.util.load_wsgistr" (issue 22264) * Adding "bytes.hex", "bytearray.hex" and "memoryview.hex" (issue 9951) * Adding a binary data formatting mini-language (depends on issue 9951, likely needs to be escalated to a full PEP for design discussion visibility) (issue 22385) ---------- nosy: +bkabrda, encukou, rkuska _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 03:14:26 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 17 Feb 2015 02:14:26 +0000 Subject: [issue23471] 404 Not Found when downloading Python 3.4.3rc1 Documentation In-Reply-To: <1424075429.03.0.707318894375.issue23471@psf.upfronthosting.co.za> Message-ID: <1424139266.17.0.605182986724.issue23471@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 03:40:13 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 17 Feb 2015 02:40:13 +0000 Subject: [issue12782] Multiple context expressions do not support parentheses for continuation across lines In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za> Message-ID: <1424140813.92.0.112416537351.issue12782@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Let's just Won't Fix this. Use a contextlib.ExitStack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 03:40:51 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 17 Feb 2015 02:40:51 +0000 Subject: [issue12782] Multiple context expressions do not support parentheses for continuation across lines In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za> Message-ID: <1424140851.12.0.698265691398.issue12782@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 04:23:11 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Feb 2015 03:23:11 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za> Message-ID: <1424143391.91.0.0881524968339.issue22834@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t have a Solaris to test this, but maybe changing the first half of the test to the following would work: dir = tempfile.TemporaryDirectory() self.addCleanup(dir.cleanup) # In case removal after chdir() fails self.addCleanup(os.chdir, os.getcwd()) os.chdir(dir.name) try: dir.cleanup() except OSError as err: # Invalid argument on Solaris self.skipTest("Couldn't remove current directory: {}".format(err)) with util.import_state(...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 04:48:08 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Feb 2015 03:48:08 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1424144888.77.0.64805432367.issue22928@psf.upfronthosting.co.za> Martin Panter added the comment: But it is not natural to do things like this (based on headers sent by Firefox): putheader("User-Agent", "Mozilla/5.0", "(X11;", "Linux", "x86_64;", "rv:25.0)", "Gecko/20100101", "Firefox/25.0") putheader("Accept-Encoding", "gzip,", "deflate") A way to properly encode different kinds of header values would be nice, but I don?t think the current putheader() API is it. Also, I still think it would be good to allow non-ASCII characters in header values. At least when an already-encoded byte string is supplied. For instance, RTSP is based on HTTP but uses UTF-8 as a default encoding, rather than HTTP?s Latin-1. Otherwise, retaining the one_value.encode('latin-1') call is confusing when later on it rejects non-ASCII-encoded characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 05:04:36 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 17 Feb 2015 04:04:36 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes In-Reply-To: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> Message-ID: <1424145876.18.0.285207153.issue23410@psf.upfronthosting.co.za> Martin Panter added the comment: Posting patch v3. It is based on Demian?s suggested wording for the requestline attribute, but adjusted to match the other entries, and to mention the empty string. ---------- Added file: http://bugs.python.org/file38157/http-attributes.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 05:26:02 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Tue, 17 Feb 2015 04:26:02 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1424147162.35.0.509810604922.issue23237@psf.upfronthosting.co.za> Changes by Michiel de Hoon : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 06:04:05 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 17 Feb 2015 05:04:05 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1424144888.77.0.64805432367.issue22928@psf.upfronthosting.co.za> Message-ID: <260DDC4D-B577-4E9A-9421-7C6C605F5B54@gmail.com> Demian Brecht added the comment: > But it is not natural to do things like this (based on headers sent by Firefox) Good point. > Otherwise, retaining the one_value.encode('latin-1') call is confusing when later on it rejects non-ASCII-encoded characters. I?m a little torn on this one given one of the SHOULD clauses in RFC 7230 about recipients treating headers with non-ASCII characters as opaque data. However, I?ve read a number of occasions where users are using latin-1 in practice (and it /is/ only a SHOULD clause), so I think it?s likely better to err on the side of caution and allow for the latin-1 charset at least. As for utf-8 though, I think that once we start getting into the realm of other application protocols, that?s something that should have to be extended by the client implementation and not something that should be changed in the base HTTP implementation. The odd part of the API though now is the fact that it?s variadic. I really have no strong opinion on whether elements should be tab or space delimited and the RFC doesn?t seem to lean either way. I think I?m still leaning towards space delimiting to give users the ability to write in either form (putheader(?Authorization?, ?Bearer?, ?token?) or putheader(?Authorization?, ?Bearer token?)). As another minor argument for it, it?s also likely a little nicer for logging. I think that optimally, the API would be a single value as you?d suggested, but I?d be concerned about the extent of backwards compatibility issues if that were to be done. I?ll try to get some time tomorrow to make those changes, so it still leaves time for further debate :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 06:05:39 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 17 Feb 2015 05:05:39 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes In-Reply-To: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> Message-ID: <1424149539.27.0.851943071885.issue23410@psf.upfronthosting.co.za> Demian Brecht added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 06:06:41 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 17 Feb 2015 05:06:41 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes In-Reply-To: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> Message-ID: <1424149601.79.0.436826421981.issue23410@psf.upfronthosting.co.za> Demian Brecht added the comment: Added Library component as there are a few newly added tests as well though and cosmetic changes were made to server.py. ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 06:28:48 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 17 Feb 2015 05:28:48 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes In-Reply-To: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> Message-ID: <1424150928.29.0.0320465306127.issue23410@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 09:19:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Feb 2015 08:19:55 +0000 Subject: [issue22883] Get rid of references to PyInt in Py3 sources In-Reply-To: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za> Message-ID: <20150217081945.62561.47109@psf.io> Roundup Robot added the comment: New changeset 2f0c1937d716 by Serhiy Storchaka in branch 'default': Issue #22883: Got rid of outdated references to PyInt and PyString in comments. https://hg.python.org/cpython/rev/2f0c1937d716 New changeset c8d08de14030 by Serhiy Storchaka in branch '3.4': Issue #22883: Update PyInt to PyLong in C API example. https://hg.python.org/cpython/rev/c8d08de14030 New changeset c0b2dacef35c by Serhiy Storchaka in branch 'default': Issue #22883: Update PyInt to PyLong in C API example. https://hg.python.org/cpython/rev/c0b2dacef35c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 09:29:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Feb 2015 08:29:22 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1424161762.12.0.568929370744.issue23237@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 09:32:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Feb 2015 08:32:30 +0000 Subject: [issue22883] Get rid of references to PyInt in Py3 sources In-Reply-To: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za> Message-ID: <1424161950.88.0.867846631894.issue22883@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 11:35:52 2015 From: report at bugs.python.org (albertjan) Date: Tue, 17 Feb 2015 10:35:52 +0000 Subject: [issue23425] Windows getlocale unix-like with french, german, portuguese, spanish In-Reply-To: <1423515310.7.0.637877209066.issue23425@psf.upfronthosting.co.za> Message-ID: <1424169352.42.0.943406287404.issue23425@psf.upfronthosting.co.za> albertjan added the comment: Hi, Thanks for your replies. Eryksun (nice to meet you here too!), your function seems very useful, thank you very much. I had indeed already switched to your 'getrawlocale' approach. Perhaps off-topic (because I have never seen this happen in Windows), but locale.getlocale() sometimes returns (None, None), *even if* locale.setlocale(locale.LC_ALL, "") has been called at the start of the program. For some reason, LANG, LC_ALL and possible other vars are sometimes not set correctly (I know this is not Python's fault, but...). Would it be a good idea to have a 'failsafe' parameter in getlocale? Something like: def safe_getlocale(failsafe=False): current_locale = locale.getlocale() if failsafe and current_locale[0] is None and not sys.platform.startswith("win"): os.environ["LANG"] = "en_US.UTF-8" os.environ["LC_ALL"] = "en_US.UTF-8" current_locale = locale.getlocale() return current_locale (sorry for squeezing this in the current issue!) Albert-Jan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 11:54:58 2015 From: report at bugs.python.org (Roger Upole) Date: Tue, 17 Feb 2015 10:54:58 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424170498.67.0.22156332201.issue22107@psf.upfronthosting.co.za> Roger Upole added the comment: It doesn't actually do anything, so why do it at all? In order to distinguish why it failed, you might try checking if the file actually exists, and if it is a folder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 12:38:59 2015 From: report at bugs.python.org (Martin Richard) Date: Tue, 17 Feb 2015 11:38:59 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1424173139.03.0.812123620272.issue21998@psf.upfronthosting.co.za> Martin Richard added the comment: I read the patch, it looks good to me for python 3.5. It will (obviously) not work with python 3.4 since self._selector won't have an _at_fork() method. I ran the tests on my project with python 3.5a1 and the patch, it seems to work as expected: ie. when I close the loop of the parent process in the child, it does not affect the parent. I don't have a case where the loop of the parent is still used in the child though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 12:49:49 2015 From: report at bugs.python.org (Tim Golden) Date: Tue, 17 Feb 2015 11:49:49 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1424170498.67.0.22156332201.issue22107@psf.upfronthosting.co.za> Message-ID: <54E32ADB.3040604@timgolden.me.uk> Tim Golden added the comment: And, just to be clear to Serhiy who I know doesn't use Windows, os.access really is a worthless function in its present form: worse, even, because it can be misleading. I have a long-standing patch to convert it to use AccessCheck but I've never quite had the guts to commit it because I fear the breakage would be too great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 13:32:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Feb 2015 12:32:34 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424176354.58.0.479561611186.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The main issue is not tempfile raises a FileExistsError, but that it hangs for several seconds (for example if the temp dir doesn't exist). The patch allows to fail early and try other temp dir. os.access() is not enough, we can add os.path.isdir(). Could you please run tests on patched Python on Windows and say what tests are failed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 15:12:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Feb 2015 14:12:38 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1424182358.75.0.201645146564.issue21998@psf.upfronthosting.co.za> STINNER Victor added the comment: > It will (obviously) not work with python 3.4 since self._selector won't have an _at_fork() method. asyncio doc contains: "The asyncio package has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the module) may occur if deemed necessary by the core developers." It's not the case for selectors. Even if it would be possible to implement selector._at_fork() in asyncio, it would make more sense to implement it in the selectors module. @neologix: Would you be ok to add a *private* _at_fork() method to selectors classes in Python 3.4 to fix this issue? I know that you are not a fan of fork, me neither, but users like to do crazy things with fork and then report bugs to asyncio :-) ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 15:43:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Feb 2015 14:43:49 +0000 Subject: [issue23472] Setup locales on buildbots Message-ID: <1424184229.01.0.47372627635.issue23472@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Tests use following locales: test_types: en_US.UTF-8 test_codecs: tr_TR test_decimal: ps_AF test_float: fr_FR or de_DE test_imaplib: de_DE or fr_FR test_locale: (en_US.UTF-8, en_US.ISO-8859-1, en_US.US-ASCII, or en_US), tr_TR test_pickle: de_DE or fr_FR test_re: en_US.ISO-8859-1, en_US.UTF-8 test_strptime: en_US.UTF-8, de_DE.UTF-8 test_time: fr_FR test_unicode: de_DE or fr_FR And test__locale uses locales from the long list. So it would be good to setup following locales on all buildbots: en_US, en_US.UTF-8, en_US.ISO-8859-1, en_US.ISO-8859-1, en_US.US-ASCII, de_DE, de_DE.UTF-8, fr_FR, tr_TR, ps_AF ---------- components: Tests messages: 236135 nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Setup locales on buildbots type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 16:10:13 2015 From: report at bugs.python.org (Martin Richard) Date: Tue, 17 Feb 2015 15:10:13 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1424185813.04.0.755264764299.issue21998@psf.upfronthosting.co.za> Martin Richard added the comment: In that case, I suggest a small addition to your patch that would do the trick: in unix_events.py: + def _at_fork(self): + super()._at_fork() + self._selector._at_fork() + self._close_self_pipe() + self._make_self_pipe() + becomes: + def _at_fork(self): + super()._at_fork() + if not hasattr(self._selector, '_at_fork'): + return + self._selector._at_fork() + self._close_self_pipe() + self._make_self_pipe() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 16:56:16 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 17 Feb 2015 15:56:16 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <260DDC4D-B577-4E9A-9421-7C6C605F5B54@gmail.com> Message-ID: Demian Brecht added the comment: I?ve updated the patch to include the latin-1 charset in legal header values. It still uses a space as delimiter, but all other comments should now be addressed. ---------- Added file: http://bugs.python.org/file38158/issue22928_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r d12c7938c4b0 Doc/library/http.client.rst --- a/Doc/library/http.client.rst Mon Feb 16 13:33:32 2015 +0200 +++ b/Doc/library/http.client.rst Tue Feb 17 07:55:09 2015 -0800 @@ -292,10 +292,10 @@ .. method:: HTTPConnection.putheader(header, argument[, ...]) - Send an :rfc:`822`\ -style header to the server. It sends a line to the server - consisting of the header, a colon and a space, and the first argument. If more - arguments are given, continuation lines are sent, each consisting of a tab and - an argument. + Send an :rfc:`7230`\ -style header to the server. It sends a line to the server + consisting of the header, a colon and a space, and the first argument. If + more arguments are given, they are appended to the header value, each + prepended with a single space. .. method:: HTTPConnection.endheaders(message_body=None) diff -r d12c7938c4b0 Lib/http/client.py --- a/Lib/http/client.py Mon Feb 16 13:33:32 2015 +0200 +++ b/Lib/http/client.py Tue Feb 17 07:55:09 2015 -0800 @@ -71,6 +71,7 @@ import http import io import os +import re import socket import collections from urllib.parse import urlsplit @@ -87,6 +88,7 @@ _UNKNOWN = 'UNKNOWN' + # connection states _CS_IDLE = 'Idle' _CS_REQ_STARTED = 'Request-started' @@ -107,6 +109,36 @@ _MAXLINE = 65536 _MAXHEADERS = 100 +# Header name/value ABNF (http://tools.ietf.org/html/rfc7230#section-3.2) +# +# VCHAR = %x21-7E +# obs-text = %x80-FF +# header-field = field-name ":" OWS field-value OWS +# field-name = token +# field-value = *( field-content / obs-fold ) +# field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] +# field-vchar = VCHAR / obs-text +# +# obs-fold = CRLF 1*( SP / HTAB ) +# ; obsolete line folding +# ; see Section 3.2.4 + +# token = 1*tchar +# +# tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" +# / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" +# / DIGIT / ALPHA +# ; any VCHAR, except delimiters +# +# VCHAR defined in http://tools.ietf.org/html/rfc5234#appendix-B.1 + +_HEADER_LEGAL_NAME = re.compile(b'^[!#$%&\'*+-.^_`|~a-zA-z0-9]+$') +# 0x20 (sp) is included in the valid character range for backwards +# compatibility, where header values with spaces (i.e. auth headers) are passed +# through to putheader as single values. latin-1 charset is also legal as ASCII +# is only suggested in RFC 7230 +_HEADER_LEGAL_VALUE = re.compile(b'^\s*[\x20-\x7E\xA0-\xFF]*\s*$') + class HTTPMessage(email.message.Message): # XXX The only usage of this method is in @@ -1000,13 +1032,35 @@ if hasattr(header, 'encode'): header = header.encode('ascii') + + if not _HEADER_LEGAL_NAME.match(header): + raise ValueError('Invalid header name {!r}'.format(header)) + values = list(values) for i, one_value in enumerate(values): if hasattr(one_value, 'encode'): - values[i] = one_value.encode('latin-1') + encoded_value = one_value.encode('latin-1') elif isinstance(one_value, int): - values[i] = str(one_value).encode('ascii') - value = b'\r\n\t'.join(values) + encoded_value = str(one_value).encode('ascii') + else: + encoded_value = one_value + + # Newly defined header fields SHOULD limit their field values to + # US-ASCII octets. A recipient SHOULD treat other octets in field + # content (obs-text) as opaque data. + if not _HEADER_LEGAL_VALUE.match(encoded_value): + raise ValueError( + 'Invalid header value {}'.format(encoded_value)) + + values[i] = encoded_value + + # http://tools.ietf.org/html/rfc7230#section-3.2.4 states that line + # folding is obsolete, unless message/http MIME type is used and rules + # are conformed to. otherwise, spaces should be used. it might be a + # good idea to put validation for this rule in sometime in the future. + # as it currently stands, there's no way to determine the MIME type of + # the message at this point. + value = b' '.join(values) header = header + b': ' + value self._output(header) diff -r d12c7938c4b0 Lib/test/test_httplib.py --- a/Lib/test/test_httplib.py Mon Feb 16 13:33:32 2015 +0200 +++ b/Lib/test/test_httplib.py Tue Feb 17 07:55:09 2015 -0800 @@ -171,6 +171,17 @@ conn.putheader('Content-length', 42) self.assertIn(b'Content-length: 42', conn._buffer) + conn.putheader('Foo', ' bar ') + self.assertIn(b'Foo: bar ', conn._buffer) + conn.putheader('Bar', '\tbaz\t') + self.assertIn(b'Bar: \tbaz\t', conn._buffer) + conn.putheader('Authorization', 'Bearer mytoken') + self.assertIn(b'Authorization: Bearer mytoken', conn._buffer) + conn.putheader('IterHeader', 'IterA', 'IterB') + self.assertIn(b'IterHeader: IterA IterB', conn._buffer) + conn.putheader('LatinHeader', b'\xFF') + self.assertIn(b'LatinHeader: \xFF', conn._buffer) + def test_ipv6host_header(self): # Default host header on IPv6 transaction should wrapped by [] if # its actual IPv6 address @@ -200,6 +211,22 @@ self.assertEqual(resp.getheader('First'), 'val') self.assertEqual(resp.getheader('Second'), 'val') + def test_invalid_control_characters(self): + conn = client.HTTPConnection('example.com') + conn.sock = FakeSocket('') + conn.putrequest('GET', '/') + + # http://tools.ietf.org/html/rfc7230#section-3.2.4, whitespace is no + # longer allowed in header names + self.assertRaises( + ValueError, conn.putheader, b' InvalidName ', b'foo') + self.assertRaises( + ValueError, conn.putheader, b'Invalid\x80Name', b'foo') + # issue22928 + self.assertRaises( + ValueError, conn.putheader, b'User-agent', + 'Mozilla/5.0' + chr(0x0A) + 'Location: header injection') + class BasicTest(TestCase): def test_status_lines(self): diff -r d12c7938c4b0 Misc/NEWS --- a/Misc/NEWS Mon Feb 16 13:33:32 2015 +0200 +++ b/Misc/NEWS Tue Feb 17 07:55:09 2015 -0800 @@ -44,6 +44,9 @@ argument which, if set to True, will pass messages to handlers taking handler levels into account. +- Issue #22928: HTTPConnection.putheader has been updated to conform to RFC + 7230. + Build ----- From report at bugs.python.org Tue Feb 17 17:46:13 2015 From: report at bugs.python.org (PJ Eby) Date: Tue, 17 Feb 2015 16:46:13 +0000 Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za> Message-ID: <1424191573.27.0.781133617065.issue18610@psf.upfronthosting.co.za> PJ Eby added the comment: This is a misreading of the spec. The read() method is defined as taking exactly one parameter. The server *should* support it being optional, but the app invoking it without an argument is not compliant, and wsgiref.validate is validating that the *app* performs according to spec, not the server. Therefore, the documentation is what's in error, not the code. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 17:52:36 2015 From: report at bugs.python.org (Zack) Date: Tue, 17 Feb 2015 16:52:36 +0000 Subject: [issue23473] Allow namedtuple to be JSON encoded as dict Message-ID: <1424191956.27.0.511838281489.issue23473@psf.upfronthosting.co.za> New submission from Zack: We used to be able to override _iterencode prior to 2.7 to get our namedtuples to be encoded as dict using json.dump(s) but now we can not. Namedtuples are automatically encoded as list but it would be more logical and convenient to have them encoded as dict ---------- messages: 236139 nosy: Zack--, ezio.melotti, pitrou, rhettinger priority: normal severity: normal status: open title: Allow namedtuple to be JSON encoded as dict type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 18:11:12 2015 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 17 Feb 2015 17:11:12 +0000 Subject: [issue23472] Setup locales on buildbots In-Reply-To: <1424184229.01.0.47372627635.issue23472@psf.upfronthosting.co.za> Message-ID: <1424193072.28.0.575571686759.issue23472@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 18:55:47 2015 From: report at bugs.python.org (Robin Schoonover) Date: Tue, 17 Feb 2015 17:55:47 +0000 Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za> Message-ID: <1424195747.36.0.487064838995.issue18610@psf.upfronthosting.co.za> Robin Schoonover added the comment: I'm not sure I follow, as it has little to say on whether the application's expected behavior here, and only a recommendation that the server allow it. But, it also defers to the "Python Standard Library", which does have an opinion. I feel that (in hindsight) the exact behavior of each method should have been specified in full. *However*, even if I differ on the reading of the spec, on general principle (and this has changed since I first wrote the issue) I agree that the application should not be omitting it anyway, because reading the entire response at once without checking the content length is dangerous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 19:34:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Feb 2015 18:34:06 +0000 Subject: [issue23474] Enhance locale testing Message-ID: <1424198046.6.0.777613508402.issue23474@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch enhance locale testing. test__locale is converted to support unittest discovery. When there are no suitable locales (e.g. there is only POSIX locale) tests are reported as skipped. Tested thousands_sep with non-english locales. Tested non-ascii values of decimal_point and thousands_sep with the ps_AF locale. In test_locale Turkish locale test no longer break a line. ---------- components: Tests files: test__locale.patch keywords: patch messages: 236141 nosy: lemburg, loewis, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Enhance locale testing type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38159/test__locale.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 19:45:11 2015 From: report at bugs.python.org (Link Mauve) Date: Tue, 17 Feb 2015 18:45:11 +0000 Subject: [issue22623] Missing guards for some POSIX functions In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za> Message-ID: <1424198711.69.0.998947155468.issue22623@psf.upfronthosting.co.za> Link Mauve added the comment: Removed the unwanted introduced function, and added a comment signaling the end of the HAVE_TTYNAME #ifdef. The full patch is attached, the diff with the previous version can be found at http://linkmauve.fr/files/getedig.patch ---------- Added file: http://bugs.python.org/file38160/getedig.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 19:50:56 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 17 Feb 2015 18:50:56 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1424199056.86.0.785522739321.issue22107@psf.upfronthosting.co.za> Mark Lawrence added the comment: The feedback here https://mail.python.org/pipermail/python-dev/2011-May/111530.html seems positive. It references #2528 which is still open but strikes me as the way forward. Why don't we go for it and nail this issue once and for all? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 19:52:52 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 17 Feb 2015 18:52:52 +0000 Subject: [issue2528] Change os.access to check ACLs under Windows In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za> Message-ID: <1424199172.04.0.514106309499.issue2528@psf.upfronthosting.co.za> Mark Lawrence added the comment: The solution proposed here could help resolve #22107. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 20:16:32 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 17 Feb 2015 19:16:32 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1424182358.75.0.201645146564.issue21998@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > @neologix: Would you be ok to add a *private* _at_fork() method to selectors classes in Python 3.4 to fix this issue? Not really: after fork(), you're hosed anyway: """ Q6 Will closing a file descriptor cause it to be removed from all epoll sets automatically? A6 Yes, but be aware of the following point. A file descriptor is a reference to an open file description (see open(2)). Whenever a descriptor is duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, or fork(2), a new file descriptor referring to the same open file description is created. An open file description continues to exist until all file descriptors referring to it have been closed. A file descriptor is removed from an epoll set only after all the file descriptors referring to the underlying open file description have been closed (or before if the descriptor is explicitly removed using epoll_ctl(2) EPOLL_CTL_DEL). This means that even after a file descriptor that is part of an epoll set has been closed, events may be reported for that file descriptor if other file descriptors referring to the same underlying file description remain open. """ What would you do with the selector after fork(): register the FDs in a new epoll, remove them? There's no sensible default behavior, and I'd rrather avoid polluting the code for this. If asyncio wants to support this, it can create a new selector and re-register everything it wants manually: there's a Selector.get_map() exposing all that's needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 20:23:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Feb 2015 19:23:08 +0000 Subject: [issue2528] Change os.access to check ACLs under Windows In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za> Message-ID: <1424200988.27.0.414863743153.issue2528@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 20:24:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Feb 2015 19:24:48 +0000 Subject: [issue22623] Missing guards for some POSIX functions In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za> Message-ID: <1424201088.3.0.195868377793.issue22623@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 3.2 and 3.3 are only for security fixes now. ---------- nosy: +serhiy.storchaka versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 20:28:56 2015 From: report at bugs.python.org (Link Mauve) Date: Tue, 17 Feb 2015 19:28:56 +0000 Subject: [issue22623] Missing guards for some POSIX functions In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za> Message-ID: <1424201336.46.0.715371618444.issue22623@psf.upfronthosting.co.za> Changes by Link Mauve : Added file: http://bugs.python.org/file38161/getedig.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 20:57:41 2015 From: report at bugs.python.org (Olivier Matz) Date: Tue, 17 Feb 2015 19:57:41 +0000 Subject: [issue23067] Export readline forced_update_display In-Reply-To: <1418758154.75.0.0731776033419.issue23067@psf.upfronthosting.co.za> Message-ID: <1424203061.58.0.298510785496.issue23067@psf.upfronthosting.co.za> Olivier Matz added the comment: Hi, I'm also interrested in this feature. Indeed, exporting rl_forced_update_display() is the only way I've found to make readline.set_completion_display_matches_hook() working properly. Without forcing the redisplay, the prompt is not displayed. This seems to be the proper function to call, because that's the one called at the end of display_matches() in libreadline code, which is the default function for displaying matches. The attached file is a simple example code derived from http://pymotw.com/2/readline/ that shows that the patch is working. ---------- nosy: +zer0 Added file: http://bugs.python.org/file38162/test-rdline.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 21:01:48 2015 From: report at bugs.python.org (Olivier Matz) Date: Tue, 17 Feb 2015 20:01:48 +0000 Subject: [issue23067] Export readline forced_update_display In-Reply-To: <1418758154.75.0.0731776033419.issue23067@psf.upfronthosting.co.za> Message-ID: <1424203308.72.0.436333971508.issue23067@psf.upfronthosting.co.za> Olivier Matz added the comment: By the way, I have my own implementation of the patch that did before checking the issue tracker. Instead of adding an argument to readline.redisplay(), it adds a new function readline.forced_update_display(). I attach the patch for reference, I don't know what is the preferred way to add this feature. ---------- Added file: http://bugs.python.org/file38163/readline_add_forced_update_display.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 22:27:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Feb 2015 21:27:13 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: Message-ID: STINNER Victor added the comment: 2015-02-17 20:16 GMT+01:00 Charles-Fran?ois Natali : > What would you do with the selector after fork(): register the FDs in > a new epoll, remove them? See the patch: + def _at_fork(self): + # don't unregister file descriptors: epoll is still shared with + # the parent process + self._epoll = select.epoll() + for key in self._fd_to_key.values(): + self._register(key) EpollSelector._at_fork() does nothing on the current epoll object, create a new epoll object and register again all file descriptor. Hum, I should maybe close explicitly the old epoll object. > There's no sensible default behavior, and I'd rrather avoid polluting > the code for this. What is wrong with the proposed patch? > If asyncio wants to support this, it can create a new selector and > re-register everything it wants manually: there's a Selector.get_map() > exposing all that's needed. If possible, I would prefer to implement "at fork" in the selectors module directly, the selectors module has a better knowledge of seletors. For example, asyncio is not aware of the selector._epoll attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 22:30:23 2015 From: report at bugs.python.org (Martin Richard) Date: Tue, 17 Feb 2015 21:30:23 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1424208623.96.0.553883282509.issue21998@psf.upfronthosting.co.za> Martin Richard added the comment: The goal of the patch is to create a duplicate selector (a new epoll() structure with the same watched fds as the original epoll). It allows to remove fds watched in the child's loop without impacting the parent process. Actually, it's true that with the current implementation of the selectors module (using get_map()), we can achieve the same result than with victor's patch without touching the selector module. I attached a patch doing that, also working with python 3.4. I thought about this at_fork() mechanism a bit more and I'm not sure of what we want to achieve with this. In my opinion, most of the time, we will want to recycle the loop in the child process (close it and create a new one) because we will not want to have the tasks and callbacks scheduled on the loop running on both the parent and the child (it would probably result in double writes on sockets, or double reads, for instance). With the current implementation of asyncio, I can't recycle the loop for a single reason: closing the loop calls _close_self_pipe() which unregisters the pipe of the selector (hence breaking the loop in the parent). Since the self pipe is an object internal to the loop, I think it's safe to close the pipes without unregistering them of the selector. It is at least true with epoll() according to the documentation quoted by neologix, but I hope that we can expect it to be true with other unix platforms too. ---------- Added file: http://bugs.python.org/file38164/at_fork-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 22:38:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Feb 2015 21:38:03 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1424208623.96.0.553883282509.issue21998@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: How do other event loops handle fork? Twisted, Tornado, libuv, libev, libevent, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 22:40:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Feb 2015 21:40:00 +0000 Subject: [issue23475] asyncio: reference leak in test_close_kill_running() Message-ID: <1424209200.5.0.815525755061.issue23475@psf.upfronthosting.co.za> New submission from STINNER Victor: The test_close_kill_running() test of test.test_asyncio.test_subprocess leaks references. It may be a reference cycle. ---------------------- haypo at selma$ ./python -Wall -b -m test.regrtest -R 3:3:refleaks -m test_close_kill_running test_asyncio [1/1] test_asyncio beginning 6 repetitions 123456 ...... test_asyncio leaked [388, 388, 388] references, sum=1164 test_asyncio leaked [84, 85, 85] memory blocks, sum=254 1 test failed: test_asyncio ---------------------- See also the issue #23353. Note: test_close_dont_kill_finished() doesn't leak. ---------- components: asyncio messages: 236152 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: reference leak in test_close_kill_running() versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 23:02:04 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 17 Feb 2015 22:02:04 +0000 Subject: [issue23474] Enhance locale testing In-Reply-To: <1424198046.6.0.777613508402.issue23474@psf.upfronthosting.co.za> Message-ID: <54E3BA5F.5080804@egenix.com> Marc-Andre Lemburg added the comment: On 17.02.2015 19:34, Serhiy Storchaka wrote: > > Proposed patch enhance locale testing. test__locale is converted to support unittest discovery. When there are no suitable locales (e.g. there is only POSIX locale) tests are reported as skipped. Tested thousands_sep with non-english locales. Tested non-ascii values of decimal_point and thousands_sep with the ps_AF locale. In test_locale Turkish locale test no longer break a line. Look good. Thanks, Serhiy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 23:12:45 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 17 Feb 2015 22:12:45 +0000 Subject: [issue9099] multiprocessing/win32: WindowsError: [Error 0] Success on Pipe() In-Reply-To: <1277729700.77.0.590017326086.issue9099@psf.upfronthosting.co.za> Message-ID: <1424211165.94.0.757777886195.issue9099@psf.upfronthosting.co.za> Davin Potts added the comment: Though the code may have changed a bit in the meantime (Issue11750 in particular), the calls to _winapi.SetNamedPipeHandleState in Lib/multiprocessing/connection.py are still present and largely the same as when this issue was first opened. The implementation of _winapi.SetNamedPipeHandleState still has the potential to raise a WindowsError with its message (i.e. e.args[0]) set to whatever the Windows GetLastError() function returns. My reading of the MSDN docs and the code in Modules/_winapi.c is as follows: 1. A WindowsError exception is raised only if the Windows function SetNamedPipeHandleState returns 0. 2. The Windows function SetNamedPipeHandleState only returns 0 if it failed. 3. When that function fails, the Windows function GetLastError is expected to return a non-zero value to provide insight on the nature of the failure. 4. MSDN docs suggest that some functions may call SetLastError with 0 to indicate success (seen when subsequently calling GetLastError). This creates a bit of a conundrum given what the OP observed in the provided traceback: the Windows function SetNamedPipeHandleState failed yet the call to GetLastError returned a 0. Possibly the MSDN docs are incomplete on this specific matter and/or there could be other environmental factors on the system(s) where this issue has been observed not to mention other wrinkles from the OP's reported use of Cython to embed the Python interpreter to trigger the issue. A google search for other situations triggering this same behavior did turn up mentions of encountering it inside the Wine environment running on Ubuntu -- debugging Wine's re-implementation of Windows APIs is certainly out-of-scope here. It is possible that this issue is caused by environmental issues and may not be possible to provoke in a supported standard Windows system environment. Without a test case or some other way to provoke or reproduce the issue, there is little capability to pursue this further. The OP kindly followed up several years ago to say that he could not find a way to reproduce the issue reliably. Given that, the above review of the code, and the search results from looking for other instances of this sort of issue, I am going ahead with closing this issue. ---------- nosy: +davin resolution: -> rejected stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 23:14:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Feb 2015 22:14:42 +0000 Subject: [issue23475] asyncio: reference leak in test_close_kill_running() In-Reply-To: <1424209200.5.0.815525755061.issue23475@psf.upfronthosting.co.za> Message-ID: <20150217221418.71226.26026@psf.io> Roundup Robot added the comment: New changeset 0f6ddf944521 by Victor Stinner in branch '3.4': Issue #23475, asyncio: Fix test_close_kill_running() https://hg.python.org/cpython/rev/0f6ddf944521 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 17 23:17:07 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Feb 2015 22:17:07 +0000 Subject: [issue23475] asyncio: reference leak in test_close_kill_running() In-Reply-To: <1424209200.5.0.815525755061.issue23475@psf.upfronthosting.co.za> Message-ID: <1424211427.16.0.451900478813.issue23475@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 00:04:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 17 Feb 2015 23:04:46 +0000 Subject: [issue23472] Setup locales on buildbots In-Reply-To: <1424184229.01.0.47372627635.issue23472@psf.upfronthosting.co.za> Message-ID: <1424214286.83.0.271361631528.issue23472@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lemburg, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 00:47:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Feb 2015 23:47:49 +0000 Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX platforms In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za> Message-ID: <1424216869.36.0.459845975619.issue23428@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I missed the issue #12822 which looks to fix similar bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 00:59:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Feb 2015 23:59:19 +0000 Subject: [issue6532] thread.get_ident() should return unsigned value In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za> Message-ID: <1424217559.43.0.701956517517.issue6532@psf.upfronthosting.co.za> STINNER Victor added the comment: On Linux, the following C program tells me that pthread_t is unsigned. --- #include #include #define TYPE_IS_SIGNED(TYPE) ((TYPE)-1 < (TYPE)0) int main() { printf("signed? %i\n", TYPE_IS_SIGNED(pthread_t)); return 0; } --- So it's fair to modify threading.get_ident() to return an unsigned number. But I disagree to change stable Python versions, it may break applications. Oh, I wrote write_thread_id() in Python/traceback.c and this function already casts the thread identifier to an unsigned number ;-) ---------- nosy: +haypo versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 02:07:17 2015 From: report at bugs.python.org (John Nagle) Date: Wed, 18 Feb 2015 01:07:17 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" Message-ID: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> New submission from John Nagle: SSL certificate verification fails for "www.verisign.com" when using the cert list from Firefox. Other sites ("google.com", "python.org") verify fine. This may be related to a known, and fixed, OpenSSL bug. See: http://rt.openssl.org/Ticket/Display.html?id=2732&user=guest&pass=guest https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1014640 Some versions of OpenSSL are known to be broken for cases where there multiple valid certificate trees. This happens when one root cert is being phased out in favor of another, and cross-signing is involved. Python ships with its own copy of OpenSSL on Windows. Tests for "www.verisign.com" Win7, x64: Python 2.7.9 with OpenSSL 1.0.1j 15 Oct 2014. FAIL Python 3.4.2 with OpenSSL 1.0.1i 6 Aug 2014. FAIL openssl s_client -OpenSSL 1.0.1h 5 Jun 2014 FAIL Ubuntu 14.04 LTS, x64, using distro's versions of Python: Python 2.7.6 - test won't run, needs create_default_context Python 3.4.0 with OpenSSL 1.0.1f 6 Jan 2014. FAIL openssl s_client OpenSSL 1.0.1f 6 Jan 2014 PASS That's with the same cert file in all cases. The OpenSSL version for Python programs comes from ssl.OPENSSL_VERSION. The Linux situation has me puzzled. On Linux, Python is supposedly using the system version of OpenSSL. The versions match. Why do Python and the OpenSSL command line client disagree? Different options passed to OpenSSL by Python? A simple test program and cert file are attached. Please try this in your environment. ---------- components: Library (Lib) files: ssltest.py messages: 236158 nosy: nagle priority: normal severity: normal status: open title: SSL cert verify fail for "www.verisign.com" versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file38165/ssltest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 02:09:05 2015 From: report at bugs.python.org (John Nagle) Date: Wed, 18 Feb 2015 01:09:05 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424221745.3.0.30076106499.issue23476@psf.upfronthosting.co.za> John Nagle added the comment: Add cert file for testing. Source of this file is http://curl.haxx.se/ca/cacert.pem ---------- Added file: http://bugs.python.org/file38166/cacert.pem _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 02:15:37 2015 From: report at bugs.python.org (John Nagle) Date: Wed, 18 Feb 2015 01:15:37 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424222137.01.0.756882322578.issue23476@psf.upfronthosting.co.za> John Nagle added the comment: To try this with the OpenSSL command line client, use this shell command: openssl s_client -connect www.verisign.com:443 -CAfile cacert.pem This provides more detailed error messages than Python provides. "verify error:num=20:unable to get local issuer certificate" is the OpenSSL error for "www.verisign.com". The corresponding Python error is "[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 03:11:47 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 18 Feb 2015 02:11:47 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1424225507.19.0.842847428176.issue18986@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FYI, the PEP for this isn't going to be accepted (I'm working on the write-up for the reasons why and will post on python-dev). That said, it would be great if the code continues to be improved and then posted on the Python Package Index. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 03:13:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Feb 2015 02:13:37 +0000 Subject: [issue23410] Document more BaseHTTPRequestHandler attributes In-Reply-To: <1423390877.64.0.272904715009.issue23410@psf.upfronthosting.co.za> Message-ID: <20150218021334.72269.89502@psf.io> Roundup Robot added the comment: New changeset f9ff2a5bbbe2 by Benjamin Peterson in branch '3.4': document the requestline and close_connection attributes, use real booleans, and add tests (closes #23410) https://hg.python.org/cpython/rev/f9ff2a5bbbe2 New changeset 6e3e252cf047 by Benjamin Peterson in branch 'default': merge 3.4 (#23410) https://hg.python.org/cpython/rev/6e3e252cf047 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 03:28:31 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Feb 2015 02:28:31 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1424226511.89.0.0220581151427.issue18986@psf.upfronthosting.co.za> Martin Panter added the comment: I will be interested to see those reasons. Another way to do a similar thing might be using a Key(value, transform) class, somewhat along the lines of Issue 20632, but as a separate class rather than part of the core type system. But I have not thought that idea through very much. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 07:05:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Feb 2015 06:05:56 +0000 Subject: [issue23474] Enhance locale testing In-Reply-To: <1424198046.6.0.777613508402.issue23474@psf.upfronthosting.co.za> Message-ID: <20150218060546.72273.87355@psf.io> Roundup Robot added the comment: New changeset 7ef372f656d1 by Serhiy Storchaka in branch '2.7': Issue #23474: Enhanced locale testing. https://hg.python.org/cpython/rev/7ef372f656d1 New changeset b53aadd9cf85 by Serhiy Storchaka in branch '3.4': Issue #23474: Enhanced locale testing. https://hg.python.org/cpython/rev/b53aadd9cf85 New changeset 4f7c5349e801 by Serhiy Storchaka in branch 'default': Issue #23474: Enhanced locale testing. https://hg.python.org/cpython/rev/4f7c5349e801 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 07:06:52 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Feb 2015 06:06:52 +0000 Subject: [issue23427] Python should expose command when invoked with -c In-Reply-To: <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za> Message-ID: <1424239612.0.0.477109329243.issue23427@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 07:06:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 18 Feb 2015 06:06:58 +0000 Subject: [issue23474] Enhance locale testing In-Reply-To: <1424198046.6.0.777613508402.issue23474@psf.upfronthosting.co.za> Message-ID: <1424239618.43.0.722432861249.issue23474@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 08:27:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 18 Feb 2015 07:27:52 +0000 Subject: [issue6532] thread.get_ident() should return unsigned value In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za> Message-ID: <1424244472.2.0.759384498435.issue6532@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is updated patch. Added few tests. ---------- Added file: http://bugs.python.org/file38167/thread_id_unsigned_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 09:31:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Feb 2015 08:31:49 +0000 Subject: [issue6532] thread.get_ident() should return unsigned value In-Reply-To: <1424244472.2.0.759384498435.issue6532@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Here is updated patch. Added few tests. Cool. I sent a review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 11:47:11 2015 From: report at bugs.python.org (F.) Date: Wed, 18 Feb 2015 10:47:11 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1424256431.72.0.625344093386.issue11245@psf.upfronthosting.co.za> F. added the comment: Imaplib2 now supports Python 3. Piers and me propose to merge imaplib2 into standard library as imaplib. Excerpt from our conversation: Piers: ...Thanks for bringing it (this thread) to my attention. I entirely agree with your comments. Me: ...I found the criticism of the "threads - a heavy solution"? counterproductive. Not that I know anything about threads... Piers: I'm not sure what the whole anti-threads thing was about all those years ago since I always loved using them. Maybe early implementations were slow, or, more likely, early adopters were clumsy ("giving threads to a novice is like giving a blow torch to a baby" to paraphrade a quote :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 11:57:22 2015 From: report at bugs.python.org (Laura Creighton) Date: Wed, 18 Feb 2015 10:57:22 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424257042.45.0.966032598486.issue23476@psf.upfronthosting.co.za> Laura Creighton added the comment: I have this problem too. Debian jessie/sid Python 2.7.8 (default, Nov 18 2014, 14:57:17) Python 3.4.2 (default, Nov 13 2014, 07:01:52) ---------- nosy: +lac _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 13:34:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 18 Feb 2015 12:34:31 +0000 Subject: [issue6532] thread.get_ident() should return unsigned value In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za> Message-ID: <1424262871.58.0.323889097737.issue6532@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Victor for your review. Here is updated patch. ---------- Added file: http://bugs.python.org/file38168/thread_id_unsigned_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 13:44:01 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 18 Feb 2015 12:44:01 +0000 Subject: [issue23473] Allow namedtuple to be JSON encoded as dict In-Reply-To: <1424191956.27.0.511838281489.issue23473@psf.upfronthosting.co.za> Message-ID: <1424263441.49.0.88914640658.issue23473@psf.upfronthosting.co.za> Eric V. Smith added the comment: Can you post a code snippet that used to work, but now does not? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 13:53:37 2015 From: report at bugs.python.org (Zack) Date: Wed, 18 Feb 2015 12:53:37 +0000 Subject: [issue23473] Allow namedtuple to be JSON encoded as dict In-Reply-To: <1424191956.27.0.511838281489.issue23473@psf.upfronthosting.co.za> Message-ID: <1424264017.4.0.0999204598294.issue23473@psf.upfronthosting.co.za> Zack added the comment: >From memory, something along the lines of from json import JSONEncoder class ExtendedJSONEncoder(JSONEncoder): def _iterencode(self, o, markers=None): if isinstance(o, tuple) and hasattr(obj, '_fields'): gen = self._iterencode_dict(o.__dict__, markers) else: gen = JSONEncoder._iterencode(self, o, markers) for chunk in gen: yield chunk ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 15:01:34 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Feb 2015 14:01:34 +0000 Subject: [issue17033] RPM spec file has old config_binsuffix value In-Reply-To: <1359129213.62.0.851750342405.issue17033@psf.upfronthosting.co.za> Message-ID: <1424268094.54.0.24322134808.issue17033@psf.upfronthosting.co.za> Benjamin Peterson added the comment: We just removed the spec file. ---------- nosy: +benjamin.peterson resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 15:02:41 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Feb 2015 14:02:41 +0000 Subject: [issue23169] Reflect that PreReq and BuildPreReq are deprecated in the latest RPM In-Reply-To: <1420463891.72.0.774842309991.issue23169@psf.upfronthosting.co.za> Message-ID: <1424268161.84.0.137290171814.issue23169@psf.upfronthosting.co.za> Benjamin Peterson added the comment: We just deleted the spec file. ---------- nosy: +benjamin.peterson resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 15:23:48 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Feb 2015 14:23:48 +0000 Subject: [issue22235] httplib: TypeError with file() object in ssl.py In-Reply-To: <1408543105.82.0.290860786236.issue22235@psf.upfronthosting.co.za> Message-ID: <1424269428.14.0.664113433494.issue22235@psf.upfronthosting.co.za> R. David Murray added the comment: Verification errors that used to be ignored (ie: verification was not done by default) are now reported. That was basically the whole point of 2.7.9. So this is most likely a problem with the site certificate, not python. As far as I can see there aren't any CPython bugs being reported in this issue, so I'm closing it as 3rd party. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 15:55:15 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 18 Feb 2015 14:55:15 +0000 Subject: [issue1559298] test_popen fails on Windows if installed to "Program Files" Message-ID: <1424271315.42.0.75927793639.issue1559298@psf.upfronthosting.co.za> Mark Lawrence added the comment: Do we leave this open or close it as there is a known work around for 2.7? ---------- versions: -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 15:57:17 2015 From: report at bugs.python.org (Alex Shkop) Date: Wed, 18 Feb 2015 14:57:17 +0000 Subject: [issue23477] Increase coverage for wsgiref module Message-ID: <1424271437.72.0.0459822564302.issue23477@psf.upfronthosting.co.za> New submission from Alex Shkop: Added test for wssgiref.simple_server to check that environ argument contains correct headers, query string and path. This code wasn't covered in tests previously. ---------- components: Tests files: wsgiref_test_environ.patch keywords: patch messages: 236176 nosy: ashkop priority: normal severity: normal status: open title: Increase coverage for wsgiref module versions: Python 3.5 Added file: http://bugs.python.org/file38169/wsgiref_test_environ.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 16:11:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 18 Feb 2015 15:11:02 +0000 Subject: [issue23473] Allow namedtuple to be JSON encoded as dict In-Reply-To: <1424191956.27.0.511838281489.issue23473@psf.upfronthosting.co.za> Message-ID: <1424272262.27.0.887230282118.issue23473@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue12657. ---------- nosy: +serhiy.storchaka resolution: -> duplicate status: open -> closed superseder: -> Cannot override JSON encoding of basic type subclasses _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 16:16:25 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 18 Feb 2015 15:16:25 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1424226511.89.0.0220581151427.issue18986@psf.upfronthosting.co.za> Message-ID: Demian Brecht added the comment: > I will be interested to see those reasons. +1. Something like what this PEP proposed would be beneficial in a few places throughout the library (header and cookie implementations would definitely benefit rather than having to deal with buggy normalization themselves). It?s unfortunate that this isn?t going to be approved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 16:54:02 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 18 Feb 2015 15:54:02 +0000 Subject: [issue5739] Language reference is ambiguous regarding next() method lookup In-Reply-To: <1239497907.46.0.481458734082.issue5739@psf.upfronthosting.co.za> Message-ID: <1424274842.37.0.0531351763564.issue5739@psf.upfronthosting.co.za> Mark Lawrence added the comment: Thrown up by selecting "Random Issue", if nothing else it looks to me as if __next__ is missing from and so should be documented in https://docs.python.org/3.1/reference/datamodel.html#special-method-names ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 16:57:26 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 18 Feb 2015 15:57:26 +0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1424275046.27.0.880248570686.issue2211@psf.upfronthosting.co.za> Demian Brecht added the comment: The attached patch should cover the implementation/test aspects of this issue. I'll work on the documentation next. ---------- keywords: +patch versions: +Python 3.5 -Python 3.2 Added file: http://bugs.python.org/file38170/issue2211.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 17:12:14 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 18 Feb 2015 16:12:14 +0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1424275934.11.0.754560555841.issue2211@psf.upfronthosting.co.za> Demian Brecht added the comment: Never mind, Morsel /is/ documented (at least in Docs). I imagine that the OP was after more detailed docstrings, but I don't believe they'd add much value. The patch should be good to go as-is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 17:22:14 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 18 Feb 2015 16:22:14 +0000 Subject: [issue9913] Misc/SpecialBuilds.txt is out of date In-Reply-To: <1285084668.56.0.665403194927.issue9913@psf.upfronthosting.co.za> Message-ID: <1424276534.73.0.59800883047.issue9913@psf.upfronthosting.co.za> Mark Lawrence added the comment: This file has been updated with the most recent revision being r90052. Can we close this as out of date? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 17:23:26 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 18 Feb 2015 16:23:26 +0000 Subject: [issue21257] Document parse_headers function of http.client In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za> Message-ID: <1424276606.17.0.835655847602.issue21257@psf.upfronthosting.co.za> Demian Brecht added the comment: Left a super minor comment in Rietveld, but otherwise LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 17:35:52 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 18 Feb 2015 16:35:52 +0000 Subject: [issue1559298] test_popen fails on Windows if installed to "Program Files" Message-ID: <1424277352.75.0.804535999724.issue1559298@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 18:37:49 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 18 Feb 2015 17:37:49 +0000 Subject: [issue9913] Misc/SpecialBuilds.txt is out of date In-Reply-To: <1285084668.56.0.665403194927.issue9913@psf.upfronthosting.co.za> Message-ID: <1424281069.86.0.604186099371.issue9913@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Actually, the real improvements came in changeset 67177:01714efdc6cf. Closing. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 18:50:09 2015 From: report at bugs.python.org (P Yap) Date: Wed, 18 Feb 2015 17:50:09 +0000 Subject: [issue23478] A list arg with default value inside function got appended each time the function is called Message-ID: <1424281809.58.0.308788589404.issue23478@psf.upfronthosting.co.za> New submission from P Yap: I have a function (test) with a list variable APP and declared its default as an empty list [], while APP is not a global variable, if I execute the same function multiple times, each time the APP will get appended. To workaround this problem, I need to do APP.pop() inside the function or explicitly called the function with an argument (test([])). del APP or reassign APP=[] inside the function does not resolve the problem same thing happens if the function is defined as an method inside a class. Here is a little test program for testing: def test(APP=[]): if len(APP) == 0: APP.append('1abc') print "APP=", APP APP.append('2def') class test1 (object): def t1(self, abc=[]): abc.append('abc') print abc if __name__ == '__main__': print "class test" t = test1() i = 0 while i < 3: t.t1() i += 1 print "Test function::" i = 0 while i < 3: test() i += 1 Here are the output: class test ['abc'] ['abc', 'abc'] ['abc', 'abc', 'abc'] Test function:: APP= ['1abc'] APP= ['1abc', '2def'] APP= ['1abc', '2def', '2def'] ---------- components: Interpreter Core messages: 236185 nosy: yappyta priority: normal severity: normal status: open title: A list arg with default value inside function got appended each time the function is called type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 18:54:27 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Feb 2015 17:54:27 +0000 Subject: [issue23478] A list arg with default value inside function got appended each time the function is called In-Reply-To: <1424281809.58.0.308788589404.issue23478@psf.upfronthosting.co.za> Message-ID: <1424282067.93.0.40312634968.issue23478@psf.upfronthosting.co.za> Benjamin Peterson added the comment: http://effbot.org/zone/default-values.htm ---------- nosy: +benjamin.peterson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 19:12:38 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 18 Feb 2015 18:12:38 +0000 Subject: [issue5739] Language reference is ambiguous regarding next() method lookup In-Reply-To: <1239497907.46.0.481458734082.issue5739@psf.upfronthosting.co.za> Message-ID: <1424283158.16.0.634070337126.issue5739@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Still true in the current doc https://docs.python.org/3/reference/datamodel.html#special-method-names object.__iter__ in listed in 3.3.6. Emulating container types A listing for __next__ could follow that. Both iterator special methods are documented in https://docs.python.org/3/library/stdtypes.html#iterator-types ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 19:18:34 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 18 Feb 2015 18:18:34 +0000 Subject: [issue23477] Increase coverage for wsgiref module In-Reply-To: <1424271437.72.0.0459822564302.issue23477@psf.upfronthosting.co.za> Message-ID: <1424283514.35.0.634252901792.issue23477@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 19:24:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 18 Feb 2015 18:24:20 +0000 Subject: [issue22364] Improve some re error messages using regex for hints In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1424283860.41.0.0700743030873.issue22364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch for regex which makes some error messages be the same as in re with re_errors_2.patch. You could apply it to regex if new error messages look better than old error messages. Otherwise we could change re error messages to match regex, or discuss better variants. ---------- Added file: http://bugs.python.org/file38171/regex_errors.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 19:49:40 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Feb 2015 18:49:40 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1424285380.95.0.835568213432.issue23342@psf.upfronthosting.co.za> R. David Murray added the comment: string vs list: see issue 6760 for some background. Yes, I think it is an API bug, but there is no consensus for fixing it (it would require a deprecation period). Jeff: in general your points to do not seem to be apropos to this particular proposed enhancement, but are instead addressing other aspects of subprocess and should be dealt with in other targeted issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 20:19:07 2015 From: report at bugs.python.org (Link Mauve) Date: Wed, 18 Feb 2015 19:19:07 +0000 Subject: [issue22623] Missing guards for some POSIX functions In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za> Message-ID: <1424287147.84.0.825318029118.issue22623@psf.upfronthosting.co.za> Changes by Link Mauve : Added file: http://bugs.python.org/file38172/getedig.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 20:27:04 2015 From: report at bugs.python.org (PJ Eby) Date: Wed, 18 Feb 2015 19:27:04 +0000 Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za> Message-ID: <1424287624.44.0.58941145863.issue18610@psf.upfronthosting.co.za> PJ Eby added the comment: This area of the spec is different between 333 and 3333 precisely to clarify this point, without technically changing conformance requirements. PEP 333 was supposed to require the app to supply an argument, while PEP 3333 was changed to encourage the server to allow the app to omit it. It's an annoying grey area in the spec itself, but not at all a grey area for for the validation tool, which is supposed to validate the strictest interpretation of the spec. A conformant server is allowed to not work with a missing argument, so it's a bad idea for your app to omit it if you want to run on all conformant servers. (And this is entirely independent of whether it's a good idea to read the entire stream in the first place.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 20:38:21 2015 From: report at bugs.python.org (Link Mauve) Date: Wed, 18 Feb 2015 19:38:21 +0000 Subject: [issue22623] Missing guards for some POSIX functions In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za> Message-ID: <1424288301.86.0.0326666757066.issue22623@psf.upfronthosting.co.za> Changes by Link Mauve : Added file: http://bugs.python.org/file38173/getedig.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 21:29:10 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 18 Feb 2015 20:29:10 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <1424291350.08.0.762194487828.issue23400@psf.upfronthosting.co.za> Davin Potts added the comment: Attaching revised patches with improved phrasing in the changes to the docs. Thanks goes to Berker for reviewing and providing helpful feedback, especially paying close attention to detail in the docs. ---------- Added file: http://bugs.python.org/file38174/issue23400_py35_and_py34_improveddocs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 21:29:43 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 18 Feb 2015 20:29:43 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <1424291383.65.0.372018769409.issue23400@psf.upfronthosting.co.za> Changes by Davin Potts : Added file: http://bugs.python.org/file38175/issue23400_py27_improveddocs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 22:56:15 2015 From: report at bugs.python.org (Mahmoud Hashemi) Date: Wed, 18 Feb 2015 21:56:15 +0000 Subject: [issue23479] str.format() breaks object duck typing Message-ID: <1424296575.91.0.194467251728.issue23479@psf.upfronthosting.co.za> New submission from Mahmoud Hashemi: While porting some old code, I found some interesting misbehavior in the new-style string formatting. When formatting objects which support int and float conversion, old-style percent formatting works great, but new-style formatting explodes hard. Here's a basic example: class MyType(object): def __init__(self, func): self.func = func def __float__(self): return float(self.func()) print '%f' % MyType(lambda: 3) # Output (python2 and python3): 3.000000 print '{:f}'.format(MyType(lambda: 3)) # Output (python2): # Traceback (most recent call last): # File "tmp.py", line 28, in # print '{:f}'.format(MyType(lambda: 3)) # ValueError: Unknown format code 'f' for object of type 'str' # # Output (python3.4): # Traceback (most recent call last): # File "tmp.py", line 30, in # print('{:f}'.format(MyType(lambda: 3))) # TypeError: non-empty format string passed to object.__format__ And the same holds true for int and so forth. I would expect these behaviors to be the same between the two formatting styles, and tangentially, expect a more python2-like error message for the python 3 case. ---------- messages: 236192 nosy: mahmoud priority: normal severity: normal status: open title: str.format() breaks object duck typing type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:00:46 2015 From: report at bugs.python.org (Mahmoud Hashemi) Date: Wed, 18 Feb 2015 22:00:46 +0000 Subject: [issue23479] str.format() breaks object duck typing In-Reply-To: <1424296575.91.0.194467251728.issue23479@psf.upfronthosting.co.za> Message-ID: <1424296846.32.0.531387167064.issue23479@psf.upfronthosting.co.za> Changes by Mahmoud Hashemi : ---------- nosy: +Mark.Williams _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:07:56 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Feb 2015 22:07:56 +0000 Subject: [issue23479] str.format() breaks object duck typing In-Reply-To: <1424296575.91.0.194467251728.issue23479@psf.upfronthosting.co.za> Message-ID: <1424297276.3.0.213291833148.issue23479@psf.upfronthosting.co.za> Martin Panter added the comment: My guess is you could make it work by adding a __format__ method to your custom class. def __format__(self, format_spec): return format(float(self), format_spec) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:09:41 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Feb 2015 22:09:41 +0000 Subject: [issue23479] str.format() breaks object duck typing In-Reply-To: <1424296575.91.0.194467251728.issue23479@psf.upfronthosting.co.za> Message-ID: <1424297381.38.0.632281748456.issue23479@psf.upfronthosting.co.za> R. David Murray added the comment: This is an intentional change. See issue 7994 for the motivation. This was mentioned in the whatsnew documentation for 3.4. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:23:57 2015 From: report at bugs.python.org (Zorigt Bazarragchaa) Date: Wed, 18 Feb 2015 22:23:57 +0000 Subject: [issue23480] Minor typo Message-ID: <1424298237.21.0.795168205464.issue23480@psf.upfronthosting.co.za> New submission from Zorigt Bazarragchaa: I found a syntax type in your demo example on https://docs.python.org/2/library/json.html >>> print json.dumps({"c": 0, "b": 0, "a": 0}, sort_keys=True) {"a": 0, "b": 0, "c": 0} The correct return should be a 'str' type not json. Therefore: >>> print json.dumps({"c": 0, "b": 0, "a": 0}, sort_keys=True) '{"a": 0, "b": 0, "c": 0}' ---------- components: Demos and Tools messages: 236195 nosy: zorigt priority: normal severity: normal status: open title: Minor typo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:27:29 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 18 Feb 2015 22:27:29 +0000 Subject: [issue23479] str.format() breaks object duck typing In-Reply-To: <1424296575.91.0.194467251728.issue23479@psf.upfronthosting.co.za> Message-ID: <1424298449.35.0.644242643429.issue23479@psf.upfronthosting.co.za> Eric V. Smith added the comment: As David says, the change from: ValueError: Unknown format code 'f' for object of type 'str' to: TypeError: non-empty format string passed to object.__format__ is quite intentional. Let me address the differences between %-formatting and __format__-based formatting. In these examples, let's say you're trying to format an object o=MyType(whatever). With your '%f' example, you're saying "please convert o to a float, and then format and print the result". The %-formatting code knows a priori that the type must be converted to a float. With your {:f} example, you're saying "please call o.__format__('f'), and print the result". Nowhere is there any logic that says "well, f must mean that o must be converted to a float". The decision on conversion (if any) is left to MyType.__format__, as are all other formatting decisions. You could write something like: class MyType(object): def __format__(self, fmt): if fmt.endswith('f'): return float(self.func()).__format__(fmt) elif fmt.endswith('d'): return int(self.func()).__format__(fmt) else: return str(self.func()).__format__(fmt) def __init__(self, func): self.func = func print(format(MyType(lambda: 3), '.12f')) # produces "3.000000000000" print(format(MyType(lambda: 3), '05d')) # produces "00003" print(format(MyType(lambda: 3), '*^10s')) # produces "****3*****" Note that %-formatting only supports a fixed and limited number of types: basically int, float, and str. It cannot support new type of objects with their own format strings. With __format__-formatting, every type can specify how it wants to be formatted, and can specify its own format language. For example, datetime supports a rich formatting language (based on strftime). ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:36:24 2015 From: report at bugs.python.org (Mahmoud Hashemi) Date: Wed, 18 Feb 2015 22:36:24 +0000 Subject: [issue23479] str.format() breaks object duck typing In-Reply-To: <1424296575.91.0.194467251728.issue23479@psf.upfronthosting.co.za> Message-ID: <1424298984.16.0.245742764766.issue23479@psf.upfronthosting.co.za> Mahmoud Hashemi added the comment: Well, thank you for the prompt and helpful replies everyone. Can't say I didn't wish the default behavior were more intuitive, but at least I think I have an idea how to work this. Thanks again! ---------- resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:37:52 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 18 Feb 2015 22:37:52 +0000 Subject: [issue23479] str.format() breaks object duck typing In-Reply-To: <1424296575.91.0.194467251728.issue23479@psf.upfronthosting.co.za> Message-ID: <1424299072.01.0.906546703972.issue23479@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:38:55 2015 From: report at bugs.python.org (SilentGhost) Date: Wed, 18 Feb 2015 22:38:55 +0000 Subject: [issue23480] Minor typo In-Reply-To: <1424298237.21.0.795168205464.issue23480@psf.upfronthosting.co.za> Message-ID: <1424299135.78.0.239770672372.issue23480@psf.upfronthosting.co.za> SilentGhost added the comment: If you run the command in your interpreter you'll see that the output is correct. ---------- assignee: -> docs at python components: +Documentation -Demos and Tools nosy: +SilentGhost, docs at python resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:41:20 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 18 Feb 2015 22:41:20 +0000 Subject: [issue23480] Minor typo In-Reply-To: <1424298237.21.0.795168205464.issue23480@psf.upfronthosting.co.za> Message-ID: <1424299280.25.0.759134951038.issue23480@psf.upfronthosting.co.za> Martin Panter added the comment: It returns a string, and the print statement/function prints the contents of that string. Perhaps you are confused between JSON strings, which appear in the output, and Python strings, which hold the characters to output. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 18 23:55:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Feb 2015 22:55:44 +0000 Subject: [issue23354] Loading 2 GiLOC file which raises exception causes wrong traceback In-Reply-To: <1422675641.92.0.509373230042.issue23354@psf.upfronthosting.co.za> Message-ID: <1424300144.19.0.692777890704.issue23354@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 00:06:05 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Feb 2015 23:06:05 +0000 Subject: [issue3609] does parse_header really belong in CGI module? In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za> Message-ID: <1424300765.01.0.781603670866.issue3609@psf.upfronthosting.co.za> R. David Murray added the comment: There is no reason to move this to the email package. email can already parse headers just fine. It might be useful to have a parse_header utility method, though, since currently the easiest way to parse a single header using the email package is: >>> from email.policy import HTTP >>> from email.parser import Parser >>> m = Parser(policy=HTTP).parsestr('Content-Type: text/plain; filename="foo"\n\n') >>> m['Content-Type'].content_type 'text/plain' >>> m['Content-type'].params mappingproxy({'filename': 'foo'}) Which isn't as straightforward as the parse_header API when you are only interested in a single header. It might also be useful to have the email MIME headers grow a 'value' attribute to return whatever the value is (in this case, text/plain), so it can be accessed regardless of the header type. I would make parse_header be a utility method of the policy, I think. Then the email API would be: from email.policy import HTTP h = HTTP.parse_header('Content-Type: ...') value, params = h.value, h.params It would then be trivial to implement the backward compatibility shim for the CGI parse_header method using the above. ---------- stage: patch review -> needs patch versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 00:24:47 2015 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 18 Feb 2015 23:24:47 +0000 Subject: [issue22364] Improve some re error messages using regex for hints In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1424301887.07.0.23759054994.issue22364@psf.upfronthosting.co.za> Matthew Barnett added the comment: Some error messages use the indefinite article: "expected a bytes-like object, %.200s found" "cannot use a bytes pattern on a string-like object" "cannot use a string pattern on a bytes-like object" but others don't: "expected string instance, %.200s found" "expected str instance, %.200s found" Messages tend to be abbreviated, so I think that it would be better to just omit the article. I don't think that the error message "bad repeat interval" is an improvement (Why is it "bad"? What is an "interval"?). I think that saying that the min is greater than the max is clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 01:54:56 2015 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 19 Feb 2015 00:54:56 +0000 Subject: [issue23481] SSL module should not offer RC4 based cipher suites for clients by default Message-ID: <1424307296.49.0.474882830169.issue23481@psf.upfronthosting.co.za> New submission from Alex Gaynor: In addition to the security concerns, it is now a violation of RFC7465 to offer a cipher suite with RC4 in a ClientHello: https://tools.ietf.org/html/rfc7465 ---------- components: Library (Lib) files: rc4.diff keywords: patch messages: 236202 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou priority: normal severity: normal status: open title: SSL module should not offer RC4 based cipher suites for clients by default versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38176/rc4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 01:56:55 2015 From: report at bugs.python.org (Ian Cordasco) Date: Thu, 19 Feb 2015 00:56:55 +0000 Subject: [issue23481] SSL module should not offer RC4 based cipher suites for clients by default In-Reply-To: <1424307296.49.0.474882830169.issue23481@psf.upfronthosting.co.za> Message-ID: <1424307415.15.0.706853526709.issue23481@psf.upfronthosting.co.za> Ian Cordasco added the comment: It's clearly no longer acceptable to include RC4 when the IETF has felt it necessary to publish an RFC prohibiting its usage. ---------- nosy: +icordasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 02:10:19 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 19 Feb 2015 01:10:19 +0000 Subject: [issue23482] sqlite3_d.dll is not included in installer Message-ID: <1424308219.39.0.206852062326.issue23482@psf.upfronthosting.co.za> New submission from Steve Dower: This file is necessary for _sqlite3 to be importable with the debug binaries. ---------- assignee: steve.dower components: Installation, Windows messages: 236204 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: sqlite3_d.dll is not included in installer type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 02:55:36 2015 From: report at bugs.python.org (Ben Hoyt) Date: Thu, 19 Feb 2015 01:55:36 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1424310936.71.0.0263467904342.issue22524@psf.upfronthosting.co.za> Ben Hoyt added the comment: BTW, I replied to Victor privately, but for the thread: no worries, and apology accepted! :-) I'm working on updating my C patch with his feedback, and will update this issue hopefully in the next few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 03:02:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Feb 2015 02:02:41 +0000 Subject: [issue23482] sqlite3_d.dll is not included in installer In-Reply-To: <1424308219.39.0.206852062326.issue23482@psf.upfronthosting.co.za> Message-ID: <20150219020238.29688.80242@psf.io> Roundup Robot added the comment: New changeset 70a55b2dee71 by Steve Dower in branch 'default': Closes #23482: sqlite3_d.dll is not included in installer https://hg.python.org/cpython/rev/70a55b2dee71 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 03:09:56 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 19 Feb 2015 02:09:56 +0000 Subject: [issue11717] conflicting definition of ssize_t in pyconfig.h In-Reply-To: <1301443864.94.0.799403342642.issue11717@psf.upfronthosting.co.za> Message-ID: <1424311796.38.0.793796265153.issue11717@psf.upfronthosting.co.za> Steve Dower added the comment: Patch needs updating, and I'd expect pyport.h to start by checking if HAVE_PY_SSIZE_T is defined. Otherwise, we may try to re-typedef Py_ssize_t. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 03:13:48 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 19 Feb 2015 02:13:48 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1424312028.65.0.177241431387.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: Last call before I let the buildbots be the reviewers :) ---------- priority: normal -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 03:16:23 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 19 Feb 2015 02:16:23 +0000 Subject: [issue1559298] test_popen fails on Windows if installed to "Program Files" Message-ID: <1424312183.04.0.447410533321.issue1559298@psf.upfronthosting.co.za> Steve Dower added the comment: The docs are pretty clear about using Popen instead of os.popen, and people using popen have likely worked around it already, so we're more likely to break them by changing it now. I vote to close. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 03:39:32 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Feb 2015 02:39:32 +0000 Subject: [issue3609] does parse_header really belong in CGI module? In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za> Message-ID: <1424313572.38.0.0206356784897.issue3609@psf.upfronthosting.co.za> Martin Panter added the comment: HTTP policy sounds as good a place as any, especially if/when it is blessed as a stable API. Another related function is the undocumented http.cookiejar.split_header_words(), which seems more flexible than cgi.parse_headers(). It accepts multiple and comma-separated header values, splits on spaces as well as semicolons, and retains parameters without equal signs. Currently I have code that abuses the Message.get_params() and get_param() methods, which could probably benefit from split_header_words(): # Parse RTSP Transport headers like # Transport: RTP/AVP/TCP;interleaved=0-1, RTP/AVP;unicast;client_port=5004 for value in header_list(self.headers, "Transport"): # Splits at commas header = email.message.Message() # Default get_params() header is Content-Type header["Content-Type"] = value [transport, _] = header.get_params()[0] # Gets the RTP/AVP part mode = header.get_param("mode", "PLAY") channel = header.get_param("interleaved") if header.get_param("unicast") is not None: port = header.get_param("client_port") ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 05:00:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 19 Feb 2015 04:00:03 +0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1424318403.17.0.429882644258.issue2211@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 05:08:55 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 19 Feb 2015 04:08:55 +0000 Subject: [issue3609] does parse_header really belong in CGI module? In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za> Message-ID: <1424318935.01.0.51690122106.issue3609@psf.upfronthosting.co.za> R. David Murray added the comment: We can also add a parser for that format to headerregistry. Is there an RFC that describes it? (It should probably be a separate issue.) The new email API will be promoted to stable in 3.5. Mostly I just need to update the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 05:27:27 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 19 Feb 2015 04:27:27 +0000 Subject: [issue3609] does parse_header really belong in CGI module? In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za> Message-ID: <1424320047.07.0.884083571288.issue3609@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 05:31:14 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 19 Feb 2015 04:31:14 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1424320274.44.0.122621618895.issue3566@psf.upfronthosting.co.za> R. David Murray added the comment: It is possible to break backward compatibility in a feature release if the break is fixing a bug. In this case I think it is in fact doing so, and that in fact in the majority of cases the change would either not break existing code or would even improve it (by making debugging easier). However, I have no way to prove that. Often in the cases of compatibility breaks we will do a deprecation of the old behavior in a given release and make the change in the next release. I'm not convinced that is necessary (or even possible) here. It would be nice if we could get some data on what the actual impact would be on existing code. For example: how, if at all, would this affect the requests package? I *can* give one data point: in an application I wrote recently the affect would be zero, since every place in my application that I catch BadStatusLine I also catch ConnectionError. I would want at least one other committer to sign off on a compatibility break before anything got committed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 09:30:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Feb 2015 08:30:18 +0000 Subject: [issue433028] SRE: (?flag:...) is not supported Message-ID: <1424334618.43.0.31568784149.issue433028@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 09:53:54 2015 From: report at bugs.python.org (Scholes C) Date: Thu, 19 Feb 2015 08:53:54 +0000 Subject: [issue23483] python 2.7 builds using icc Message-ID: <1424336034.12.0.170693655501.issue23483@psf.upfronthosting.co.za> New submission from Scholes C: HI, can you please look into this ? thanks. icc builds of python 2.7 seem to have issues handling nan, inf, etc $ /usr/local/python-2.7.6/bin/python Python 2.7.6 (default, Jan 10 2014, 12:14:02) [GCC Intel(R) C++ gcc 4.1 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print float('nan') 0.0 $ /usr/local/python-2.6.6-64bit/bin/python Python 2.6.6 (r266:84292, Oct 14 2010, 15:47:19) [GCC Intel(R) C++ gcc 4.1 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print float('nan') nan I tried both ?fp-model strict and ?fp-model precise compiler options as suggested by http://bugs.python.org/issue21167, but neither seems to resolve other situations like the one with atan2 below: $ LD_LIBRARY_PATH=/dat/sharefolder_scratch/python-build ./python Python 2.7.9 (default, Feb 18 2015, 19:58:37) [GCC Intel(R) C++ gcc 4.1 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print float('nan') nan >>> import math >>> print math.atan2(0, float('nan')) 0.0 $ /usr/local/python-2.6.6-64bit/bin/python Python 2.6.6 (r266:84292, Oct 14 2010, 15:47:19) [GCC Intel(R) C++ gcc 4.1 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> print math.atan2(0, float('nan')) nan ---------- components: Interpreter Core messages: 236213 nosy: Scholes.C priority: normal severity: normal status: open title: python 2.7 builds using icc type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 10:19:28 2015 From: report at bugs.python.org (SilentGhost) Date: Thu, 19 Feb 2015 09:19:28 +0000 Subject: [issue23483] python 2.7 builds using icc In-Reply-To: <1424336034.12.0.170693655501.issue23483@psf.upfronthosting.co.za> Message-ID: <1424337568.52.0.31471038055.issue23483@psf.upfronthosting.co.za> SilentGhost added the comment: I suggest you add this information to issue21167 as it's exactly the same behaviour you're seeing. There really is no need to have a separate issue. ---------- nosy: +SilentGhost status: open -> closed superseder: -> float('nan') returns 0.0 on Python compiled with icc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 12:31:14 2015 From: report at bugs.python.org (Teodor Dima) Date: Thu, 19 Feb 2015 11:31:14 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid Message-ID: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> New submission from Teodor Dima: The keyword for 'blocking' in the documentation for multiprocessing.Lock.acquire() (and all synchronization objects dependent on SemLock) differs from its implementation at Modules/_multiprocessing/semaphore.c:70 - https://docs.python.org/3.4/library/threading.html#threading.Lock.acquire ---------- components: Extension Modules messages: 236215 nosy: td priority: normal severity: normal status: open title: SemLock acquire() keyword arg 'blocking' is invalid type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 14:32:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Feb 2015 13:32:55 +0000 Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module Message-ID: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za> New submission from STINNER Victor: The implementation of the PEP 475 has to modify the following functions to restart on EINTR (and recompute the timeout): * select.select() * select.poll() * select.epoll.poll() * select.devpoll.poll() * select.kqueue.control() * selectors.SelectSelector.select() and other selector classes See also issues #18885 and #23285. ---------- components: Extension Modules messages: 236216 nosy: haypo, neologix priority: normal severity: normal status: open title: PEP 475: handle EINTR in the select and selectors module versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 15:43:09 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 19 Feb 2015 14:43:09 +0000 Subject: [issue23483] python 2.7 builds using icc In-Reply-To: <1424336034.12.0.170693655501.issue23483@psf.upfronthosting.co.za> Message-ID: <1424356989.14.0.653291017523.issue23483@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> duplicate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 16:27:44 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Feb 2015 15:27:44 +0000 Subject: [issue10641] kill_python sometimes fails to kill processes on buildbots In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za> Message-ID: <1424359664.12.0.211518621735.issue10641@psf.upfronthosting.co.za> Mark Lawrence added the comment: I don't recall seeing this flagged anywhere else so can we close it as out of date? ---------- components: +Windows -Build nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 16:32:09 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Feb 2015 15:32:09 +0000 Subject: [issue14559] (2.7.3 Regression) PC\8.0 directory can no longer be used to build on windows In-Reply-To: <1334215463.37.0.843460683269.issue14559@psf.upfronthosting.co.za> Message-ID: <1424359929.64.0.295586401858.issue14559@psf.upfronthosting.co.za> Mark Lawrence added the comment: Presumably this can be closed as fixed? ---------- components: +Windows -Build nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 16:33:55 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 19 Feb 2015 15:33:55 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1424360035.84.0.810500500119.issue23441@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good to me. I prefer 4 space indent as well, and since we have essentially deprecated the use of tabs for spacing in Python, I'd rather not reintroduce it here for the (minor) benefit of making backspacing easier. Just think about the copy and paste consequences.... I'll miss vi's autoindent more than I will smart backspace, but python never had that to start with so I'm not asking for it :). I presume someone could add an enhancement for smart backspace if they were motivated to do so, but I'd say that is a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 16:40:00 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Feb 2015 15:40:00 +0000 Subject: [issue14672] Windows installer: add desktop shortcut(s) In-Reply-To: <1335414011.97.0.984037154974.issue14672@psf.upfronthosting.co.za> Message-ID: <1424360400.23.0.901311008601.issue14672@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've never felt the need for these shortcuts but what do the rest of you guys think about it? ---------- components: +Windows nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 17:03:43 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Feb 2015 16:03:43 +0000 Subject: [issue16111] Python 2.7.3 Windows MSI installer installs the VC++ 9 dlls directly to WinSxS folder In-Reply-To: <1349201780.49.0.563700308951.issue16111@psf.upfronthosting.co.za> Message-ID: <1424361823.68.0.876797006838.issue16111@psf.upfronthosting.co.za> Mark Lawrence added the comment: Given the comments in msg194081 can we close this as "not a bug"? ---------- components: +Windows nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 17:12:50 2015 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 19 Feb 2015 16:12:50 +0000 Subject: [issue16111] Python 2.7.3 Windows MSI installer installs the VC++ 9 dlls directly to WinSxS folder In-Reply-To: <1349201780.49.0.563700308951.issue16111@psf.upfronthosting.co.za> Message-ID: <1424362370.71.0.276487361909.issue16111@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 17:20:51 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 19 Feb 2015 16:20:51 +0000 Subject: [issue14672] Windows installer: add desktop shortcut(s) In-Reply-To: <1335414011.97.0.984037154974.issue14672@psf.upfronthosting.co.za> Message-ID: <1424362851.56.0.829973018525.issue14672@psf.upfronthosting.co.za> Steve Dower added the comment: Not going to happen. The desktop is for users, not installers, and apps installing shortcuts all over it is one of the reasons we got the Start Screen in Windows 8 (where only users can add items - no way for installers to do it). Besides, such an option would be off by default, which means you're probably looking at more than three clicks to enable it in the installer. Users can easily pin it to the taskbar or copy the shortcut to the desktop, and admins can push out a shortcut to all users on their network if they like. Either option is better than the installer doing it. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 17:21:44 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 19 Feb 2015 16:21:44 +0000 Subject: [issue14559] (2.7.3 Regression) PC\8.0 directory can no longer be used to build on windows In-Reply-To: <1334215463.37.0.843460683269.issue14559@psf.upfronthosting.co.za> Message-ID: <1424362904.58.0.743880256065.issue14559@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 17:23:24 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 19 Feb 2015 16:23:24 +0000 Subject: [issue10641] kill_python sometimes fails to kill processes on buildbots In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za> Message-ID: <1424363004.6.0.617127960758.issue10641@psf.upfronthosting.co.za> Steve Dower added the comment: Not sure if this still affects 2.7, but it doesn't affect 3.5 anymore. If one of the buildbot owners confirms that 2.7 is fine, I'll close. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 17:24:20 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Feb 2015 16:24:20 +0000 Subject: [issue9119] Python download page needs to mention crypto code in Windows installer In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za> Message-ID: <1424363060.68.0.240272842854.issue9119@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Terry it does not look as if the download pages were ever updated so can you follow this up please? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 18:08:14 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Feb 2015 17:08:14 +0000 Subject: [issue19792] pathlib does not support symlink in Windows XP In-Reply-To: <1385451814.33.0.666998936425.issue19792@psf.upfronthosting.co.za> Message-ID: <1424365694.27.0.688770198751.issue19792@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've read the entire issue and don't believe there's anything to be done here. Plus the originator says in msg204557 "But anyway feel free to close this ticket". ---------- components: +Windows nosy: +BreamoreBoy, steve.dower, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 18:11:13 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 19 Feb 2015 17:11:13 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1424365873.33.0.589294981408.issue23439@psf.upfronthosting.co.za> Demian Brecht added the comment: Left a super minor comment in Rietveld, but otherwise LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 18:11:33 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 19 Feb 2015 17:11:33 +0000 Subject: [issue21257] Document parse_headers function of http.client In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za> Message-ID: <1424365893.08.0.921832147466.issue21257@psf.upfronthosting.co.za> Demian Brecht added the comment: Ignore my previous comment. It was intended for #23439. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 18:45:38 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 19 Feb 2015 17:45:38 +0000 Subject: [issue19792] pathlib does not support symlink in Windows XP In-Reply-To: <1385451814.33.0.666998936425.issue19792@psf.upfronthosting.co.za> Message-ID: <1424367938.16.0.204309095661.issue19792@psf.upfronthosting.co.za> Steve Dower added the comment: Sounds good to me. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 19:23:33 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Feb 2015 18:23:33 +0000 Subject: [issue20589] pathlib.owner() and pathlib.group() raise ImportError on Windows In-Reply-To: <1392089109.39.0.748049843739.issue20589@psf.upfronthosting.co.za> Message-ID: <1424370213.82.0.819369170954.issue20589@psf.upfronthosting.co.za> Mark Lawrence added the comment: Just to note that 3.5 still raises ImportError rather than NotImplementedError although the latter is the consensus here. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 19:39:19 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Feb 2015 18:39:19 +0000 Subject: [issue20717] test_4_daemon_threads() fails randomly on "x86 Windows Server 2003 [SB] 3.x" In-Reply-To: <1392973435.96.0.316031564004.issue20717@psf.upfronthosting.co.za> Message-ID: <1424371159.3.0.465413195762.issue20717@psf.upfronthosting.co.za> Mark Lawrence added the comment: The "AMD64 Windows7 SP1 3.x" buildbot is currently green although it did fail at Feb 18 02:17. The "x86 Windows Server 2003 [SB] 3.4" has been showing an exception for the last two days. I'm sorry but I do not know how to investigate this further myself. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 19:44:54 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Feb 2015 18:44:54 +0000 Subject: [issue8075] Windows (Vista/7) install error when choosing to compile .py files In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za> Message-ID: <1424371494.77.0.330681572832.issue8075@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Steve what is your take on this issue? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 20:05:22 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 19 Feb 2015 19:05:22 +0000 Subject: [issue8075] Windows (Vista/7) install error when choosing to compile .py files In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za> Message-ID: <1424372722.06.0.0798655546132.issue8075@psf.upfronthosting.co.za> Steve Dower added the comment: I'm not interested in fixing the 2.7 installer, but patches are welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 20:45:32 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 19 Feb 2015 19:45:32 +0000 Subject: [issue9119] Python download page needs to mention crypto code in Windows installer In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za> Message-ID: <1424375132.49.0.906952569639.issue9119@psf.upfronthosting.co.za> Terry J. Reedy added the comment: No, this is really out of my ballpark. ---------- versions: +Python 3.5 -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 22:59:13 2015 From: report at bugs.python.org (Craig Holmquist) Date: Thu, 19 Feb 2015 21:59:13 +0000 Subject: [issue23486] Enum comparisons are 20x slower than comparing equivalent ints Message-ID: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> New submission from Craig Holmquist: Running the attached test script: $ time python test.py enum real 0m6.546s user 0m6.530s sys 0m0.007s $ time python test.py int real 0m0.384s user 0m0.377s sys 0m0.000s I encountered this with a script that yielded a sequence of objects (potentially a few hundred thousand of them) and categorized them with instances of an Enum subclass. The consumer of that iteration processes each object with a switch-case-like comparison of the category, checking it sequentially against each instance of the Enum. This seems like a fairly common use case. >From cProfile it looks like EnumMeta.__getattr__ and _is_dunder are the main bottlenecks: [...] 7/1 0.000 0.000 0.000 0.000 abc.py:194(__subclasscheck__) 1 0.000 0.000 0.001 0.001 enum.py:1() 3 0.000 0.000 0.000 0.000 enum.py:132() 2000021 0.988 0.000 0.988 0.000 enum.py:16(_is_dunder) 19 0.000 0.000 0.000 0.000 enum.py:24(_is_sunder) 2000002 1.825 0.000 2.813 0.000 enum.py:241(__getattr__) 17 0.000 0.000 0.000 0.000 enum.py:282(__setattr__) 3 0.000 0.000 0.000 0.000 enum.py:342(_get_mixins_) 3 0.000 0.000 0.000 0.000 enum.py:387(_find_new_) [...] ---------- components: Library (Lib) files: test.py messages: 236234 nosy: craigh priority: normal severity: normal status: open title: Enum comparisons are 20x slower than comparing equivalent ints type: performance versions: Python 3.4 Added file: http://bugs.python.org/file38177/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 23:03:28 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 19 Feb 2015 22:03:28 +0000 Subject: [issue23486] Enum comparisons are 20x slower than comparing equivalent ints In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> Message-ID: <1424383408.49.0.284509887302.issue23486@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 23:07:41 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 19 Feb 2015 22:07:41 +0000 Subject: [issue21257] Document parse_headers function of http.client In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za> Message-ID: <1424383661.56.0.291522608432.issue21257@psf.upfronthosting.co.za> Demian Brecht added the comment: And this really should likely now be closed as a duplicate of #23439. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 23:12:02 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 19 Feb 2015 22:12:02 +0000 Subject: [issue23486] Enum comparisons are 20x slower than comparing equivalent ints In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> Message-ID: <1424383922.1.0.193945991188.issue23486@psf.upfronthosting.co.za> Ethan Furman added the comment: Craig Holmquist wrote: --------------------- > The consumer of that iteration processes each object with a switch-case-like > comparison of the category, checking it sequentially against each instance > of the Enum. So for every object you compare against every Enum member? Is there a reason you don't just use the lookup capability? class Category(Enum): tiny = 1 medium = 2 large = 3 cat = Category(obj.category) # assumes obj.category is 1, 2, or 3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 23:19:34 2015 From: report at bugs.python.org (Craig Holmquist) Date: Thu, 19 Feb 2015 22:19:34 +0000 Subject: [issue23486] Enum comparisons are 20x slower than comparing equivalent ints In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> Message-ID: <1424384374.31.0.240525040421.issue23486@psf.upfronthosting.co.za> Craig Holmquist added the comment: I may not have been clear before. What I mean is, code like this: for obj in get_objects(): if obj.category == Cat.cat1: #do something elif obj.category == Cat.cat2: #do something else elif obj.category == Cat.cat3 or obj.category == Cat.cat4: #... obj.category is already an instance of Cat, in other words. The consumer is using it to determine what to do with each obj. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 23:22:52 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Feb 2015 22:22:52 +0000 Subject: [issue23481] SSL module should not offer RC4 based cipher suites for clients by default In-Reply-To: <1424307296.49.0.474882830169.issue23481@psf.upfronthosting.co.za> Message-ID: <1424384572.86.0.844448976644.issue23481@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sounds fine to me. Should a test be added? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 23:35:38 2015 From: report at bugs.python.org (Craig Holmquist) Date: Thu, 19 Feb 2015 22:35:38 +0000 Subject: [issue23486] Enum comparisons are 20x slower than comparing equivalent ints In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> Message-ID: <1424385338.96.0.354321261757.issue23486@psf.upfronthosting.co.za> Craig Holmquist added the comment: It seems like performance is drastically improved by doing this: class Category(Enum): tiny = 1 medium = 2 large = 3 tiny = Category.tiny medium = Category.medium In other words, resolving Category.tiny and Category.medium is what's slow. The comparison itself is very fast. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 19 23:58:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Feb 2015 22:58:26 +0000 Subject: [issue23481] SSL module should not offer RC4 based cipher suites for clients by default In-Reply-To: <1424307296.49.0.474882830169.issue23481@psf.upfronthosting.co.za> Message-ID: <20150219225824.10186.61697@psf.io> Roundup Robot added the comment: New changeset c509e6f18d7d by Benjamin Peterson in branch '3.4': remove rc4 from the default client ciphers (closes #23481) https://hg.python.org/cpython/rev/c509e6f18d7d New changeset 3596081cfb55 by Benjamin Peterson in branch '2.7': remove rc4 from the default client ciphers (closes #23481) https://hg.python.org/cpython/rev/3596081cfb55 New changeset 041a27298cf3 by Benjamin Peterson in branch 'default': merge 3.4 (#23481) https://hg.python.org/cpython/rev/041a27298cf3 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 00:27:28 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 19 Feb 2015 23:27:28 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1424388448.52.0.238896285549.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Posting RemoteDisconnected.v4.patch with these changes: * Renamed ConnectionClosed ? RemoteDisconnected. Hopefully avoids confusion with shutting down the local end of a connection, or closing a socket?s file descriptor. * Dropped the HTTPConnection.closed attribute * Dropped special distinction of ECONNRESET at start versus in middle of response. It certainly makes the code and tests simpler again, and I realize that distinction is not the most important problem to solve right now, if ever. Also avoids relying on the poorly defined BufferedReader.peek() method. I would like to retain the backwards compatibility with BadStatusLine if that is okay though. Requests and ?urllib3?: I?m not overly familiar with the internals of these packages (Requests uses ?urllib3?). I cannot find any reference to BadStatusLine handling in ?urllib3?, and I suspect it might just rely on detecting a dropped connection before sending a request; see . In my opinion this is a race condition, but it is helpful and works most of the time. So I suspect ?urllib3? would not be affected by any changes made relating to BadStatusLine. ---------- Added file: http://bugs.python.org/file38178/RemoteDisconnected.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 00:41:15 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 19 Feb 2015 23:41:15 +0000 Subject: [issue23486] Enum member lookup is 20x slower than normal class attribute lookup In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> Message-ID: <1424389275.6.0.260115687972.issue23486@psf.upfronthosting.co.za> Ethan Furman added the comment: Yup, you have it figured out. It's the lookup that is the slowdown. When performance is an issue one of the standard tricks is to create a local name, like you did with "tiny = Category.tiny". For the curious (taken from the docstring for Enum.__getattr__): We use __getattr__ instead of descriptors or inserting into the enum class' __dict__ in order to support `name` and `value` being both properties for enum members (which live in the class' __dict__) and enum members themselves. It is possible to store all the enum members /except/ for 'name' and 'value' in the class' __dict__, but I'm not sure it's worth the extra complication. ---------- title: Enum comparisons are 20x slower than comparing equivalent ints -> Enum member lookup is 20x slower than normal class attribute lookup _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 01:17:42 2015 From: report at bugs.python.org (Scholes C) Date: Fri, 20 Feb 2015 00:17:42 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1424391462.09.0.144078026991.issue21167@psf.upfronthosting.co.za> Scholes C added the comment: HI, can you please look into this ? thanks. icc builds of python 2.7 seem to have issues handling nan, inf, etc $ /usr/local/python-2.7.6/bin/python Python 2.7.6 (default, Jan 10 2014, 12:14:02) [GCC Intel(R) C++ gcc 4.1 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print float('nan') 0.0 $ /usr/local/python-2.6.6-64bit/bin/python Python 2.6.6 (r266:84292, Oct 14 2010, 15:47:19) [GCC Intel(R) C++ gcc 4.1 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print float('nan') nan I tried both ?fp-model strict and ?fp-model precise compiler options as suggested by http://bugs.python.org/issue21167, but neither seems to resolve other situations like the one with atan2 below: $ LD_LIBRARY_PATH=/dat/sharefolder_scratch/python-build ./python Python 2.7.9 (default, Feb 18 2015, 19:58:37) [GCC Intel(R) C++ gcc 4.1 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print float('nan') nan >>> import math >>> print math.atan2(0, float('nan')) 0.0 $ /usr/local/python-2.6.6-64bit/bin/python Python 2.6.6 (r266:84292, Oct 14 2010, 15:47:19) [GCC Intel(R) C++ gcc 4.1 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> print math.atan2(0, float('nan')) nan ---------- nosy: +Scholes.C _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 01:26:28 2015 From: report at bugs.python.org (Scholes C) Date: Fri, 20 Feb 2015 00:26:28 +0000 Subject: [issue21167] float('nan') returns 0.0 on Python compiled with icc In-Reply-To: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za> Message-ID: <1424391988.72.0.525421526877.issue21167@psf.upfronthosting.co.za> Scholes C added the comment: please disregard , the issue is resolved with your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 02:46:57 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 20 Feb 2015 01:46:57 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1424396817.62.0.765382904941.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: Left a few minor comments in Rietveld. My only opposition to the RemoteDisconnected error is now we have two exceptions that effectively mean the same thing. It looks like asyncio.streams has similar behaviour: https://hg.python.org/cpython/file/041a27298cf3/Lib/asyncio/streams.py#l193. I think that if it's acceptable to break backwards compatibility here, we should. Browsing through some Github repos, it seems like this change /could/ potentially impact a few smaller projects. I can confirm, however, that neither urllib3 nor requests are dependent on BadStatusLine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 03:05:25 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Feb 2015 02:05:25 +0000 Subject: [issue12855] linebreak sequences should be better documented In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za> Message-ID: <1424397925.62.0.436087697885.issue12855@psf.upfronthosting.co.za> Martin Panter added the comment: Posting linebreakdoc.v3.py3.5.patch: * Rebased onto recent ?default? (3.5) branch * Add missing 1C?1E codes * Dropped reference to ?universal newlines?, since that only handles CRs and LFs as I understand it The newlines are already tested by test_unicodedata.UnicodeMiscTest.test_linebreak_7643() when the VT and FF codes were added in Issue 7643. ---------- Added file: http://bugs.python.org/file38179/linebreakdoc.v3.py3.5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 04:44:30 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 20 Feb 2015 03:44:30 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424403870.06.0.953578632515.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I've started to work on the bzip module. I'll attach I work-in-progress patch if I get stuck or run out of time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 05:08:09 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Feb 2015 04:08:09 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1424405289.57.0.921269283259.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: I guess you saying RemoteDisconnected effectively means the same thing as ConnectionResetError. Would it help if it was derived from ConnectionResetError, instead of the ConnectionError base class? Or are you also worried about the multiple inheritance or clutter of yet another type of exception? I?m not really familiar with the ?asyncio? streams/protocols/transports/thingies, but it looks like the code you pointed to is actually called when writing, via drain(), fails. Maybe the equivalent code for when reading hits EOF is . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 05:14:23 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Feb 2015 04:14:23 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1424405663.91.0.402502953258.issue23439@psf.upfronthosting.co.za> Martin Panter added the comment: Posting v3 patch that changes from a list to a set of expected API names ---------- Added file: http://bugs.python.org/file38180/http.client-all.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 05:27:13 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Feb 2015 04:27:13 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1424406433.01.0.437537467756.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: Posting patch v3; thanks for the reviews! * Changed ?buffer? ? ?object? * Made it clearer that the bytes-like object generalization only applies to method arguments, not return values * Minor fixes to wording ---------- Added file: http://bugs.python.org/file38181/bytes-like-param.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 06:54:06 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Feb 2015 05:54:06 +0000 Subject: [issue22000] cross type comparisons clarification In-Reply-To: <1405622312.02.0.49093151571.issue22000@psf.upfronthosting.co.za> Message-ID: <1424411646.44.0.965812276361.issue22000@psf.upfronthosting.co.za> Martin Panter added the comment: I think the patch for Issue 12067 covers all of the suggested points here, and is more accurate in some cases. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 07:59:04 2015 From: report at bugs.python.org (BJ Dierkes) Date: Fri, 20 Feb 2015 06:59:04 +0000 Subject: [issue22848] Subparser help does not respect SUPPRESS argument In-Reply-To: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za> Message-ID: <1424415544.66.0.814822895603.issue22848@psf.upfronthosting.co.za> BJ Dierkes added the comment: I would like to add to this regarding the following: [QUOTE] Why would a user want to use `help=argparse.SUPPRESS`, as opposed to simply omitting the `help` parameter? The effect would be the same as your patch. [/QUOTE] This actually isn't the case, if you omit the 'help' option entirely, the sub-parser is still listed in the {short_list}. For example: import argparse root_parser = argparse.ArgumentParser(prog='myapp') root_parser.add_argument('--foo', action=CustomAction) sub_parsers = root_parser.add_subparsers(dest='commands', title='subcommands') sub_parser = sub_parsers.add_parser('sub-command-1', help='useless help txt') sub_parser = sub_parsers.add_parser('sub-command-2', help=argparse.SUPPRESS) sub_parser = sub_parsers.add_parser('sub-command-3') args = root_parser.parse_args() You end up with: $ python argtest.py --help usage: myapp [-h] [--foo FOO] {sub-command-1,sub-command-2,sub-command-3} ... optional arguments: -h, --help show this help message and exit --foo FOO subcommands: {sub-command-1,sub-command-2,sub-command-3} sub-command-1 useless help txt sub-command-2 ==SUPPRESS== The 'sub-command-3' is still listed in the {sub-parsers} .... where, if I want to hide a sub-parser... I don't want to see it anywhere. Would be ideal to have a 'hide=True' option for sub-parsers and arguments alike. All the same functionality, you just wouldn't see it in '--help'. ---------- nosy: +derks _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 08:24:03 2015 From: report at bugs.python.org (BJ Dierkes) Date: Fri, 20 Feb 2015 07:24:03 +0000 Subject: [issue23487] argparse: add_subparsers 'action' broken Message-ID: <1424417043.22.0.71313795028.issue23487@psf.upfronthosting.co.za> New submission from BJ Dierkes: Related: http://bugs.python.org/issue9253 I came across issue9253 in trying to implement a default action for a subparser namespace. In the absence of a 'default' option, I thought that it may be possible by adding an 'action' to 'add_subparsers'. Per the documentation this should be possible: https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers [QUOTE] action - the basic type of action to be taken when this argument is encountered at the command line [/QUOTE] That said, custom actions on 'add_subparsers' doesn't appear to work at all: import argparse class CustomAction(argparse.Action): def __call__(self, parser, namespace, values, option_string=None): print('Inside CustomAction') setattr(namespace, self.dest, values) root_parser = argparse.ArgumentParser(prog='myapp') sub_parser = root_parser.add_subparsers(dest='commands', action=CustomAction) args = root_parser.parse_args() Produces: $ python argtest.py --help Traceback (most recent call last): File "argtest.py", line 46, in sub_parser = root_parser.add_subparsers(dest='commands', action=CustomAction) File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/argparse.py", line 1661, in add_subparsers action = parsers_class(option_strings=[], **kwargs) TypeError: __init__() got an unexpected keyword argument 'prog' Erroneous documentation maybe? Tested the same on Python 2.7 and 3.3. ---------- components: Library (Lib) messages: 236254 nosy: derks priority: normal severity: normal status: open title: argparse: add_subparsers 'action' broken type: behavior versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 08:44:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 07:44:19 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <20150220074409.109548.54337@psf.io> Roundup Robot added the comment: New changeset 21b31f5438ae by Berker Peksag in branch '3.4': Issue #23439: Add missing entries to http.client.__all__. https://hg.python.org/cpython/rev/21b31f5438ae New changeset 95533c9edaaf by Berker Peksag in branch 'default': Issue #23439: Add missing entries to http.client.__all__. https://hg.python.org/cpython/rev/95533c9edaaf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 08:46:10 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 07:46:10 +0000 Subject: [issue23439] Fixed http.client.__all__ and added a test In-Reply-To: <1423608111.44.0.417026855918.issue23439@psf.upfronthosting.co.za> Message-ID: <1424418370.86.0.284845478608.issue23439@psf.upfronthosting.co.za> Berker Peksag added the comment: Committed now. Thanks for the patch, Martin and thanks for the review, Demian. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 09:59:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 08:59:21 +0000 Subject: [issue22364] Improve some re error messages using regex for hints In-Reply-To: <1424301887.07.0.23759054994.issue22364@psf.upfronthosting.co.za> Message-ID: <4704288.PGacdt14zg@raxxla> Serhiy Storchaka added the comment: > Messages tend to be abbreviated, so I think that it would be better to just > omit the article. I agree, but this is came from standard error messages which are not consistent. I opened a thread on Python-Dev. "expected a bytes-like object" and "expected str instance" are standard error messages raised in bytes.join and str.join, not in re. We could change them though. > I don't think that the error message "bad repeat interval" is an improvement > (Why is it "bad"? What is an "interval"?). I think that saying that the min > is greater than the max is clearer. Agree. I'll change this in re. What message is better in case of overflow: "the repetition number is too large" (in re) or "repeat count too big" (in regex)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 10:29:04 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 20 Feb 2015 09:29:04 +0000 Subject: [issue23486] Enum member lookup is 20x slower than normal class attribute lookup In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> Message-ID: <1424424544.38.0.867135676755.issue23486@psf.upfronthosting.co.za> Ethan Furman added the comment: Out of curiousity I tried: took two new lines, one modified line, and one comment. :) ---------- keywords: +patch Added file: http://bugs.python.org/file38182/issue23486.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 10:30:14 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 20 Feb 2015 09:30:14 +0000 Subject: [issue23486] Enum member lookup is 20x slower than normal class attribute lookup In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> Message-ID: <1424424614.6.0.296335625884.issue23486@psf.upfronthosting.co.za> Ethan Furman added the comment: Oh, and the slowdown dropped from 20 to 3 (for non-DynamicClassAttributes -- which is probably more than 99% of them). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 10:39:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Feb 2015 09:39:08 +0000 Subject: [issue23486] Enum member lookup is 20x slower than normal class attribute lookup In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> Message-ID: <1424425148.17.0.166307894581.issue23486@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand the patch, but 3x slower instead of 20x slower is a huge optimization :-) Do you plan to change Python 3.5 *and* Python 3.4? ---------- nosy: +haypo versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 10:39:24 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 20 Feb 2015 09:39:24 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1424425164.55.0.800846648989.issue23484@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:09:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 10:09:38 +0000 Subject: [issue21548] pydoc -k IndexError on empty docstring In-Reply-To: <1400661783.43.0.558471008968.issue21548@psf.upfronthosting.co.za> Message-ID: <20150220100935.4012.70723@psf.io> Roundup Robot added the comment: New changeset 43641e03692a by Berker Peksag in branch '2.7': Issue #21548: Fix pydoc.synopsis() and pydoc.apropos() on modules with empty https://hg.python.org/cpython/rev/43641e03692a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:10:26 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 10:10:26 +0000 Subject: [issue21548] pydoc -k IndexError on empty docstring In-Reply-To: <1400661783.43.0.558471008968.issue21548@psf.upfronthosting.co.za> Message-ID: <1424427026.79.0.403605478124.issue21548@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:18:42 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 20 Feb 2015 10:18:42 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds Message-ID: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The Modules/_randommodule.c implements the 32-bit version of the MersenneTwister and its struct uses (unsigned long) for each of the 624 elements of the state vector. On a 32-bit build, the unsigned longs are 4 bytes. However, on a 64-bit build, they are 8 bytes each eventhough only the bottom 32-bits are used. This causes the random object to be twice as big as necessary. sys.getsizeof(_random.Random()) reports 5016 bytes. This wastes memory, grinds the cache, and slows performance. The (unsigned long) declaration should probably be replaced with (uint32_t). ---------- assignee: rhettinger messages: 236262 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Random objects twice as big as necessary on 64-bit builds type: resource usage versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:18:59 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 20 Feb 2015 10:18:59 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424427539.15.0.397703177858.issue23488@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- components: +Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:33:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Feb 2015 10:33:31 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424428411.82.0.154736425339.issue23488@psf.upfronthosting.co.za> STINNER Victor added the comment: > The (unsigned long) declaration should probably be replaced with (uint32_t) Would it be possible to benchmark this change, to ensure that it doesn't kill performances? A quick micro-benchmark using timeit should be enough ;) I agree with the change, I already noticed the unused bits long time ago, when I took at look at the Mersenne Twister implementation. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:33:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Feb 2015 10:33:59 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424428439.85.0.0898524666348.issue23488@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, by the way, using 32 bits unsigned integers would avoid all the "& 0xffffffff" everywhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:42:26 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 20 Feb 2015 10:42:26 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424428946.69.0.590042974084.issue23488@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, I noticed this when reimplementing the random module in Numba. *Theoretically*, I think you need "long" to ensure ints are at least 32 bits. But in practice, I think CPython already needs 32-bit C ints. (note Numpy also uses C longs internally) > Would it be possible to benchmark this change, to ensure that it doesn't kill performances? There is no way it can kill performance. ---------- nosy: +mark.dickinson, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:42:33 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 20 Feb 2015 10:42:33 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424428953.8.0.792603018435.issue23488@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:50:45 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 20 Feb 2015 10:50:45 +0000 Subject: [issue23472] Setup locales on buildbots In-Reply-To: <1424184229.01.0.47372627635.issue23472@psf.upfronthosting.co.za> Message-ID: <1424429445.79.0.452795891546.issue23472@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Unfortunately, this is the kind of thing that must be asked individually to each buildbot owner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:51:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 10:51:30 +0000 Subject: [issue23018] Add version info to python In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1424429490.42.0.648148933287.issue23018@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PC/python_ver_rc.h now is not compatible with clinic.py. $ ./python Tools/clinic/clinic.py --make Traceback (most recent call last): File "Tools/clinic/clinic.py", line 4204, in sys.exit(main(sys.argv[1:])) File "Tools/clinic/clinic.py", line 4184, in main parse_file(path, force=ns.force, verify=not ns.force) File "Tools/clinic/clinic.py", line 1743, in parse_file raw = f.read() File "/home/serhiy/py/cpython/Lib/codecs.py", line 321, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa9 in position 199: invalid start byte Either convert PC/python_ver_rc.h to UTF-8, or escape copyright sign "?" as "\xa9" (if Latin1 is needed), or replace it witch ASCII "(c)". ---------- nosy: +serhiy.storchaka resolution: fixed -> stage: patch review -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 11:56:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 10:56:44 +0000 Subject: [issue23472] Setup locales on buildbots In-Reply-To: <1424184229.01.0.47372627635.issue23472@psf.upfronthosting.co.za> Message-ID: <1424429804.95.0.805948383227.issue23472@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be document this recommendation somewhere? If there is crossplatform script that tests buildbot configuration, may be add checks for locales in it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 12:00:09 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Feb 2015 11:00:09 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1424430009.85.0.0999751883095.issue12067@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 4395 is already open for the != delegating to __eq__ issue that Guido pointed out earlier. Yet another issue that this doc patch should solve: Issue 22000. I am posting v13 of the patch that works with the current ?default? (3.5) branch. Minor modifications to the documentation part: * Undo some paragraph reflowing to reduce the size of the diff hunks * Use math.nan instead of nan = float('NaN') * Tweaked the new subheadings to better differentiate ?Value comparisons? (which this bug is concerned with) from ?Identity comparisons? Changes I made to the added test cases: * Drop Python 3 version check * Use TestCase.subTest() so it?s easier to see everything that [is] was failing * Merge some tests for != and fix changed expectations due to Issue 21408 being fixed * Drop _inst_str() and __str__(), apparently unused It would be nice to see at least the documentation part reviewed and committed, even if the tests require more work. (After having to hack the tests to get them working, I might point out some odd bits in the code review.) Though I guess they are just tests, so it doesn?t matter so much as long as they pass. ---------- Added file: http://bugs.python.org/file38183/issue12067-expressions-py3.5_v13.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 12:09:04 2015 From: report at bugs.python.org (Alex Shkop) Date: Fri, 20 Feb 2015 11:09:04 +0000 Subject: [issue23477] Increase coverage for wsgiref module In-Reply-To: <1424271437.72.0.0459822564302.issue23477@psf.upfronthosting.co.za> Message-ID: <1424430544.1.0.807752072293.issue23477@psf.upfronthosting.co.za> Alex Shkop added the comment: Replaced "%s;%s;%s" with ';'.join() call. ---------- Added file: http://bugs.python.org/file38184/wsgiref_test_environ_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 12:10:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 11:10:04 +0000 Subject: [issue21257] Document parse_headers function of http.client In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za> Message-ID: <1424430604.04.0.509237587395.issue21257@psf.upfronthosting.co.za> Berker Peksag added the comment: This is a different issue than #23439. BaseHTTPRequestHandler.headers documentation mentions about parse_headers function, the function itself is not documented. See https://docs.python.org/3/library/http.server.html#http.server.BaseHTTPRequestHandler.headers ---------- components: +Documentation keywords: +easy nosy: +berker.peksag stage: -> needs patch type: behavior -> enhancement versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 12:30:43 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 11:30:43 +0000 Subject: [issue9119] Python download page needs to mention crypto code in Windows installer In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za> Message-ID: <1424431843.52.0.609612664878.issue9119@psf.upfronthosting.co.za> Berker Peksag added the comment: > Terry, would you like to move this forward with the Python.org webmasters ? This is now a content issue and can be handled on GitHub: https://github.com/python/pythondotorg/issues ---------- nosy: +berker.peksag resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 12:48:28 2015 From: report at bugs.python.org (juj) Date: Fri, 20 Feb 2015 11:48:28 +0000 Subject: [issue23489] atexit handlers are not executed when using multiprocessing.Pool.map. Message-ID: <1424432908.71.0.0710990700334.issue23489@psf.upfronthosting.co.za> New submission from juj: When Multiprocessing.Pool.map is used for a script that registers atexit handlers, the atexit handlers are not executed when the pool threads quit. STR: 1. Run attached file in Python 2.7 with 'python task_spawn.py' 2. Observe the printed output. Observed: Console prints: CREATED TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_qef8r_ CREATED TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_axi9tt CREATED TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_vx6fmu task1 task2 ATEXIT: REMOVING TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_qef8r_ Expected: Console should print: CREATED TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_qef8r_ CREATED TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_axi9tt CREATED TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_vx6fmu task1 task2 ATEXIT: REMOVING TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_vx6fmu ATEXIT: REMOVING TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_axi9tt ATEXIT: REMOVING TEMP DIRECTORY c:\users\clb\appdata\local\temp\temp_qef8r_ ---------- components: Library (Lib) files: task_spawn.py messages: 236273 nosy: juj priority: normal severity: normal status: open title: atexit handlers are not executed when using multiprocessing.Pool.map. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file38185/task_spawn.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 12:50:28 2015 From: report at bugs.python.org (juj) Date: Fri, 20 Feb 2015 11:50:28 +0000 Subject: [issue23489] atexit handlers are not executed when using multiprocessing.Pool.map. In-Reply-To: <1424432908.71.0.0710990700334.issue23489@psf.upfronthosting.co.za> Message-ID: <1424433028.74.0.675865407981.issue23489@psf.upfronthosting.co.za> juj added the comment: This was tested on Python 2.7.9 64-bit on Windows 8.1, however I believe that it occurs equally on OSX and Linux, since I am running servers with those OSes that also exhibit temp file leaking issues (although I did not specifically confirm if the root cause is the same as this). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 13:06:49 2015 From: report at bugs.python.org (paul) Date: Fri, 20 Feb 2015 12:06:49 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer Message-ID: <1424434009.7.0.146767591235.issue23490@psf.upfronthosting.co.za> New submission from paul: # Bug # --- # # Py_UNICODE * # PyUnicode_AsUnicodeAndSize(PyObject *unicode, Py_ssize_t *size) # { # ... # #endif # wchar_t *w; # wchar_t *wchar_end; # # ... # 1 _PyUnicode_WSTR(unicode) = (wchar_t *) PyObject_MALLOC(sizeof(wchar_t) * # (_PyUnicode_LENGTH(unicode) + 1)); # ... # w = _PyUnicode_WSTR(unicode); # 2 wchar_end = w + _PyUnicode_LENGTH(unicode); # # if (PyUnicode_KIND(unicode) == PyUnicode_1BYTE_KIND) { # one_byte = PyUnicode_1BYTE_DATA(unicode); # 3 for (; w < wchar_end; ++one_byte, ++w) # *w = *one_byte; # /* null-terminate the wstr */ # 4 *w = 0; # } # # 1. if length(unicode)==2**30-1, then malloced buffer has size equal to # 4*(2^30-1+1)=2^32 == 0 (modulo 2^32) # 2. wchar_end is equal to w-4 because of pointer arithmetic (nonexplicit # multiplication by 4) # 3. w > wchar_end, so we don't enter the loop # 4. 4 byte write to a 0 size buffer # # GDB output # ---------- # # 3860 _PyUnicode_WSTR(unicode) = (wchar_t *) PyObject_MALLOC(sizeof(wchar_t) * # ... # (gdb) print sizeof(wchar_t)*(((PyASCIIObject*)(unicode))->length+1) # $21 = 0 # ... # (gdb) n # 3868 w = _PyUnicode_WSTR(unicode); # (gdb) n # 3869 wchar_end = w + _PyUnicode_LENGTH(unicode); # (gdb) n # 3871 if (PyUnicode_KIND(unicode) == PyUnicode_1BYTE_KIND) { # (gdb) print w # $22 = 0x805fc028 L"\xfbfbfbfb\xced00000" # (gdb) print wchar_end # $23 = 0x805fc024 L"\xfbfbfb6f\xfbfbfbfb\xced00000" # ... # 3876 *w = 0; # # ) # OS info # ------- # # % ./python -V # Python 3.4.1 # # % uname -a # Linux ubuntu 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux import locale s='a'*(2**30-1) locale.strxfrm(s) ---------- files: poc_strxfrm.py messages: 236275 nosy: pkt priority: normal severity: normal status: open title: allocation (and overwrite) of a 0 byte buffer type: crash versions: Python 3.4 Added file: http://bugs.python.org/file38186/poc_strxfrm.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 13:22:31 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 12:22:31 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1424434951.29.0.714913215392.issue23350@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 13:25:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 12:25:03 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1424435103.1.0.696224626059.issue22928@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 13:28:18 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 12:28:18 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1424435298.17.0.617855670847.issue22931@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: -Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 13:52:52 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 20 Feb 2015 12:52:52 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support Message-ID: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> New submission from Paul Moore: This is the patch for PEP 441 (Zip Application Support). Steve, could you check the installer changes, please? I haven't managed to get a setup where I can test the installer, and I'm not aware of any WiX coding tools, so I just edited the XML files by hand with grep and vim, and checked that Tools/buildmsi.bat doesn't error in anything I wrote... (There's a CRC check error in TCL, but that was there before I made changes) light.exe : error LGHT0216: An unexpected Win32 exception with error code 0x17 occurred while accessing file 'C:\Work\Projects\cpython\externals\tcltk64\lib\tcl8.6\tzdata\America\Detroit': Data error (cyclic redundancy check) [C:\Work\Projects\cpython\Tools\msi\tcltk\tcltk.wixproj] Also, I don't *think* I need to do anything for the new files in Doc\Lib, Lib and Lib\test to get picked up, but I'm not sure how to check that. ---------- assignee: steve.dower components: Library (Lib) files: pep441.patch keywords: patch messages: 236276 nosy: pmoore, steve.dower priority: normal severity: normal status: open title: PEP 441 - Improving Python Zip Application Support type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38187/pep441.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 13:56:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 12:56:37 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <1423655171.77.0.0216146047129.issue23442@psf.upfronthosting.co.za> Message-ID: <20150220125634.3887.55566@psf.io> Roundup Robot added the comment: New changeset 52d37efaf939 by Berker Peksag in branch 'default': Issue #23442: Rename two member names to stay backward compatible https://hg.python.org/cpython/rev/52d37efaf939 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 13:58:54 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 12:58:54 +0000 Subject: [issue23442] http.client.REQUEST_HEADER_FIELDS_TOO_LARGE renamed in 3.5 In-Reply-To: <1423655171.77.0.0216146047129.issue23442@psf.upfronthosting.co.za> Message-ID: <1424437134.02.0.299139134985.issue23442@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thanks to both of you :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 14:04:07 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Feb 2015 13:04:07 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1424437447.92.0.496645779246.issue20699@psf.upfronthosting.co.za> R. David Murray added the comment: What is your objection to "len(b)"? When I read "len(b)" I know exactly what it means. When I read "the number of bytes in b", I have to think about it it, because it could mean "the number of bytes that that b is long" or "the number of bytes that have been already written to b", and the latter is the meaning my mind goes to first, so it takes time for my mind to realize it is the first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 14:10:01 2015 From: report at bugs.python.org (paul) Date: Fri, 20 Feb 2015 13:10:01 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <1424434009.7.0.146767591235.issue23490@psf.upfronthosting.co.za> Message-ID: <1424437801.69.0.870800016112.issue23490@psf.upfronthosting.co.za> paul added the comment: And a nice error: Debug memory block at address p=0x805fc028: API 'o' 0 bytes originally requested The 3 pad bytes at p-3 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x805fc028 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x00 *** OUCH at tail+1: 0x00 *** OUCH at tail+2: 0x00 *** OUCH at tail+3: 0x00 *** OUCH The block was made by call #53454 to debug malloc/realloc. Fatal Python error: bad trailing pad byte ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 14:13:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Feb 2015 13:13:16 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <1424434009.7.0.146767591235.issue23490@psf.upfronthosting.co.za> Message-ID: <1424437996.77.0.919761333419.issue23490@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +benjamin.peterson, haypo, serhiy.storchaka type: crash -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 14:24:08 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 13:24:08 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1424438648.82.0.387583773909.issue21793@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. I left a comment for Serhiy on Rietveld. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 14:37:46 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Feb 2015 13:37:46 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1424439466.66.0.0273387224544.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: Using len(b) is fine if b is a bytes() or bytearray() object, but a bytes-like object can be anything that you can pass to memoryview(). In general len(b) is not part of that protocol, so can return some other value, or even be unimplemented: >>> from array import array >>> b = array("H", range(2)) >>> len(b) 2 >>> bytes(b) # Actually 4 bytes = 2 items ? 2 bytes b'\x00\x00\x01\x00' >>> from ctypes import c_int >>> b = c_int(100) >>> len(b) Traceback (most recent call last): File "", line 1, in TypeError: object of type 'c_long' has no len() >>> bytes(b) # 4 bytes despite not implementing len() b'd\x00\x00\x00' I see your point that ?the number of bytes in b? can be misleading. I will think about the wording some more. Maybe we can come up with a third alternative, like ?the number of bytes given? or something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 14:41:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 13:41:16 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1424437447.92.0.496645779246.issue20699@psf.upfronthosting.co.za> Message-ID: <4482593.HnPrEmWn6J@raxxla> Serhiy Storchaka added the comment: Because it is not len(b). I fixed several bugs in Python code which called len() for bytes-like argument and failed with array.array or memoryview with non-byte items. The term "bytes-like object" is slightly misleading. In some cases it implies indexing and len, and iterating, and may be slicing -- common operations for bytes, bytearray, array('B'), memoryview().cast('B'). In more narrow meaning it may require such operations as concatenation (operator +) and .startswith() -- common for bytes and bytearray. In more general meaning it requires only the support of buffer protocol and contiguity. In more general meaning it may be even non-contiguous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 14:49:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 13:49:00 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1424440140.48.0.435474095763.issue21793@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Does not changing __str__ to decimal representation (and in this case __str__ = int.__str__ may be better) lost a part of the point of converting HTTP status codes to enums? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 14:55:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 13:55:53 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424440553.47.0.72831681406.issue23491@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 15:12:08 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 20 Feb 2015 14:12:08 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424441528.8.0.533492278763.issue23491@psf.upfronthosting.co.za> Steve Dower added the comment: The installer changes look fine, though there shouldn't be PATH related strings in exe/, so there's probably a separate issue there. Wix doesn't really have any editors that aren't just XML editors. We probably want to update the ContentType value from text/plain for all the shortcuts, though I'm not sure what to (it affects the implicit associations and extra commands on the files, inc. Open With). The easiest way to make sure the files are in the installer is to install it :) But if they're just .py files under Lib/ then they'll be there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 15:12:52 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 20 Feb 2015 14:12:52 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424441572.49.0.877323796663.issue23491@psf.upfronthosting.co.za> Steve Dower added the comment: I haven't looked closely at the rest, btw. Will try and find time today or tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 15:15:34 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 20 Feb 2015 14:15:34 +0000 Subject: [issue23489] atexit handlers are not executed when using multiprocessing.Pool.map. In-Reply-To: <1424432908.71.0.0710990700334.issue23489@psf.upfronthosting.co.za> Message-ID: <1424441734.1.0.74415352862.issue23489@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +davin, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 15:25:43 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Feb 2015 14:25:43 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1424442343.6.0.83050991672.issue20699@psf.upfronthosting.co.za> R. David Murray added the comment: How about "the length of b in bytes"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 15:40:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 14:40:14 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions Message-ID: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch improve generated parsers for functions with single positional argument. Now they always generated as METH_O and PyArg_Parse() is used to parse single argument. To avoid code churn in this and following changes it would be worth to extract all generated code in separated files. ---------- components: Build files: clinic_meth_o.patch keywords: patch messages: 236288 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Argument Clinic: improve generated parser for 1-argument functions type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38188/clinic_meth_o.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 15:48:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 14:48:41 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za> Message-ID: <20150220144827.109550.60316@psf.io> Roundup Robot added the comment: New changeset f4f2096ab6f8 by Brett Cannon in branch 'default': Issue #22834: Fix a failing test under Solaris due to the platform not https://hg.python.org/cpython/rev/f4f2096ab6f8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:02:57 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 20 Feb 2015 15:02:57 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424444577.03.0.385528231521.issue23465@psf.upfronthosting.co.za> Wolfgang Maier added the comment: am I correct that when a script contains a shebang line like: #! python3 or #! python3.4 i.e., one indicating just a version of, but not a full path to the interpreter, the current patch would not use an active virtualenv even if it has a suitable version ? If so, is that a desirable behaviour? If I've misread the patch and the PEP, then sorry for the noise. ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:22:54 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 20 Feb 2015 15:22:54 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424445774.72.0.723672106996.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: Thanks for checking, Steve. I don't get an installer because of the checksum error quoted, although I did get the component msi files. As far as content type is concerned, I wasn't sure what effect it had so I just copied what was there. I guess application/zip might be better for .pyz files, based on what you said? I'm not sure what you meant by the comment about exe/. All I did was mention .pyz as well as .py - although I don't see where the PathDescription string us used so I may be missing something important! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:26:41 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Feb 2015 15:26:41 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za> Message-ID: <1424446001.51.0.474497164608.issue22834@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the suggestion, Martin. Went with a variant of what you proposed. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:30:05 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 20 Feb 2015 15:30:05 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424446205.88.0.713879275133.issue23465@psf.upfronthosting.co.za> Paul Moore added the comment: That's correct. The problem here is that it's not possible to know what version of Python a virtualenv has (at least, not without running it, which isn't appropriate in the launcher). So the only case it's possible to support is #!python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:32:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 15:32:07 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1424446001.51.0.474497164608.issue22834@psf.upfronthosting.co.za> Message-ID: <1806319.YlqliPs2Fo@raxxla> Serhiy Storchaka added the comment: May be better use errno.EINVAL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:34:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 15:34:39 +0000 Subject: [issue23422] Clarify docs for importlib.import_module() In-Reply-To: <1423496708.39.0.508635169879.issue23422@psf.upfronthosting.co.za> Message-ID: <20150220153429.116381.50600@psf.io> Roundup Robot added the comment: New changeset 46bfddb14cbe by Brett Cannon in branch 'default': Issue #23422: Clarify some things around importlib.import_module() https://hg.python.org/cpython/rev/46bfddb14cbe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:34:57 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 20 Feb 2015 15:34:57 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1424405289.57.0.921269283259.issue3566@psf.upfronthosting.co.za> Message-ID: <71BEFAC3-C49D-45BC-B741-35F463FD0950@gmail.com> Demian Brecht added the comment: > On Feb 19, 2015, at 8:08 PM, Martin Panter wrote: > I guess you saying RemoteDisconnected effectively means the same thing as ConnectionResetError. Exactly. > Would it help if it was derived from ConnectionResetError, instead of the ConnectionError base class? Or are you also worried about the multiple inheritance or clutter of yet another type of exception? My concern is more about consistency of exceptions and exception handling when using the client. Thinking about it from a user?s standpoint, when I issue a request and the remote socket closes, I would hope to get consistent exceptions for all remote resets. If I?m handling the lowest level errors independently of one another rather than catch-all ConnectionError, I don?t want to do something like this: except (RemoteDisconnected, ConnectionResetError) I /should/ be able to simply use ConnectionResetError. Reading the docs, the only real reason for this exception at all is for backwards compatibility. If we have a case to break backwards compatibility here, then that eliminates the need for the new exception and potential (minor) confusion. In this special case, the behaviour that we see at the client socket level indicates a remote reset, but it?s only artificially known immediately due to the empty read. In my mind, because the client /knows/ that this is an early indicator of a ConnectionResetError, that is exactly the exception that should be used. Hope that makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:35:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 15:35:05 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <1424434009.7.0.146767591235.issue23490@psf.upfronthosting.co.za> Message-ID: <1424446505.97.0.83094629094.issue23490@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. There is yet one similar bug in unicodeobject.c. ---------- keywords: +patch stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file38189/issue23490.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:40:11 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 20 Feb 2015 15:40:11 +0000 Subject: [issue21257] Document parse_headers function of http.client In-Reply-To: <1424430604.04.0.509237587395.issue21257@psf.upfronthosting.co.za> Message-ID: Demian Brecht added the comment: > On Feb 20, 2015, at 3:10 AM, Berker Peksag wrote: > This is a different issue than #23439. BaseHTTPRequestHandler.headers documentation mentions about parse_headers function, the function itself is not documented. Not entirely sure what I was thinking here. I was under the impression that the docs for parse_headers had been added in the linked issue. Thanks for pointing that out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:42:44 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Feb 2015 15:42:44 +0000 Subject: [issue23422] Clarify docs for importlib.import_module() In-Reply-To: <1423496708.39.0.508635169879.issue23422@psf.upfronthosting.co.za> Message-ID: <1424446964.96.0.715246496738.issue23422@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:43:56 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 20 Feb 2015 15:43:56 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424447036.56.0.845342117892.issue23465@psf.upfronthosting.co.za> Wolfgang Maier added the comment: isn't the pyvenv.cfg file specifying the version ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 16:58:58 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 20 Feb 2015 15:58:58 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1424447938.57.0.47721785134.issue22928@psf.upfronthosting.co.za> Changes by Demian Brecht : Added file: http://bugs.python.org/file38190/issue22928_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 17:17:14 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 20 Feb 2015 16:17:14 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424449034.52.0.756009038854.issue23465@psf.upfronthosting.co.za> Paul Moore added the comment: Hmm, I didn't know that (although virtualenv-based environments don't have an equivalent to pyvenv.cfg). But there's some confusion here. This patch only affects command line usage (running "py.exe" to start Python). I don't really see a use case for making "py -3" mean "the virtualenv if it's Python 3 otherwise ignore the virtualenv and use the system Python 3". For scripts, shebang processing isn't altered. Nothing uses a virtualenv except "#!/usr/bin/env python". And that does so only because it searches PATH before looking at the registry. If you use "#!/usr/bin/env python3" it won't see a virtualenv because there is no python3.exe in a virtualenv... The scope of this PEP is just to make the "py" command (with no explicit version) use an active virtualenv before falling back to the default Python. This is specifically to allow people who don't put Python on their PATH but use virtualenvs to use "py" consistently, rather than having to switch to "python" when they are in a virtualenv. See the PEP (specifically the rationale section) for details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 17:23:29 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 20 Feb 2015 16:23:29 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424449409.02.0.761273626646.issue23491@psf.upfronthosting.co.za> Steve Dower added the comment: Either "application/zip" or "application/x-zip-compressed", I'm not sure exactly what the difference is, but the default .zip association has the latter. The CRC error may be your machine or it may be because we're currently running on unstable WiX releases (hey, everything else is unstable right now :) ). If you can edit and re-save that file, I'd expect it to work, otherwise the 32-bit installer should be okay. The exe/ comment is more a note for myself, sorry. Those strings are unused and should be removed (I'll do that now - got a few things to fix). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 17:25:56 2015 From: report at bugs.python.org (Wouter Bolsterlee) Date: Fri, 20 Feb 2015 16:25:56 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() Message-ID: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> New submission from Wouter Bolsterlee: The JSON encoder uses a lambda function for the sort(key=...) invocation used to sort the keys in a JSON object in case sort_keys=True is passed: https://hg.python.org/cpython/file/46bfddb14cbe/Lib/json/encoder.py#l352 Instead of having a lambda, operator.itemgetter(0) can be used here, which is a minor performance gain. It should be noted that many other internals of the JSON encoder have also been fine-tuned (manually) for performance reasons. ---------- components: Library (Lib) messages: 236302 nosy: wbolster priority: normal severity: normal status: open title: optimize sort_keys in json module by using operator.itemgetter() versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 17:29:03 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 20 Feb 2015 16:29:03 +0000 Subject: [issue23018] Add version info to python In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1424449743.45.0.909717998241.issue23018@psf.upfronthosting.co.za> Steve Dower added the comment: Looks like the .rc files should actually be UCS-2, since that's how the strings are going to be stored into the executables. If I rename the .h file to .h_ (and change the encoding to UCS-2 with BOM), will it be ignored by argument clinic? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 17:31:35 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 20 Feb 2015 16:31:35 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1424440140.48.0.435474095763.issue21793@psf.upfronthosting.co.za> Message-ID: <01363711-8569-4D4D-BC85-310076F50EEE@gmail.com> Demian Brecht added the comment: The updated patch addresses comments which I?d somehow missed previously, but keeps the log fix to the __str__ implementation of HTTPStatus (using int.__str__ rather than format()). > Does not changing __str__ to decimal representation (and in this case __str__ = int.__str__ may be better) lost a part of the point of converting HTTP status codes to enums? I don?t think so. In the case of HTTPStatus in general, I think that the optimal string representation of an element of the enum is the stringified version of the status code. If nothing else, it?s consistent with the other type of status code that can be used (ints). That does lead me to something that I think is a little odd about IntEnums in general but I?ll ask that question in python-dev rather than here as to not conflate this issue. ---------- Added file: http://bugs.python.org/file38191/issue21793_logfix_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 46bfddb14cbe Lib/http/__init__.py --- a/Lib/http/__init__.py Fri Feb 20 10:34:20 2015 -0500 +++ b/Lib/http/__init__.py Fri Feb 20 08:12:24 2015 -0800 @@ -24,6 +24,9 @@ obj.description = description return obj + def __str__(self): + return int.__str__(self) + # informational CONTINUE = 100, 'Continue', 'Request received, please continue' SWITCHING_PROTOCOLS = (101, 'Switching Protocols', diff -r 46bfddb14cbe Lib/test/test_httpservers.py --- a/Lib/test/test_httpservers.py Fri Feb 20 10:34:20 2015 -0500 +++ b/Lib/test/test_httpservers.py Fri Feb 20 08:12:24 2015 -0800 @@ -6,7 +6,7 @@ from http.server import BaseHTTPRequestHandler, HTTPServer, \ SimpleHTTPRequestHandler, CGIHTTPRequestHandler -from http import server +from http import server, HTTPStatus import os import sys @@ -235,6 +235,27 @@ self.assertEqual(int(res.getheader('Content-Length')), len(data)) +class RequestHandlerLoggingTestCase(BaseTestCase): + class request_handler(BaseHTTPRequestHandler): + protocol_version = 'HTTP/1.1' + default_request_version = 'HTTP/1.1' + + def do_GET(self): + self.send_response(HTTPStatus.OK) + self.end_headers() + + def test_get(self): + self.con = http.client.HTTPConnection(self.HOST, self.PORT) + self.con.connect() + + with support.captured_stderr() as err: + self.con.request('GET', '/') + self.con.getresponse() + + self.assertTrue( + err.getvalue().endswith('"GET / HTTP/1.1" 200 -\n')) + + class SimpleHTTPServerTestCase(BaseTestCase): class request_handler(NoLogRequestHandler, SimpleHTTPRequestHandler): pass @@ -816,6 +837,7 @@ cwd = os.getcwd() try: support.run_unittest( + RequestHandlerLoggingTestCase, BaseHTTPRequestHandlerTestCase, BaseHTTPServerTestCase, SimpleHTTPServerTestCase, From report at bugs.python.org Fri Feb 20 17:31:41 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 20 Feb 2015 16:31:41 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424449901.12.0.867836301186.issue23465@psf.upfronthosting.co.za> Wolfgang Maier added the comment: > Hmm, I didn't know that (although virtualenv-based environments don't have an equivalent to pyvenv.cfg). Well, that complicates things then :( > But there's some confusion here. This patch only affects command line usage (running "py.exe" to start Python). I don't really see a use case for making "py -3" mean "the virtualenv if it's Python 3 otherwise ignore the virtualenv and use the system Python 3". > > For scripts, shebang processing isn't altered. Nothing uses a virtualenv except "#!/usr/bin/env python". And that does so only because it searches PATH before looking at the registry. If you use "#!/usr/bin/env python3" it won't see a virtualenv because there is no python3.exe in a virtualenv... > Well, and that's exactly what I think is a mistake ... > The scope of this PEP is just to make the "py" command (with no explicit version) use an active virtualenv before falling back to the default Python. This is specifically to allow people who don't put Python on their PATH but use virtualenvs to use "py" consistently, rather than having to switch to "python" when they are in a virtualenv. See the PEP (specifically the rationale section) for details. > Right, just that #!/usr/bin/env python3 is a very plausible shebang line for a Python3 script for use under UNIX where #!/usr/bin/env python typically means python2. So, with the current patch users could still not use the py launcher from a virtual environment with scripts that are supposed to work under UNIX :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 17:32:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 16:32:16 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424449936.45.0.461899171009.issue23488@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. It also optimizes getrandbit() and seed() as was originally proposed in issue16496. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 17:41:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 16:41:54 +0000 Subject: [issue23018] Add version info to python In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1424450514.44.0.330509246546.issue23018@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I afraid that adding source file that can't be easy handled by Unix text tools (such as diff) is not good idea. Does "\xa9" work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:01:36 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 20 Feb 2015 17:01:36 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424451696.83.0.123389163214.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: Thanks. Updated patch with the new mime-type. Looks like there's disk errors on that file with the CRC check. Lovely :-) ---------- Added file: http://bugs.python.org/file38192/pep441.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:05:50 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 20 Feb 2015 17:05:50 +0000 Subject: [issue23018] Add version info to python In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1424451950.43.0.719072345307.issue23018@psf.upfronthosting.co.za> Steve Dower added the comment: Digging around the likely encodings to be running on Windows machines, it looks like 0xA9 is always the right symbol, so that change should be fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:07:31 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 20 Feb 2015 17:07:31 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1424449901.12.0.867836301186.issue23465@psf.upfronthosting.co.za> Message-ID: Paul Moore added the comment: On 20 February 2015 at 16:31, Wolfgang Maier wrote: >> The scope of this PEP is just to make the "py" command (with no explicit version) use an active virtualenv before falling back to the default Python. This is specifically to allow people who don't put Python on their PATH but use virtualenvs to use "py" consistently, rather than having to switch to "python" when they are in a virtualenv. See the PEP (specifically the rationale section) for details. >> > > Right, just that > > #!/usr/bin/env python3 > > is a very plausible shebang line for a Python3 script for use under UNIX where #!/usr/bin/env python typically means python2. That seems completely reasonable. Presumably this works for Unix because virtualenvs have a "python3" executable installed, not just a "python" executable? > So, with the current patch users could still not use the py launcher from a virtual environment with scripts that are supposed to work under UNIX :( Correct. That's not the problem this PEP is intended to solve. Another PEP could be written to look at this, but I suspect it could be quite hard to balance the various issues involved. As a start, maybe the Python Windows installer should be writing a "python3.exe" as well as "python.exe" and venv should put that in the virtualenv. (That's certainly something that has been suggested in the past). That may be a simpler solution than adding yet more complexity and special cases to the launcher. Personally, I don't have a need for this functionality, so I'm happy to leave that PEP to someone else to write. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:13:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 17:13:35 +0000 Subject: [issue23018] Add version info to python In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <20150220171333.29686.99142@psf.io> Roundup Robot added the comment: New changeset 843a8ee94270 by Steve Dower in branch 'default': Closes #23018: Replace copyright symbol with escape. https://hg.python.org/cpython/rev/843a8ee94270 ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:35:19 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 20 Feb 2015 17:35:19 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <1424434009.7.0.146767591235.issue23490@psf.upfronthosting.co.za> Message-ID: <1424453719.88.0.538909089988.issue23490@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think it looks fine except why do you cast PyUnicode_LENGTH to size_t in the comparison? I also wonder if we should have PyObject_NEW now. ---------- stage: patch review -> versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:38:35 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 20 Feb 2015 17:38:35 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424453915.1.0.564784509795.issue23492@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm not opposed to the patch in principle. I assume your goal is to make Python faster--do you have any data on how much faster? I don't support immediately changing all uses of Argument Clinic to generate their code into a separate file. I would want to see a consensus from the community first. Perhaps we should discuss it (again?) on python-dev? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:39:46 2015 From: report at bugs.python.org (Ed Maste) Date: Fri, 20 Feb 2015 17:39:46 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1424453986.09.0.640517707804.issue23458@psf.upfronthosting.co.za> Changes by Ed Maste : ---------- nosy: +Ed.Maste _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:39:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 17:39:56 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <1424453719.88.0.538909089988.issue23490@psf.upfronthosting.co.za> Message-ID: <2088807.jOZ8g1NGfQ@raxxla> Serhiy Storchaka added the comment: > I think it looks fine except why do you cast PyUnicode_LENGTH to size_t in > the comparison? To silence compiler warning. PyUnicode_LENGTH is signed, right hand is unsigned. > I also wonder if we should have PyObject_NEW now. We have PyObject_NEW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:52:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 17:52:01 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424453915.1.0.564784509795.issue23492@psf.upfronthosting.co.za> Message-ID: <4983833.4li7hTEWtJ@raxxla> Serhiy Storchaka added the comment: This is one step on long way. Second step will be to inline PyArg_Parse for some format codes ("i", "U", "y*", "O&", "O!"). Then we could try to expand PyArg_ParseTuple, at least for simple common cases. Then PyArg_ParseTupleAndKeywords. All this step will produce large diffs for generated code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 18:57:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 17:57:53 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1424455073.33.0.282685314735.issue23458@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 19:07:23 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 20 Feb 2015 18:07:23 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <2088807.jOZ8g1NGfQ@raxxla> Message-ID: <1424455640.2596328.230260237.256CD332@webmail.messagingengine.com> Benjamin Peterson added the comment: On Fri, Feb 20, 2015, at 12:39, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > > I think it looks fine except why do you cast PyUnicode_LENGTH to size_t in > > the comparison? > > To silence compiler warning. PyUnicode_LENGTH is signed, right hand is > unsigned. Okay. > > > I also wonder if we should have PyObject_NEW now. > > We have PyObject_NEW. Can we use here then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 19:14:35 2015 From: report at bugs.python.org (Ed Maste) Date: Fri, 20 Feb 2015 18:14:35 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1424456075.58.0.629030218831.issue23458@psf.upfronthosting.co.za> Ed Maste added the comment: For reference, this fd leak was causing one of LLDB's tests to fail. It is now marked XFAIL pending a resolution of this issue: http://llvm.org/viewvc/llvm-project?view=revision&revision=229704 Linux is also affected, the Linux LLDB tests were previously running on an earlier Python version which did not demonstrate this problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 19:19:24 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 20 Feb 2015 18:19:24 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424456364.59.0.247065832678.issue23476@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 19:54:09 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 20 Feb 2015 18:54:09 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424458449.67.0.947483743757.issue23476@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This may be related to a known, and fixed, OpenSSL bug. Where do you see that the bug is fixed? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 19:57:07 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 20 Feb 2015 18:57:07 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1424458627.35.0.73328429335.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Can I interest any of you in further review? I think I have responded to all comments so far. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 20:02:32 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 20 Feb 2015 19:02:32 +0000 Subject: [issue14484] missing return in win32_kill? In-Reply-To: <1333462226.23.0.725280599354.issue14484@psf.upfronthosting.co.za> Message-ID: <1424458952.33.0.199505965891.issue14484@psf.upfronthosting.co.za> Mark Lawrence added the comment: #14480 "os.kill on Windows should accept zero as signal" references this. It seems that we either go all the way and change the code as Victor has suggested or keep the status quo and change the docs as Zach has said. Thoughts? ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 20:02:45 2015 From: report at bugs.python.org (Laura Creighton) Date: Fri, 20 Feb 2015 19:02:45 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424458965.18.0.262955571528.issue23476@psf.upfronthosting.co.za> Laura Creighton added the comment: In https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1014640 it says : FIX: Fixed in Ubuntu 14.04 apparently. Openssl upstream, see http://rt.openssl.org/Ticket/Display.html?id=2732 But I think the person who wrote that launchpad note was mistaken, as the rt.openssl.org ticket still is marked open when I looked at it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 20:17:50 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 20 Feb 2015 19:17:50 +0000 Subject: [issue6820] Redefinition of HAVE_STRFTIME can cause compiler errors. In-Reply-To: <1251884386.05.0.339554390546.issue6820@psf.upfronthosting.co.za> Message-ID: <1424459870.84.0.313175610422.issue6820@psf.upfronthosting.co.za> Mark Lawrence added the comment: Having had another look the patch is not acceptable as the majority of the changes are to whitespace only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 20:35:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 19:35:30 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <1424434009.7.0.146767591235.issue23490@psf.upfronthosting.co.za> Message-ID: <20150220193522.3873.67316@psf.io> Roundup Robot added the comment: New changeset 038297948389 by Serhiy Storchaka in branch '3.4': Issue #23490: Fixed possible crashes related to interoperability between https://hg.python.org/cpython/rev/038297948389 New changeset 56c6a4bce996 by Serhiy Storchaka in branch 'default': Issue #23490: Fixed possible crashes related to interoperability between https://hg.python.org/cpython/rev/56c6a4bce996 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 20:38:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 19:38:45 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <1424434009.7.0.146767591235.issue23490@psf.upfronthosting.co.za> Message-ID: <1424461125.23.0.58567670945.issue23490@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Can we use here then? It is for PyObjects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 20:39:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 19:39:53 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <1424434009.7.0.146767591235.issue23490@psf.upfronthosting.co.za> Message-ID: <1424461193.46.0.761859050531.issue23490@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report paul. ---------- assignee: -> serhiy.storchaka components: +Interpreter Core resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 20:46:14 2015 From: report at bugs.python.org (Gil Shotan) Date: Fri, 20 Feb 2015 19:46:14 +0000 Subject: [issue23494] adding timedelta to datetime object is not timezone aware Message-ID: <1424461574.53.0.989762969133.issue23494@psf.upfronthosting.co.za> New submission from Gil Shotan: I encountered a strange bug involving timezone aware datetime objects and timedelta objects. The crux of the matter is that daylight savings time is considered a different timezone, and therefore the timezone of a datetime object is date dependent. However, adding a timedelta object to a datetime object seems to do the simple thing which is preserve the timezone object. The bug manifests itself whenever adding a timedelta object crosses a daylight savings time boundary. The following code illustrates the problem. Note that the transition between PDT (Pacific daylight time) and PST (Pacific savings time) occurs on March 9th (ish) >>> from datetime import datetime, timedelta >>> import pytz >>> tz = pytz.timezone('America/Los_Angeles') >>> before = tz.localize(datetime(year=2015, month=3, day=8)) >>> before datetime.datetime(2015, 3, 8, 0, 0, tzinfo=) >>> # notice PST timezone >>> after_right = tz.localize(datetime(year=2015, month=3, day=10)) >>> after_right datetime.datetime(2015, 3, 10, 0, 0, tzinfo=) >>> # notice PDT timezone >>> after_wrong = before + timedelta(days=2) >>> after_wrong datetime.datetime(2015, 3, 10, 0, 0, tzinfo=) >>> # when calculated this way, the timezone remains at PST ---------- components: Distutils messages: 236326 nosy: dstufft, eric.araujo, gilsho priority: normal severity: normal status: open title: adding timedelta to datetime object is not timezone aware type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 21:41:57 2015 From: report at bugs.python.org (John Nagle) Date: Fri, 20 Feb 2015 20:41:57 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424464917.75.0.356436070447.issue23476@psf.upfronthosting.co.za> John Nagle added the comment: The "fix" in Ubuntu was to the Ubuntu certificate store, which is a directory tree with one cert per file, with lots of symbolic links with names based on hashes to express dependencies. Python's SSL isn't using that. Python is taking in one big text file of SSL certs, with no link structure, and feeding it to OpenSSL. This is an option at SSLContext.load_verify_locations(cafile=None, capath=None, cadata=None) I've been testing with "cafile". "capath" is a path to a set of preprocessed certs laid out like the Ubuntu certificate store. It may be that the directory parameter works but the single-file parameter does not. It's possible to create such a directory from a single .pem file by splitting the big file into smaller files (the suggested tool is an "awk" script) and then running "c_rehash", which comes with OpenSSL. See "https://www.openssl.org/docs/apps/c_rehash.html" So I tried a workaround, using Python 3.4.0 and Ubuntu 14.04 LTS. I broke up "cacert.pem" into one file per cert with the suggested "awk" script, and used "c_rehash" to build all the links, creating a directory suitable for "capath". It didn't help. Fails for "verisign.com", works for "python.org" and "google.com", just like the original single-file test. The "capath" version did exactly the same thing as the "cafile" version. Python is definitely reading the cert file or directories; if I try an empty cert file or dir, everything fails, like it should. Tried the same thing on Win7 x64. Same result. Tried the command line openssl tool using the cert directory. Same results as with the single file on both platforms. So that's not it. A fix to OpenSSL was proposed in 2012, but no action was taken: http://rt.openssl.org/Ticket/Display.html?id=2732 at "Wed Jun 13 17:15:04 2012 Arne Becker - Correspondence added". Any ideas? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 21:45:53 2015 From: report at bugs.python.org (Steven Barker) Date: Fri, 20 Feb 2015 20:45:53 +0000 Subject: [issue23495] The writer.writerows method should be documented as accepting any iterable (not only a list) Message-ID: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za> New submission from Steven Barker: The documentation for the csv.writer.writerows method says that it expects "a list of row objects", when it really will accept any iterable that yields rows (such as a generator). While it's often nice for code to be more accepting than the documented requirements, I think the docs in this case should state that writerows() expects an iterable, rather than misinforming users that a list is required. This documentation issue was brought up in a Stack Overflow question here: http://stackoverflow.com/questions/28636848/csv-writer-writerows-takes-iterator I expect the necessary documentation patch will be pretty trivial, and if nobody else gets to it first, I will try to provide one when I have enough time to update my cpython checkout (not soon, alas). ---------- assignee: docs at python components: Documentation messages: 236328 nosy: Steven.Barker, docs at python priority: normal severity: normal status: open title: The writer.writerows method should be documented as accepting any iterable (not only a list) type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 22:05:32 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 20 Feb 2015 21:05:32 +0000 Subject: [issue23489] atexit handlers are not executed when using multiprocessing.Pool.map. In-Reply-To: <1424432908.71.0.0710990700334.issue23489@psf.upfronthosting.co.za> Message-ID: <1424466332.74.0.641912005103.issue23489@psf.upfronthosting.co.za> Davin Potts added the comment: There are at least two issues at play here. Running the attached file on OS X produces starkly different results -- console prints: CREATED TEMP DIRECTORY /var/folders/s4/tc1y5rjx25vfknpzvnfh1b140000gn/T/temp_z6I0BA task1 task2 ATEXIT: REMOVING TEMP DIRECTORY /var/folders/s4/tc1y5rjx25vfknpzvnfh1b140000gn/T/temp_z6I0BA The reason only one temp directory is created on OS X (or on other unix-y platforms) and more than one is created on Windows is described in more detail here: https://docs.python.org/2/library/multiprocessing.html#windows In short, on Windows 8.1, the processes you spawn via multiprocessing must import your main module ("task_spawn" in this case) and in so doing each executes both the line creating a temp directory and the lines following it (this is part of how import works). I suspect you want instead to put these lines inside a "if __name__ == '__main__'" clause -- doing so will ensure only one temp dir is created and it will be properly cleaned up when the interpreter exits cleanly. You will have consistent behavior across Windows and unix-y platforms this way too, not to mention your code will more clearly convey that you only want the main process to create a temp dir. (Specifically see the section "Safe importing of main module" in the docs at the above link.) That was the first issue -- on to the second. The registering of functions with atexit means they'll be executed upon "normal interpreter termination". Lifting a snippet from the atexit docs' introduction section (https://docs.python.org/2/library/atexit.html): Note: The functions registered via this module are not called when the program is killed by a signal not handled by Python, when a Python fatal internal error is detected, or when os._exit() is called. When the processes created and managed via multiprocessing reach termination, that is quite different from "normal interpreter termination". You are observing that when the interpreter's (main) process is done, it executes the function you registered with atexit -- that is how it should be. Registering functions with atexit inside distinct processes will not cause them to be automagically registered with atexit in the parent interpreter process. Hopefully with the above explanation in hand it will be possible to make the necessary changes to correct your code without breaking a sweat. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 22:12:40 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 20 Feb 2015 21:12:40 +0000 Subject: [issue23489] atexit handlers are not executed when using multiprocessing.Pool.map. In-Reply-To: <1424432908.71.0.0710990700334.issue23489@psf.upfronthosting.co.za> Message-ID: <1424466760.53.0.0270054072485.issue23489@psf.upfronthosting.co.za> Davin Potts added the comment: I should have added in my prior comments: juj: thank you very much for providing the info about the platform you tested on and even an example piece of code that triggered the problem. I wish all issues came with the level of info you provided. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 22:24:14 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Feb 2015 21:24:14 +0000 Subject: [issue23494] adding timedelta to datetime object is not timezone aware In-Reply-To: <1424461574.53.0.989762969133.issue23494@psf.upfronthosting.co.za> Message-ID: <1424467454.85.0.520990609033.issue23494@psf.upfronthosting.co.za> R. David Murray added the comment: the tzinfo object is responsible for handling daylight savings time. This looks like a bug in pytz. ---------- components: +Library (Lib) -Distutils nosy: +belopolsky, r.david.murray -dstufft, eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 22:27:45 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 20 Feb 2015 21:27:45 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1424467665.22.0.370746224886.issue23484@psf.upfronthosting.co.za> Davin Potts added the comment: Interesting! The documentation in 3.4 as well as 2.7 indicates that the keyword should be 'blocking' yet the code implements this as 'block'. Code to reproduce empirically what is actually implemented: import multiprocessing dummy_lock = multiprocessing.Lock() dummy_lock.acquire(blocking=False) # Raises a TypeError on invalid keyword The same code changed to 'block=False' works happily. The code should be changed to reflect the docs and a test probably added too that both exercises this keyword explicitly by name and tests to see if we've fallen out of sync with the threading module. ---------- stage: -> needs patch versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 22:39:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 21:39:22 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1424468362.84.0.807461876097.issue11145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, I didn't find any issues with the last patch. Could you please point on them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 22:48:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 21:48:31 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <20150220214829.4036.30341@psf.io> Roundup Robot added the comment: New changeset e7b6b1f57268 by Serhiy Storchaka in branch '3.4': Issue #23374: Fixed pydoc failure with non-ASCII files when stdout encoding https://hg.python.org/cpython/rev/e7b6b1f57268 New changeset affe167a45f3 by Serhiy Storchaka in branch 'default': Issue #23374: Fixed pydoc failure with non-ASCII files when stdout encoding https://hg.python.org/cpython/rev/affe167a45f3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 22:49:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 21:49:08 +0000 Subject: [issue23374] pydoc 3.x raises UnicodeEncodeError on sqlite3 package In-Reply-To: <1422818658.77.0.913299562674.issue23374@psf.upfronthosting.co.za> Message-ID: <1424468948.19.0.351266673066.issue23374@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 22:52:56 2015 From: report at bugs.python.org (juj) Date: Fri, 20 Feb 2015 21:52:56 +0000 Subject: [issue23489] atexit handlers are not executed when using multiprocessing.Pool.map. In-Reply-To: <1424432908.71.0.0710990700334.issue23489@psf.upfronthosting.co.za> Message-ID: <1424469176.3.0.708875455731.issue23489@psf.upfronthosting.co.za> juj added the comment: While the test case can be 'fixed' by changing the code to use "if __name__ == '__main__'", and I'm ok to do it in my code to work around the problem, I would argue the following: 1) calling this not a bug (or solving it only at documentation level) does not at all feel correct to reflect the situation, since the provided test case silently fails and does the unexpected. If atexit() does not work at all when invoked as a result of importing from multiprocessing.Pool.map(), then at minimum it would be better that calling atexit() in such a scenario should throw an exception "not available", rather than silently discarding the operation. 2) Why couldn't the atexit handlers be executed even on Windows when the multiprocessing processes quit, even if special code is required in python multiprocessing libraries to handle it? The explanation you are giving sounds like a lazy excuse. There should not be any technical obstacle why the cleanup handlers could not be tracked and honored here? 3) Saying that this should not be working like the (existing) documentation implies, is not at all obvious to the reader. I could not find it documented that processes that exit from multiprocessing would be somehow special, and the note that you pasted does is not in any way obvious to connect to this case, since a) I was not using signals, b) there was no internal error occurring, and c) I was not calling os._exit(). The documentation does not reflect that it is undefined whether atexit() handlers are executed or not when multiprocessing is used. 4) I would even argue that it is a bug that there is different cross platform observable behavior in terms of multiprocessing and script importing, but that is probably a different topic. Overall, leaving this as a silent failure, instead of raising an exception, nor implementing the support on Windows, does not feel mature, since it leaves a hole of C/C++ style of undefined behavior in the libraries. For maturity, I would recommend something to be done, in the descending order of preference: I) Fix multiprocessing importing on windows so that it is not a special case compared to other OSes. II) If the above is not possible, fix the atexit() handlers so that they are executed when the processes quit on Windows. III) If the above is not possible, make the atexit() function raise an exception if invoked from a script that has been spawned from multiprocessing, when it is known at atexit() call time that the script was spawned a as a result of multiprocessing, and the atexit() handlers will never be run. If none of those are really not possible due to real technical reasons, then as a last resort, explicitly document both in the docs for atexit() and the docs for multiprocessing that the atexit() handlers are not executed if called on Windows when these two are used in conjunction. Disregarding these kind of silent failure behavior especially when cross-platformness is involved with a shrug and a NotABug label is not a good practice! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 23:10:33 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Feb 2015 22:10:33 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za> Message-ID: <1424470233.7.0.974253145291.issue22834@psf.upfronthosting.co.za> Martin Panter added the comment: +1 to EINVAL, also the bug reference comment is redundant with the one at the top of the test case :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 23:14:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 22:14:48 +0000 Subject: [issue5700] io.FileIO calls flush() after file closed In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za> Message-ID: <1424470488.09.0.69329339417.issue5700@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree, the test in test_fileio is redundant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 23:32:24 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Feb 2015 22:32:24 +0000 Subject: =?utf-8?b?W2lzc3VlMjMyOTddIOKAmHRva2VuaXplLmRldGVjdF9lbmNvZGluZ+KAmSBp?= =?utf-8?q?s_confused_between_text_and_bytes=3A_no_=E2=80=98startswith?= =?utf-8?q?=E2=80=99_method_on_a_byte_string?= In-Reply-To: <1421901626.89.0.392776519963.issue23297@psf.upfronthosting.co.za> Message-ID: <1424471544.36.0.23055920208.issue23297@psf.upfronthosting.co.za> R. David Murray added the comment: The error message could indeed be made clearer by turning it into a message that tokenize itself requires bytes input. Or, more likely, the additional error handling needs to be in detect_encoding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 23:37:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 22:37:12 +0000 Subject: [issue5700] io.FileIO calls flush() after file closed In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za> Message-ID: <20150220223710.99276.77206@psf.io> Roundup Robot added the comment: New changeset 7052206ad381 by Serhiy Storchaka in branch '2.7': Issue #5700: io.FileIO() called flush() after closing the file. https://hg.python.org/cpython/rev/7052206ad381 New changeset 36f5c36b7704 by Serhiy Storchaka in branch '3.4': Issue #5700: io.FileIO() called flush() after closing the file. https://hg.python.org/cpython/rev/36f5c36b7704 New changeset e1f08f5b6b62 by Serhiy Storchaka in branch 'default': Issue #5700: io.FileIO() called flush() after closing the file. https://hg.python.org/cpython/rev/e1f08f5b6b62 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 23:37:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 22:37:46 +0000 Subject: [issue5700] io.FileIO calls flush() after file closed In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za> Message-ID: <1424471866.15.0.248060916015.issue5700@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 23:39:19 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 20 Feb 2015 22:39:19 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1424471959.64.0.359113301606.issue21793@psf.upfronthosting.co.za> Martin Panter added the comment: One option might be changing log_request() from self.log_message('"%s" %s %s', self.requestline, str(code), str(size)) to self.log_message('"%s" %s %s', self.requestline, format(code), size) Using str() is redundant with %s, and using format() instead invokes the int base class?s __format__() rather than the enum?s __repr__(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 23:50:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 22:50:31 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1424472631.14.0.755330605702.issue21793@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I would write just: if isinstance(code, HTTPStatus): code = '%d' % code ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 20 23:56:16 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 20 Feb 2015 22:56:16 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1424472631.14.0.755330605702.issue21793@psf.upfronthosting.co.za> Message-ID: <0A38E69E-9808-403F-AE35-05BCBC6B4D6F@gmail.com> Demian Brecht added the comment: > On Feb 20, 2015, at 2:50 PM, Serhiy Storchaka wrote: > > if isinstance(code, HTTPStatus): > code = '%d' % code That?s what I?m intending on doing. It?s definitely not as contained as changing the __str__ implementation of HTTPStatus. That said, I understand the reasoning behind not doing so and this path is the next clearest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 00:22:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 23:22:21 +0000 Subject: [issue21934] OpenBSD has no /dev/full device In-Reply-To: <1404747013.93.0.393614299649.issue21934@psf.upfronthosting.co.za> Message-ID: <1424474541.47.0.694701270112.issue21934@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 00:23:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Feb 2015 23:23:33 +0000 Subject: [issue23215] MemoryError with custom error handlers and multibyte codecs In-Reply-To: <1420860783.67.0.50434618074.issue23215@psf.upfronthosting.co.za> Message-ID: <20150220232325.116393.59694@psf.io> Roundup Robot added the comment: New changeset af8089217cc6 by Serhiy Storchaka in branch '2.7': Issue #23215: Multibyte codecs with custom error handlers that ignores errors https://hg.python.org/cpython/rev/af8089217cc6 New changeset 4dc8b7ed8973 by Serhiy Storchaka in branch '3.4': Issue #23215: Multibyte codecs with custom error handlers that ignores errors https://hg.python.org/cpython/rev/4dc8b7ed8973 New changeset 5620691ce26b by Serhiy Storchaka in branch 'default': Issue #23215: Multibyte codecs with custom error handlers that ignores errors https://hg.python.org/cpython/rev/5620691ce26b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 00:28:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Feb 2015 23:28:25 +0000 Subject: [issue23215] MemoryError with custom error handlers and multibyte codecs In-Reply-To: <1420860783.67.0.50434618074.issue23215@psf.upfronthosting.co.za> Message-ID: <1424474905.28.0.187030550442.issue23215@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 00:59:21 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 20 Feb 2015 23:59:21 +0000 Subject: [issue23489] atexit handlers are not executed when using multiprocessing.Pool.map. In-Reply-To: <1424432908.71.0.0710990700334.issue23489@psf.upfronthosting.co.za> Message-ID: <1424476761.33.0.216487827709.issue23489@psf.upfronthosting.co.za> Davin Potts added the comment: You make an overall valid point that despite reading the documentation, the resulting behavior of your code was not what you expected -- I take that specific complaint very seriously anytime anyone makes it. Regarding your recommendations: I) Unfortunately this is not a trivial topic; it has been discussed extensively elsewhere. As you point out, this is a different topic. II) Please do note the atexit documentation does not suggest it is a tool for triggering actions when a _process_ exits. I don't think I'm a pedant but that kinda makes me sound like one. Here are some suggestions on potential next steps: 1. If the documentation for atexit is inadequate in getting across its true nature and limitations, would you please open a new issue against atexit's documentation? In it, please recommend what would have made it much clearer. 2. Detecting that atexit functionality has been invoked inside a process created using multiprocessing does not cover the full range of possibilities where atexit functionality is impacted and thus the originally-intended/desired behavior will not occur. Ignoring the larger set of possible scenarios for the moment, I think a case could be made to add an atexit-like feature to multiprocessing that would give you specific control over what happens when a process created by multiprocessing is done and terminates. If that appeals to you too, would you consider opening a new issue proposing this feature request and, given your use cases to date, please suggest things that would make it especially valuable? Apologies if any choice of phrasing on my part added in any way to your frustration -- it was not my intention. I do hope you'll be able to contribute something more, possibly along the lines I suggest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 01:43:21 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 21 Feb 2015 00:43:21 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424479401.62.0.612450878611.issue23493@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Is it even legal to have non-string keys in a JSON object? If they must be strings, and they must be unique, I don't think a key argument is necessary (and it would save the generation of the key array; not doing the work is faster than doing the work more efficiently after all), since the default tuple comparison would work fine; the first element would always be unequal, so the second elements would never be compared, right? I'm not 100% on this with the rich comparison operator approach, but my attempts to trigger a failure haven't worked (TimSort or the tuple comparison, or both, are probably smarter about this than I am). ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 01:49:41 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 21 Feb 2015 00:49:41 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424479781.3.0.853393112669.issue23492@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 02:03:08 2015 From: report at bugs.python.org (Steven Barker) Date: Sat, 21 Feb 2015 01:03:08 +0000 Subject: [issue23495] The writer.writerows method should be documented as accepting any iterable (not only a list) In-Reply-To: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za> Message-ID: <1424480588.07.0.458026651665.issue23495@psf.upfronthosting.co.za> Steven Barker added the comment: Another Stack Overflow user pointed out that the DictWriter's writerows implementation (in pure Python) unnecessarily converts whatever its argument is into a list in memory before passing it on to the builtin writer.writerows method which would accept any iterable type. Probably it should be changed to use map or a generator expression instead. So, perhaps this issue isn't purely documentation, but actually a small behavior enhancement as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 02:40:22 2015 From: report at bugs.python.org (Demian Brecht) Date: Sat, 21 Feb 2015 01:40:22 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <0A38E69E-9808-403F-AE35-05BCBC6B4D6F@gmail.com> Message-ID: Demian Brecht added the comment: Latest patch should address all comments. It also fixes the same issue in error logging which wasn?t previously accounted for. The test file has also been updated with using HTTPStatus where possible rather than hard coded ints. This is consistent with other areas in the http package. ---------- Added file: http://bugs.python.org/file38193/issue21793_logfix_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 46bfddb14cbe Lib/http/server.py --- a/Lib/http/server.py Fri Feb 20 10:34:20 2015 -0500 +++ b/Lib/http/server.py Fri Feb 20 17:37:25 2015 -0800 @@ -442,6 +442,10 @@ message = shortmsg if explain is None: explain = longmsg + + if isinstance(code, HTTPStatus): + code = code.value + self.log_error("code %d, message %s", code, message) # using _quote_html to prevent Cross Site Scripting attacks (see bug #1100201) content = (self.error_message_format % @@ -517,6 +521,8 @@ This is called by send_response(). """ + if isinstance(code, HTTPStatus): + code = code.value self.log_message('"%s" %s %s', self.requestline, str(code), str(size)) diff -r 46bfddb14cbe Lib/test/test_httpservers.py --- a/Lib/test/test_httpservers.py Fri Feb 20 10:34:20 2015 -0500 +++ b/Lib/test/test_httpservers.py Fri Feb 20 17:37:25 2015 -0800 @@ -6,7 +6,7 @@ from http.server import BaseHTTPRequestHandler, HTTPServer, \ SimpleHTTPRequestHandler, CGIHTTPRequestHandler -from http import server +from http import server, HTTPStatus import os import sys @@ -79,13 +79,13 @@ default_request_version = 'HTTP/1.1' def do_TEST(self): - self.send_response(204) + self.send_response(HTTPStatus.NO_CONTENT) self.send_header('Content-Type', 'text/html') self.send_header('Connection', 'close') self.end_headers() def do_KEEP(self): - self.send_response(204) + self.send_response(HTTPStatus.NO_CONTENT) self.send_header('Content-Type', 'text/html') self.send_header('Connection', 'keep-alive') self.end_headers() @@ -94,7 +94,7 @@ self.send_error(999) def do_NOTFOUND(self): - self.send_error(404) + self.send_error(HTTPStatus.NOT_FOUND) def do_EXPLAINERROR(self): self.send_error(999, "Short Message", @@ -122,35 +122,35 @@ def test_command(self): self.con.request('GET', '/') res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_request_line_trimming(self): self.con._http_vsn_str = 'HTTP/1.1\n' self.con.putrequest('XYZBOGUS', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_version_bogus(self): self.con._http_vsn_str = 'FUBAR' self.con.putrequest('GET', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 400) + self.assertEqual(res.status, HTTPStatus.BAD_REQUEST) def test_version_digits(self): self.con._http_vsn_str = 'HTTP/9.9.9' self.con.putrequest('GET', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 400) + self.assertEqual(res.status, HTTPStatus.BAD_REQUEST) def test_version_none_get(self): self.con._http_vsn_str = '' self.con.putrequest('GET', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_version_none(self): # Test that a valid method is rejected when not HTTP/1.x @@ -158,7 +158,7 @@ self.con.putrequest('CUSTOM', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 400) + self.assertEqual(res.status, HTTPStatus.BAD_REQUEST) def test_version_invalid(self): self.con._http_vsn = 99 @@ -166,21 +166,21 @@ self.con.putrequest('GET', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 505) + self.assertEqual(res.status, HTTPStatus.HTTP_VERSION_NOT_SUPPORTED) def test_send_blank(self): self.con._http_vsn_str = '' self.con.putrequest('', '') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 400) + self.assertEqual(res.status, HTTPStatus.BAD_REQUEST) def test_header_close(self): self.con.putrequest('GET', '/') self.con.putheader('Connection', 'close') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_head_keep_alive(self): self.con._http_vsn_str = 'HTTP/1.1' @@ -188,12 +188,12 @@ self.con.putheader('Connection', 'keep-alive') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_handler(self): self.con.request('TEST', '/') res = self.con.getresponse() - self.assertEqual(res.status, 204) + self.assertEqual(res.status, HTTPStatus.NO_CONTENT) def test_return_header_keep_alive(self): self.con.request('KEEP', '/') @@ -230,11 +230,48 @@ # Issue #16088: standard error responses should have a content-length self.con.request('NOTFOUND', '/') res = self.con.getresponse() - self.assertEqual(res.status, 404) + self.assertEqual(res.status, HTTPStatus.NOT_FOUND) + data = res.read() self.assertEqual(int(res.getheader('Content-Length')), len(data)) +class RequestHandlerLoggingTestCase(BaseTestCase): + class request_handler(BaseHTTPRequestHandler): + protocol_version = 'HTTP/1.1' + default_request_version = 'HTTP/1.1' + + def do_GET(self): + self.send_response(HTTPStatus.OK) + self.end_headers() + + def do_ERROR(self): + self.send_error(HTTPStatus.NOT_FOUND, 'File not found') + + def test_get(self): + self.con = http.client.HTTPConnection(self.HOST, self.PORT) + self.con.connect() + + with support.captured_stderr() as err: + self.con.request('GET', '/') + self.con.getresponse() + + self.assertTrue( + err.getvalue().endswith('"GET / HTTP/1.1" 200 -\n')) + + def test_err(self): + self.con = http.client.HTTPConnection(self.HOST, self.PORT) + self.con.connect() + + with support.captured_stderr() as err: + self.con.request('ERROR', '/') + self.con.getresponse() + + lines = err.getvalue().split('\n') + self.assertTrue(lines[0].endswith('code 404, message File not found')) + self.assertTrue(lines[1].endswith('"ERROR / HTTP/1.1" 404 -')) + + class SimpleHTTPServerTestCase(BaseTestCase): class request_handler(NoLogRequestHandler, SimpleHTTPRequestHandler): pass @@ -285,52 +322,52 @@ if name != 'test': # Ignore a filename created in setUp(). filename = name break - body = self.check_status_and_reason(response, 200) + body = self.check_status_and_reason(response, HTTPStatus.OK) quotedname = urllib.parse.quote(filename, errors='surrogatepass') self.assertIn(('href="%s"' % quotedname) .encode(enc, 'surrogateescape'), body) self.assertIn(('>%s<' % html.escape(filename)) .encode(enc, 'surrogateescape'), body) response = self.request(self.tempdir_name + '/' + quotedname) - self.check_status_and_reason(response, 200, + self.check_status_and_reason(response, HTTPStatus.OK, data=support.TESTFN_UNDECODABLE) def test_get(self): #constructs the path relative to the root directory of the HTTPServer response = self.request(self.tempdir_name + '/test') - self.check_status_and_reason(response, 200, data=self.data) + self.check_status_and_reason(response, HTTPStatus.OK, data=self.data) # check for trailing "/" which should return 404. See Issue17324 response = self.request(self.tempdir_name + '/test/') - self.check_status_and_reason(response, 404) + self.check_status_and_reason(response, HTTPStatus.NOT_FOUND) response = self.request(self.tempdir_name + '/') - self.check_status_and_reason(response, 200) + self.check_status_and_reason(response, HTTPStatus.OK) response = self.request(self.tempdir_name) - self.check_status_and_reason(response, 301) + self.check_status_and_reason(response, HTTPStatus.MOVED_PERMANENTLY) response = self.request(self.tempdir_name + '/?hi=2') - self.check_status_and_reason(response, 200) + self.check_status_and_reason(response, HTTPStatus.OK) response = self.request(self.tempdir_name + '?hi=1') - self.check_status_and_reason(response, 301) + self.check_status_and_reason(response, HTTPStatus.MOVED_PERMANENTLY) self.assertEqual(response.getheader("Location"), self.tempdir_name + "/?hi=1") response = self.request('/ThisDoesNotExist') - self.check_status_and_reason(response, 404) + self.check_status_and_reason(response, HTTPStatus.NOT_FOUND) response = self.request('/' + 'ThisDoesNotExist' + '/') - self.check_status_and_reason(response, 404) + self.check_status_and_reason(response, HTTPStatus.NOT_FOUND) with open(os.path.join(self.tempdir_name, 'index.html'), 'w') as f: response = self.request('/' + self.tempdir_name + '/') - self.check_status_and_reason(response, 200) + self.check_status_and_reason(response, HTTPStatus.OK) # chmod() doesn't work as expected on Windows, and filesystem # permissions are ignored by root on Unix. if os.name == 'posix' and os.geteuid() != 0: os.chmod(self.tempdir, 0) response = self.request(self.tempdir_name + '/') - self.check_status_and_reason(response, 404) + self.check_status_and_reason(response, HTTPStatus.NOT_FOUND) os.chmod(self.tempdir, 0o755) def test_head(self): response = self.request( self.tempdir_name + '/test', method='HEAD') - self.check_status_and_reason(response, 200) + self.check_status_and_reason(response, HTTPStatus.OK) self.assertEqual(response.getheader('content-length'), str(len(self.data))) self.assertEqual(response.getheader('content-type'), @@ -338,12 +375,12 @@ def test_invalid_requests(self): response = self.request('/', method='FOO') - self.check_status_and_reason(response, 501) + self.check_status_and_reason(response, HTTPStatus.NOT_IMPLEMENTED) # requests must be case sensitive,so this should fail too response = self.request('/', method='custom') - self.check_status_and_reason(response, 501) + self.check_status_and_reason(response, HTTPStatus.NOT_IMPLEMENTED) response = self.request('/', method='GETs') - self.check_status_and_reason(response, 501) + self.check_status_and_reason(response, HTTPStatus.NOT_IMPLEMENTED) cgi_file1 = """\ @@ -490,12 +527,13 @@ def test_headers_and_content(self): res = self.request('/cgi-bin/file1.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), (res.read(), res.getheader('Content-type'), res.status)) def test_issue19435(self): res = self.request('///////////nocgi.py/../cgi-bin/nothere.sh') - self.assertEqual(res.status, 404) + self.assertEqual(res.status, HTTPStatus.NOT_FOUND) def test_post(self): params = urllib.parse.urlencode( @@ -508,38 +546,43 @@ def test_invaliduri(self): res = self.request('/cgi-bin/invalid') res.read() - self.assertEqual(res.status, 404) + self.assertEqual(res.status, HTTPStatus.NOT_FOUND) def test_authorization(self): headers = {b'Authorization' : b'Basic ' + base64.b64encode(b'username:pass')} res = self.request('/cgi-bin/file1.py', 'GET', headers=headers) - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) def test_no_leading_slash(self): # http://bugs.python.org/issue2254 res = self.request('cgi-bin/file1.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) def test_os_environ_is_not_altered(self): signature = "Test CGI Server" os.environ['SERVER_SOFTWARE'] = signature res = self.request('/cgi-bin/file1.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) self.assertEqual(os.environ['SERVER_SOFTWARE'], signature) def test_urlquote_decoding_in_cgi_check(self): res = self.request('/cgi-bin%2ffile1.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) def test_nested_cgi_path_issue21323(self): res = self.request('/cgi-bin/child-dir/file3.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) class SocketlessRequestHandler(SimpleHTTPRequestHandler): @@ -549,7 +592,7 @@ def do_GET(self): self.get_called = True - self.send_response(200) + self.send_response(HTTPStatus.OK) self.send_header('Content-Type', 'text/html') self.end_headers() self.wfile.write(b'Data\r\n') @@ -559,7 +602,7 @@ class RejectingSocketlessRequestHandler(SocketlessRequestHandler): def handle_expect_100(self): - self.send_error(417) + self.send_error(HTTPStatus.EXPECTATION_FAILED) return False @@ -816,6 +859,7 @@ cwd = os.getcwd() try: support.run_unittest( + RequestHandlerLoggingTestCase, BaseHTTPRequestHandlerTestCase, BaseHTTPServerTestCase, SimpleHTTPServerTestCase, From report at bugs.python.org Sat Feb 21 04:26:13 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 21 Feb 2015 03:26:13 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1424489173.18.0.338189029195.issue23484@psf.upfronthosting.co.za> Davin Potts added the comment: Of course, there's code in the wild that expects and uses the parameter named 'block' so simply changing this keyword will result in breaking others' code. Two potentially appealing options: 1) Document that acquire in multiprocessing differs from threading in this way. 2) Implement 'blocking' as a supported keyword argument though preserve support for 'block' as a deprecated keyword. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 05:11:37 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Feb 2015 04:11:37 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1424491897.03.0.49603694458.issue21793@psf.upfronthosting.co.za> Martin Panter added the comment: I think you will find the error logging was already fine, since it already uses %d: 127.0.0.1 - - [21/Feb/2015 04:02:06] code 404, message File not found 127.0.0.1 - - [21/Feb/2015 04:02:06] "GET /nonexistant HTTP/1.1" HTTPStatus.NOT_FOUND - The new codes in the tests look okay though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 05:30:53 2015 From: report at bugs.python.org (Pavel Roskin) Date: Sat, 21 Feb 2015 04:30:53 +0000 Subject: [issue16786] argparse doesn't offer localization interface for "version" action In-Reply-To: <1356527998.28.0.00679479762722.issue16786@psf.upfronthosting.co.za> Message-ID: <1424493053.36.0.982798687432.issue16786@psf.upfronthosting.co.za> Pavel Roskin added the comment: I have tested the patch. It fixes the problem for me. You are right, new programs would just supply translated help to the version action. No effort would be saved. But the programs updated from the deprecated syntax may rely on a separate string list for translating strings found in argparse.py. They would lose the translation for the "--version" help without any warning. Debugging and fixing that would take some effort. ---------- nosy: +proski _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 06:04:05 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 21 Feb 2015 05:04:05 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424495045.09.0.163311501448.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Attached is a patch for the bz2 module. ---------- Added file: http://bugs.python.org/file38194/issue15955_bz2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 06:58:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 05:58:22 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1424498302.96.0.887016782891.issue20204@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 07:03:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 06:03:16 +0000 Subject: [issue22113] memoryview and struct.pack_into In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za> Message-ID: <1424498596.77.0.495769802143.issue22113@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Benjamin, what are your thoughts as RM? > Something similar should be applied to 3.x because PyObject_AsWriteBuffer() is deprecated and not safe. Done in issue22896. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 07:19:28 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Feb 2015 06:19:28 +0000 Subject: [issue19023] ctypes docs: Unimplemented and undocumented features In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za> Message-ID: <1424499568.06.0.093079268419.issue19023@psf.upfronthosting.co.za> Martin Panter added the comment: Posting a new patch, rebased against the recent ?default? (3.5) branch: * Tweaked so that sentences start with a capital letter * Added _Pointer.contents ---------- Added file: http://bugs.python.org/file38195/arrays-pointers.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 10:07:41 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Feb 2015 09:07:41 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <1424509661.7.0.21958709745.issue14285@psf.upfronthosting.co.za> Martin Panter added the comment: The relevant code is in the _get_module_details() function at Lib/runpy.py:101. There are a few of things going on: 1. The code is calling importlib.util.find_spec(".__main__"), and handles various kinds of exceptions by wrapping them in an ImportError, adding the ?Error while finding spec? message. The call apparently causes the package to be imported, so some exceptions triggered by running __init__.py are wrapped. It would be nice if exceptions raised by running __init__.py were not caught, but I have no idea if this is practical or how to do it. It seems the exception handler is there to raise ImportError if you do something like ?python -m os.path.something?, which seems rather unlikely to me. 2. The logic for handling the __main__ module in a package seems to assume that any ImportError (such as raised from step 1) is due to the __main__ module not being present. Then it wraps that exception in another ImportError, adding the ?. . . cannot be directly executed? bit. Again, it would be good to separate the __init__.py running from this exception handling. 3. Finally in _run_module_as_main(), the ImportError is caught and printed, without any traceback. It would be good to only do this for internal errors loading the module, and not if ImportError is raised when the module (or __init__.py) is run. I?m not sure what the best way to fix this is. Perhaps add an internal ImportError subclass (or subclasses) that is only used for the ?No module named . . .? errors, or only used for errors appropriate for final handler in step 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 11:03:13 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Feb 2015 10:03:13 +0000 Subject: [issue23224] LZMADecompressor object is only initialized in __init__ In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za> Message-ID: <1424512993.67.0.550611317566.issue23224@psf.upfronthosting.co.za> Martin Panter added the comment: Similar situation in the bzip module: >>> BZ2Decompressor.__new__(BZ2Decompressor).decompress(bytes()) Segmentation fault (core dumped) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 11:10:13 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Feb 2015 10:10:13 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424513413.29.0.843275355239.issue15955@psf.upfronthosting.co.za> Martin Panter added the comment: The new bzip parameter still needs documenting in the library reference. However I reviewed the doc string, C code, and tests, and I can?t find anything wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 11:12:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Feb 2015 10:12:03 +0000 Subject: [issue9179] Lookback with group references incorrect (two issues?) In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za> Message-ID: <20150221101200.6730.80701@psf.io> Roundup Robot added the comment: New changeset b78195af96f5 by Serhiy Storchaka in branch 'default': Issues #814253, #9179: Group references and conditional group references now https://hg.python.org/cpython/rev/b78195af96f5 New changeset 5387095b8675 by Serhiy Storchaka in branch '2.7': Issues #814253, #9179: Warnings now are raised when group references and https://hg.python.org/cpython/rev/5387095b8675 New changeset e295ad9be16d by Serhiy Storchaka in branch '3.4': Issues #814253, #9179: Warnings now are raised when group references and https://hg.python.org/cpython/rev/e295ad9be16d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 11:12:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Feb 2015 10:12:03 +0000 Subject: [issue814253] Grouprefs in lookbehind assertions Message-ID: <20150221101200.6730.90801@psf.io> Roundup Robot added the comment: New changeset b78195af96f5 by Serhiy Storchaka in branch 'default': Issues #814253, #9179: Group references and conditional group references now https://hg.python.org/cpython/rev/b78195af96f5 New changeset 5387095b8675 by Serhiy Storchaka in branch '2.7': Issues #814253, #9179: Warnings now are raised when group references and https://hg.python.org/cpython/rev/5387095b8675 New changeset e295ad9be16d by Serhiy Storchaka in branch '3.4': Issues #814253, #9179: Warnings now are raised when group references and https://hg.python.org/cpython/rev/e295ad9be16d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 11:19:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 10:19:07 +0000 Subject: [issue9179] Lookback with group references incorrect (two issues?) In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za> Message-ID: <1424513947.38.0.87931920431.issue9179@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Only warnings are raised in 2.7 and 3.4, so it will not break third party code that "works" by accident. In 3.5 only references to groups defined outside of lookbehind assertion work, so the behavior is compatible with regex. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 11:19:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 10:19:37 +0000 Subject: [issue9179] Lookback with group references incorrect (two issues?) In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za> Message-ID: <1424513977.07.0.183750125453.issue9179@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 11:22:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 10:22:18 +0000 Subject: [issue23252] Add support of writing to unseekable file in zipfile In-Reply-To: <1421438148.04.0.307260333821.issue23252@psf.upfronthosting.co.za> Message-ID: <1424514138.14.0.958047977669.issue23252@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please make a review of the documentation part of the patch David? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 11:44:07 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 21 Feb 2015 10:44:07 +0000 Subject: [issue23495] The writer.writerows method should be documented as accepting any iterable (not only a list) In-Reply-To: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za> Message-ID: <1424515447.89.0.291992584073.issue23495@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 15:13:47 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 21 Feb 2015 14:13:47 +0000 Subject: [issue23495] The writer.writerows method should be documented as accepting any iterable (not only a list) In-Reply-To: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za> Message-ID: <1424528027.92.0.0417856998902.issue23495@psf.upfronthosting.co.za> R. David Murray added the comment: Seems reasonable to me. Do you want to prepare patches? The doc patch should be separate, since it applies to all active versions, but the code change to dictwriter would go only into 3.5. ---------- stage: -> needs patch versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 15:29:25 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 21 Feb 2015 14:29:25 +0000 Subject: [issue23147] Possible error in _header_value_parser.py In-Reply-To: <1420194679.08.0.467668822135.issue23147@psf.upfronthosting.co.za> Message-ID: <1424528965.18.0.662766006145.issue23147@psf.upfronthosting.co.za> R. David Murray added the comment: Probably. What I need is a test case that triggers it. (FYI, I know there are other bugs in that algorithm...what I really need to do is completely rewrite it to be simpler and more understandable, but there are so many edge cases that I haven't found the time to tackle it yet). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 15:35:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 14:35:09 +0000 Subject: [issue23147] Possible error in _header_value_parser.py In-Reply-To: <1420194679.08.0.467668822135.issue23147@psf.upfronthosting.co.za> Message-ID: <1424529309.49.0.99988857765.issue23147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If I had a test case, I would write the patch. But I'm not experienced in the email package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 15:39:52 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 21 Feb 2015 14:39:52 +0000 Subject: [issue23147] Possible error in _header_value_parser.py In-Reply-To: <1420194679.08.0.467668822135.issue23147@psf.upfronthosting.co.za> Message-ID: <1424529592.36.0.108664563368.issue23147@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, I assumed that you didn't have a test case. I was explaining why I hadn't done anything with this issue :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 15:47:13 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 21 Feb 2015 14:47:13 +0000 Subject: [issue23434] RFC6266 support (Content-Disposition for HTTP) In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za> Message-ID: <1424530033.51.0.306725789049.issue23434@psf.upfronthosting.co.za> R. David Murray added the comment: I know it is called the 'email' package, but the intent is to support http header parsing as well (cf email.policy.HTTP). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 16:04:19 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 21 Feb 2015 15:04:19 +0000 Subject: [issue23436] xml.dom.minidom.Element.ownerDocument is hiden In-Reply-To: <1423596643.73.0.960398071264.issue23436@psf.upfronthosting.co.za> Message-ID: <1424531059.5.0.210356911293.issue23436@psf.upfronthosting.co.za> R. David Murray added the comment: It looks like the __slots__ declaration on Node was missed when the other slots changes were made (by MvL in 3931f043b79a). Note that the Node base class (xml.dom.Node) has a __slots__ declaration, but it was added after MvL's patch (by Florent in 49c5511b234a). Changing this now may have backward compatibility issues, though. ---------- nosy: +flox, loewis, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 16:36:58 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 21 Feb 2015 15:36:58 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424533018.2.0.599266075732.issue23492@psf.upfronthosting.co.za> Stefan Behnel added the comment: Serhiy, I suggest you look at the code that Cython generates for its functions. It has been extensively profiled and optimised (years ago), so generating the same code for the argument clinic should yield the same performance. And while I don't have exact numbers at hand, avoiding the tuple packing for the call by passing it into a METH_O function can make a substantial difference. It also kills support for keyword arguments, though. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 16:38:06 2015 From: report at bugs.python.org (Sahil Chelaramani) Date: Sat, 21 Feb 2015 15:38:06 +0000 Subject: [issue23322] parser module docs missing second example In-Reply-To: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za> Message-ID: <1424533086.12.0.375909575048.issue23322@psf.upfronthosting.co.za> Sahil Chelaramani added the comment: A patch for this bug. Please let me know if I have to change something. First patch, please be kind :) ---------- keywords: +patch nosy: +SahilC Added file: http://bugs.python.org/file38196/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 16:59:58 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 21 Feb 2015 15:59:58 +0000 Subject: [issue23148] Missing the charset parameter in as_encoded_word() In-Reply-To: <1420195099.17.0.393236049779.issue23148@psf.upfronthosting.co.za> Message-ID: <1424534398.05.0.899448425375.issue23148@psf.upfronthosting.co.za> R. David Murray added the comment: Same comment as the fold bug...I need to find time to work out a test case (or for someone else to do so). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 17:03:16 2015 From: report at bugs.python.org (Demian Brecht) Date: Sat, 21 Feb 2015 16:03:16 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1424491897.03.0.49603694458.issue21793@psf.upfronthosting.co.za> Message-ID: <4BFCABF9-A563-43C3-8A36-0F360CFDF538@gmail.com> Demian Brecht added the comment: Well, I?m not entirely sure how I came to the conclusion that errors were a problem (other than not spending enough time walking through it) and of course you?re right about the coercion handling it just fine. I?ve removed the explicit conversion in the code but have left the tests as they?re not tested elsewhere. Hopefully that should now wrap this up. ---------- Added file: http://bugs.python.org/file38197/issue21793_logfix_4.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 46bfddb14cbe Lib/http/server.py --- a/Lib/http/server.py Fri Feb 20 10:34:20 2015 -0500 +++ b/Lib/http/server.py Sat Feb 21 07:59:08 2015 -0800 @@ -517,6 +517,8 @@ This is called by send_response(). """ + if isinstance(code, HTTPStatus): + code = code.value self.log_message('"%s" %s %s', self.requestline, str(code), str(size)) diff -r 46bfddb14cbe Lib/test/test_httpservers.py --- a/Lib/test/test_httpservers.py Fri Feb 20 10:34:20 2015 -0500 +++ b/Lib/test/test_httpservers.py Sat Feb 21 07:59:08 2015 -0800 @@ -6,7 +6,7 @@ from http.server import BaseHTTPRequestHandler, HTTPServer, \ SimpleHTTPRequestHandler, CGIHTTPRequestHandler -from http import server +from http import server, HTTPStatus import os import sys @@ -79,13 +79,13 @@ default_request_version = 'HTTP/1.1' def do_TEST(self): - self.send_response(204) + self.send_response(HTTPStatus.NO_CONTENT) self.send_header('Content-Type', 'text/html') self.send_header('Connection', 'close') self.end_headers() def do_KEEP(self): - self.send_response(204) + self.send_response(HTTPStatus.NO_CONTENT) self.send_header('Content-Type', 'text/html') self.send_header('Connection', 'keep-alive') self.end_headers() @@ -94,7 +94,7 @@ self.send_error(999) def do_NOTFOUND(self): - self.send_error(404) + self.send_error(HTTPStatus.NOT_FOUND) def do_EXPLAINERROR(self): self.send_error(999, "Short Message", @@ -122,35 +122,35 @@ def test_command(self): self.con.request('GET', '/') res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_request_line_trimming(self): self.con._http_vsn_str = 'HTTP/1.1\n' self.con.putrequest('XYZBOGUS', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_version_bogus(self): self.con._http_vsn_str = 'FUBAR' self.con.putrequest('GET', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 400) + self.assertEqual(res.status, HTTPStatus.BAD_REQUEST) def test_version_digits(self): self.con._http_vsn_str = 'HTTP/9.9.9' self.con.putrequest('GET', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 400) + self.assertEqual(res.status, HTTPStatus.BAD_REQUEST) def test_version_none_get(self): self.con._http_vsn_str = '' self.con.putrequest('GET', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_version_none(self): # Test that a valid method is rejected when not HTTP/1.x @@ -158,7 +158,7 @@ self.con.putrequest('CUSTOM', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 400) + self.assertEqual(res.status, HTTPStatus.BAD_REQUEST) def test_version_invalid(self): self.con._http_vsn = 99 @@ -166,21 +166,21 @@ self.con.putrequest('GET', '/') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 505) + self.assertEqual(res.status, HTTPStatus.HTTP_VERSION_NOT_SUPPORTED) def test_send_blank(self): self.con._http_vsn_str = '' self.con.putrequest('', '') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 400) + self.assertEqual(res.status, HTTPStatus.BAD_REQUEST) def test_header_close(self): self.con.putrequest('GET', '/') self.con.putheader('Connection', 'close') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_head_keep_alive(self): self.con._http_vsn_str = 'HTTP/1.1' @@ -188,12 +188,12 @@ self.con.putheader('Connection', 'keep-alive') self.con.endheaders() res = self.con.getresponse() - self.assertEqual(res.status, 501) + self.assertEqual(res.status, HTTPStatus.NOT_IMPLEMENTED) def test_handler(self): self.con.request('TEST', '/') res = self.con.getresponse() - self.assertEqual(res.status, 204) + self.assertEqual(res.status, HTTPStatus.NO_CONTENT) def test_return_header_keep_alive(self): self.con.request('KEEP', '/') @@ -230,11 +230,48 @@ # Issue #16088: standard error responses should have a content-length self.con.request('NOTFOUND', '/') res = self.con.getresponse() - self.assertEqual(res.status, 404) + self.assertEqual(res.status, HTTPStatus.NOT_FOUND) + data = res.read() self.assertEqual(int(res.getheader('Content-Length')), len(data)) +class RequestHandlerLoggingTestCase(BaseTestCase): + class request_handler(BaseHTTPRequestHandler): + protocol_version = 'HTTP/1.1' + default_request_version = 'HTTP/1.1' + + def do_GET(self): + self.send_response(HTTPStatus.OK) + self.end_headers() + + def do_ERROR(self): + self.send_error(HTTPStatus.NOT_FOUND, 'File not found') + + def test_get(self): + self.con = http.client.HTTPConnection(self.HOST, self.PORT) + self.con.connect() + + with support.captured_stderr() as err: + self.con.request('GET', '/') + self.con.getresponse() + + self.assertTrue( + err.getvalue().endswith('"GET / HTTP/1.1" 200 -\n')) + + def test_err(self): + self.con = http.client.HTTPConnection(self.HOST, self.PORT) + self.con.connect() + + with support.captured_stderr() as err: + self.con.request('ERROR', '/') + self.con.getresponse() + + lines = err.getvalue().split('\n') + self.assertTrue(lines[0].endswith('code 404, message File not found')) + self.assertTrue(lines[1].endswith('"ERROR / HTTP/1.1" 404 -')) + + class SimpleHTTPServerTestCase(BaseTestCase): class request_handler(NoLogRequestHandler, SimpleHTTPRequestHandler): pass @@ -285,52 +322,52 @@ if name != 'test': # Ignore a filename created in setUp(). filename = name break - body = self.check_status_and_reason(response, 200) + body = self.check_status_and_reason(response, HTTPStatus.OK) quotedname = urllib.parse.quote(filename, errors='surrogatepass') self.assertIn(('href="%s"' % quotedname) .encode(enc, 'surrogateescape'), body) self.assertIn(('>%s<' % html.escape(filename)) .encode(enc, 'surrogateescape'), body) response = self.request(self.tempdir_name + '/' + quotedname) - self.check_status_and_reason(response, 200, + self.check_status_and_reason(response, HTTPStatus.OK, data=support.TESTFN_UNDECODABLE) def test_get(self): #constructs the path relative to the root directory of the HTTPServer response = self.request(self.tempdir_name + '/test') - self.check_status_and_reason(response, 200, data=self.data) + self.check_status_and_reason(response, HTTPStatus.OK, data=self.data) # check for trailing "/" which should return 404. See Issue17324 response = self.request(self.tempdir_name + '/test/') - self.check_status_and_reason(response, 404) + self.check_status_and_reason(response, HTTPStatus.NOT_FOUND) response = self.request(self.tempdir_name + '/') - self.check_status_and_reason(response, 200) + self.check_status_and_reason(response, HTTPStatus.OK) response = self.request(self.tempdir_name) - self.check_status_and_reason(response, 301) + self.check_status_and_reason(response, HTTPStatus.MOVED_PERMANENTLY) response = self.request(self.tempdir_name + '/?hi=2') - self.check_status_and_reason(response, 200) + self.check_status_and_reason(response, HTTPStatus.OK) response = self.request(self.tempdir_name + '?hi=1') - self.check_status_and_reason(response, 301) + self.check_status_and_reason(response, HTTPStatus.MOVED_PERMANENTLY) self.assertEqual(response.getheader("Location"), self.tempdir_name + "/?hi=1") response = self.request('/ThisDoesNotExist') - self.check_status_and_reason(response, 404) + self.check_status_and_reason(response, HTTPStatus.NOT_FOUND) response = self.request('/' + 'ThisDoesNotExist' + '/') - self.check_status_and_reason(response, 404) + self.check_status_and_reason(response, HTTPStatus.NOT_FOUND) with open(os.path.join(self.tempdir_name, 'index.html'), 'w') as f: response = self.request('/' + self.tempdir_name + '/') - self.check_status_and_reason(response, 200) + self.check_status_and_reason(response, HTTPStatus.OK) # chmod() doesn't work as expected on Windows, and filesystem # permissions are ignored by root on Unix. if os.name == 'posix' and os.geteuid() != 0: os.chmod(self.tempdir, 0) response = self.request(self.tempdir_name + '/') - self.check_status_and_reason(response, 404) + self.check_status_and_reason(response, HTTPStatus.NOT_FOUND) os.chmod(self.tempdir, 0o755) def test_head(self): response = self.request( self.tempdir_name + '/test', method='HEAD') - self.check_status_and_reason(response, 200) + self.check_status_and_reason(response, HTTPStatus.OK) self.assertEqual(response.getheader('content-length'), str(len(self.data))) self.assertEqual(response.getheader('content-type'), @@ -338,12 +375,12 @@ def test_invalid_requests(self): response = self.request('/', method='FOO') - self.check_status_and_reason(response, 501) + self.check_status_and_reason(response, HTTPStatus.NOT_IMPLEMENTED) # requests must be case sensitive,so this should fail too response = self.request('/', method='custom') - self.check_status_and_reason(response, 501) + self.check_status_and_reason(response, HTTPStatus.NOT_IMPLEMENTED) response = self.request('/', method='GETs') - self.check_status_and_reason(response, 501) + self.check_status_and_reason(response, HTTPStatus.NOT_IMPLEMENTED) cgi_file1 = """\ @@ -490,12 +527,13 @@ def test_headers_and_content(self): res = self.request('/cgi-bin/file1.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), (res.read(), res.getheader('Content-type'), res.status)) def test_issue19435(self): res = self.request('///////////nocgi.py/../cgi-bin/nothere.sh') - self.assertEqual(res.status, 404) + self.assertEqual(res.status, HTTPStatus.NOT_FOUND) def test_post(self): params = urllib.parse.urlencode( @@ -508,38 +546,43 @@ def test_invaliduri(self): res = self.request('/cgi-bin/invalid') res.read() - self.assertEqual(res.status, 404) + self.assertEqual(res.status, HTTPStatus.NOT_FOUND) def test_authorization(self): headers = {b'Authorization' : b'Basic ' + base64.b64encode(b'username:pass')} res = self.request('/cgi-bin/file1.py', 'GET', headers=headers) - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) def test_no_leading_slash(self): # http://bugs.python.org/issue2254 res = self.request('cgi-bin/file1.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) def test_os_environ_is_not_altered(self): signature = "Test CGI Server" os.environ['SERVER_SOFTWARE'] = signature res = self.request('/cgi-bin/file1.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) self.assertEqual(os.environ['SERVER_SOFTWARE'], signature) def test_urlquote_decoding_in_cgi_check(self): res = self.request('/cgi-bin%2ffile1.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) def test_nested_cgi_path_issue21323(self): res = self.request('/cgi-bin/child-dir/file3.py') - self.assertEqual((b'Hello World' + self.linesep, 'text/html', 200), - (res.read(), res.getheader('Content-type'), res.status)) + self.assertEqual( + (b'Hello World' + self.linesep, 'text/html', HTTPStatus.OK), + (res.read(), res.getheader('Content-type'), res.status)) class SocketlessRequestHandler(SimpleHTTPRequestHandler): @@ -549,7 +592,7 @@ def do_GET(self): self.get_called = True - self.send_response(200) + self.send_response(HTTPStatus.OK) self.send_header('Content-Type', 'text/html') self.end_headers() self.wfile.write(b'Data\r\n') @@ -559,7 +602,7 @@ class RejectingSocketlessRequestHandler(SocketlessRequestHandler): def handle_expect_100(self): - self.send_error(417) + self.send_error(HTTPStatus.EXPECTATION_FAILED) return False @@ -816,6 +859,7 @@ cwd = os.getcwd() try: support.run_unittest( + RequestHandlerLoggingTestCase, BaseHTTPRequestHandlerTestCase, BaseHTTPServerTestCase, SimpleHTTPServerTestCase, From report at bugs.python.org Sat Feb 21 17:09:39 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 21 Feb 2015 16:09:39 +0000 Subject: [issue22113] memoryview and struct.pack_into In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za> Message-ID: <1424534979.19.0.321523870883.issue22113@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I suppose this is okay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 17:10:03 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 21 Feb 2015 16:10:03 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424535003.72.0.594783080939.issue23492@psf.upfronthosting.co.za> Larry Hastings added the comment: Stefan: Serhiy's patch only affects functions taking a single positional-only parameter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 17:30:26 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 21 Feb 2015 16:30:26 +0000 Subject: [issue13637] binascii.a2b_* functions could accept unicode strings In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za> Message-ID: <1424536226.31.0.193922438715.issue13637@psf.upfronthosting.co.za> R. David Murray added the comment: I think this doc change was incorrect. The current document is supposed to provide the correct historical information. So "changed in 3.3: accept ASCII input" (and just ignore the fact that 3.1 also accepted ascii, since we pretty much prefer to ignore the existence of 3.0 and 3.1 :) would be the better choice, IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 17:50:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Feb 2015 16:50:45 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <20150221165042.99276.12894@psf.io> Roundup Robot added the comment: New changeset 4f6f4aa0d80f by Steve Dower in branch 'default': Issue #23152: Implement _Py_fstat() to support files larger than 2 GB on Windows. https://hg.python.org/cpython/rev/4f6f4aa0d80f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 18:40:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 17:40:50 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1424540450.68.0.569623820299.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch now supports wideInt if PY_LONG_LONG is not defined or is not equal to Tcl_WideInt. getint() also now supports big integers (currently it returns ambiguous result for values outside the range of C signed int). As far as this issue causes random tests failures, may be it makes sense to apply the patch to maintained releases. On other hand, looks as this happens very rarely. ---------- keywords: +needs review nosy: +benjamin.peterson Added file: http://bugs.python.org/file38198/tkinter_bignum_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 18:41:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 17:41:06 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1424540466.44.0.602122275976.issue16840@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file28551/tkinter_bignum.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 18:41:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 17:41:13 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1424540473.84.0.804962677166.issue16840@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file31420/tkinter_bignum_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 18:41:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 17:41:51 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1424540511.61.0.401391056471.issue16840@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file35280/tkinter_bignum_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 18:45:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 21 Feb 2015 17:45:53 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <20150221165042.99276.12894@psf.io> Message-ID: STINNER Victor added the comment: The name of attribute_data_to_stat() and other shared functions must be prefixed by "_Py". +/* Return size of file in bytes; < 0 if unknown or INT_MAX if too big */ static off_t getfilesize(FILE *fp) Hum since we have a type able yo store the file size and the function is private, you should use the type able to store the size. Maybe off_t on POSIX and something else on Windows. Is Py_off_t type 64 bits? I'm the sure that the caller works if getfilesize() returns a truncated size. @@ -420,9 +420,11 @@ fileio_init(PyObject *oself, PyObject *a } self->blksize = DEFAULT_BUFFER_SIZE; -#ifdef HAVE_FSTAT - if (fstat(self->fd, &fdfstat) < 0) +#if defined(HAVE_FSTAT) || defined(MS_WINDOWS) + if (_Py_fstat(self->fd, &fdfstat) < 0) { + PyErr_SetFromErrno(PyExc_OSError); goto error; + } Why do you raise an exception here? Is it a bug fix? (I cannot read the code at error label right now.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 18:53:43 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 21 Feb 2015 17:53:43 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1424541223.21.0.745481057522.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: The caller to getfilesize is only using it to check whether it's small enough to load the file into memory all at once, so "too big" is an okay response (that function is in marshal.c and not used anywhere else). The error label just returns back to the interpreter loop, previously without an exception set, so we got a SystemError. I mentioned this in my first post. Happy to rename the now shared functions - I just took those straight from your patch :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 18:57:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Feb 2015 17:57:16 +0000 Subject: [issue22113] memoryview and struct.pack_into In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za> Message-ID: <20150221175714.10174.52807@psf.io> Roundup Robot added the comment: New changeset 4d8e37e54a7d by Serhiy Storchaka in branch '2.7': Issue #22113: struct.pack_into() now supports new buffer protocol (in https://hg.python.org/cpython/rev/4d8e37e54a7d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 18:59:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 17:59:52 +0000 Subject: [issue22113] memoryview and struct.pack_into In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za> Message-ID: <1424541592.29.0.456656473111.issue22113@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 19:00:54 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 21 Feb 2015 18:00:54 +0000 Subject: [issue18382] multiprocessing's overlapped PipeConnection issues on Windows 8 In-Reply-To: <1373114737.55.0.0779572840335.issue18382@psf.upfronthosting.co.za> Message-ID: <1424541654.1.0.505351906936.issue18382@psf.upfronthosting.co.za> Steve Dower added the comment: Attached a patch to 3.5 that resolves this, and I'll backport to 3.4. I haven't got access to Windows 7 or 8 right now to test it, but it's fine on Vista without the patch and 8.1 with the patch. It'd be great if people could help check exactly which version of Windows changed the behaviour by running this code and posting their OS and whether the result is True (correct) or False (incorrect): from multiprocessing import Pipe a, b = Pipe() b.send_bytes(b'') a.poll() and a.poll() ---------- keywords: +patch nosy: +steve.dower Added file: http://bugs.python.org/file38199/18382_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 19:04:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Feb 2015 18:04:26 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <20150221180424.10172.85316@psf.io> Roundup Robot added the comment: New changeset 307713759a62 by Steve Dower in branch 'default': Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat https://hg.python.org/cpython/rev/307713759a62 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 19:04:29 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 21 Feb 2015 18:04:29 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za> Message-ID: <1424541869.01.0.297948897992.issue22834@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 19:06:40 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 21 Feb 2015 18:06:40 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1424542000.13.0.555829403182.issue16840@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I'm all for fixing random test failures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 19:07:15 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 21 Feb 2015 18:07:15 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424542035.43.0.789223803593.issue23492@psf.upfronthosting.co.za> Larry Hastings added the comment: lgtm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 19:11:07 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 21 Feb 2015 18:11:07 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1424542267.82.0.579021692507.issue23314@psf.upfronthosting.co.za> Steve Dower added the comment: Having run some more tests, it may be that the only regular problem is in the test for inherited file descriptors. I've attached a patch for tf_inherit_check.py that will prevent assert dialogs. It's not pretty, but it avoids touching the interpreter internals. I still prefer the environment variable option (and maybe add an underscore at the start/making it 'officially' undocumented?), as that will help avoid issues when new tests are added, but for now it looks like only this test needs fixing. ---------- Added file: http://bugs.python.org/file38200/23314_tf_inherit_check.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 19:22:55 2015 From: report at bugs.python.org (Taylor Marks) Date: Sat, 21 Feb 2015 18:22:55 +0000 Subject: [issue2889] curses for windows (alternative patch) In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za> Message-ID: <1424542975.09.0.05630065569.issue2889@psf.upfronthosting.co.za> Taylor Marks added the comment: Python is supposed to be cross platform. This has been a major incompatibility issue between Windows and *nix and you think this patch, which has been ready for nearly 7 years now, should simply get discarded because the fix is available from pip? I think there are two possible remedies to this: - Accept this patch. - Remove curses from the Python standard library for *nix (breaks backwards compatibility for *nix, but fixes compatibility between Windows and *nix going forward.) ---------- nosy: +Taylor.Marks _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 19:37:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 18:37:21 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424543841.9.0.038615613558.issue23492@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Serhiy, I suggest you look at the code that Cython generates for its functions. It has been extensively profiled and optimised (years ago), so generating the same code for the argument clinic should yield the same performance. Thanks, I'll look on it. > And while I don't have exact numbers at hand, avoiding the tuple packing for the call by passing it into a METH_O function can make a substantial difference. Good idea. Here are samples: $ ./python -m timeit "chr(0x20ac)" Unpatched: 1000000 loops, best of 3: 0.976 usec per loop Patched: 1000000 loops, best of 3: 0.752 usec per loop $ ./python -m timeit -s "from cmath import isnan; x = 1j" -- "isnan(x)" Unpatched: 1000000 loops, best of 3: 0.62 usec per loop Patched: 1000000 loops, best of 3: 0.386 usec per loop Of course for more complex functions the effect is smaller. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 20:02:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 19:02:55 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1424545375.83.0.833308180775.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: But there is a risk to break Python builds with old Tcl/Tk. We dropped support of Tcl/Tk older than 8.4 in 3.5, but theoretically 2.7 should work with older versions. It was not tested for years, we have no build bots with 8.3, and I manually test Python only with 8.4+ (it is harder to build 8.3, not mentioning older versions). But AFAIK wideInt was not supported in 8.3, so code and tests should be adapted for optional support of integers outside 32-bit range. I could try to build 8.3 and adapt the patch, but I'm not very motivated in this. And I can't take the responsibility of committing the patch blindly, without testing with different options. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 20:19:49 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 21 Feb 2015 19:19:49 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1424546389.74.0.102168039749.issue16840@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It's up to you. Since 2.7 is so long lived, we've had to gradually alter supported library versions (e.g. for bsddb). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 21:02:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Feb 2015 20:02:04 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424548924.94.0.241203700709.issue23492@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: After expanding PyArg_Parse for "i" and "D" codes above tests give following results: $ ./python -m timeit "chr(0x20ac)" 1000000 loops, best of 3: 0.558 usec per loop $ ./python -m timeit -s "from cmath import isnan; x = 1j" -- "isnan(x)" 1000000 loops, best of 3: 0.278 usec per loop About twice in comparison with initial variant! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 21:46:57 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sat, 21 Feb 2015 20:46:57 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 Message-ID: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> New submission from Cyd Haselton: This is a (hopefully) complete list of patches and modifications required to natively build Python 3.4.2 on an Android device where patches == listed issues in this bug tracker modifications (mods) == unsubmitted patches and/or edits made to source CAVEATS Build was completed on a tablet running Android 4.4.2 and within the KBOX environment; an app that simulates a Linux filesystem by using a ported version of fakechroot. Details of the environment can be found here: http://kevinboone.net/kbox2_how_it_works.html. NOTE: During the Python build it was necessary to patch this environment with a modified version of fakechroot; the KBOX version currently available as of 2.21.2015 may not contain the modified fakechroot. CONFIGURE && POST-CONFIGURE && MAKE The configure command was run with the following parameters --enable-shared --without-ensurepip --prefix=/usr/python After running configure. changes were made to pyconfig.h to account for various platform limitations and to Setup to ensure that a) all modules specified were built as shared and b) modules that used symbols from libpython were explicitly linked to said library. See attached pyconfig.h and Setup. Make fails when the newly built python binary tries to execute and run setup.py. This is resolved by copying the shared library from the build directory to /lib in the KBOX environment. Otherwise make && make install runs without errors provided patches/mods are applied. I did not run make test or the equivalent for this build. PATCHES/MODS The attached patches from the following issues must be applied: http://bugs.python.org/issue20305 http://bugs.python.org/issue16353 (NOTE: use patch with 'defpath' not 'confstr', which is not supported in Android) http://bugs.python.org/issue21668 The following modifications to source must be made: The instructions under 'Code Changes' at this link: https://code.google.com/p/python-for-android/wiki/CrossCompilingPython The attached patch, contributed by Ryan Gonzales (patch.diff) The changes listed below by file (apologies for formatting) /* patch for strdup segfault issue in readline.c */ #define RESTORE_LOCALE(sl) { if (sl) { setlocale(LC_CTYPE, sl); free(sl); } } char *_locale = setlocale(LC_CTYPE, NULL); char *saved_locale; if(!_locale) _locale = ""; saved_locale = strdup(_locale); char *saved_locale = setlocale(LC_CTYPE, NULL); if (saved_locale != NULL) { saved_locale = strdup(saved_locale); if (!saved_locale) Py_FatalError("not enough memory to save locale"); } /* fix for Lib/ctypes/__init.py__ */ 30 DEFAULT_MODE == RTLD_GLOBAL /* patch for python.c */ /* here line for oldloc is commented out */ 24 int i, res; 25 /* char *oldloc; */ 26 #ifdef __FreeBSD__ /* here oldloc lines commented out */ 46 47 /* oldloc = _PyMem_RawStrdup(setlocale(LC_ALL, NULL)); 48 * if (!oldloc) { 49 * fprintf(stderr, "out of memory\n"); 50 * return 1; 51 * 52 * } 53 */ /* patch for pythonrun.c 307, --309-310, ++311-313 --1009-1012 ++1013-1014 */ 305 return get_codec_name(codeset); 306 #else 307 char* m; 308 PyErr_SetNone(PyExc_NotImplementedError); 309 /* return NULL; */ 310 /* char* m; */ 311 m = malloc(6); 312 strcpy(m, "ascii"); 313 return m; 314 #endif 315 } 1002 static int 1003 initfsencoding(PyInterpreterState *interp) 1004 { 1005 PyObject *codec; 1006 1007 if (Py_FileSystemDefaultEncoding == NULL) 1008 { 1009 /* Py_FileSystemDefaultEncoding = get_locale_encoding(); 1010 * if (Py_FileSystemDefaultEncoding == NULL) 1011 * Py_FatalError("Py_Initialize: Unable to get the locale encoding 1011 "); 1012 */ 1013 Py_FileSystemDefaultEncoding = malloc(6); 1014 strcpy(Py_FileSystemDefaultEncoding, "ascii"); 1015 Py_HasFileSystemDefaultEncoding = 0; 1016 interp->fscodec_initialized = 1; 1017 return 0; 1018 } 1019 /* changes to Lib/plat-linux/DLFCN.py */ 76 # Included from bits/dlfcn.h 77 # Changed for Android 78 RTLD_LAZY = 1 79 RTLD_NOW = 0 80 #RTLD_BINDING_MASK = 0x3 81 #RTLD_NOLOAD = 0x00004 82 RTLD_GLOBAL = 2 83 RTLD_LOCAL = 0 84 #RTLD_NODELETE = 0x01000 85 86 # Also from Android's dlfcn.h 87 RTLD_DEFAULT ((void*) 0xffffffff) 88 RTLD_NEXT ((void*) 0xfffffffe) 89 ---------- components: Build files: patch.diff keywords: patch messages: 236389 nosy: chaselton priority: normal severity: normal status: open title: Steps for Android Native Build of Python 3.4.2 versions: Python 3.4 Added file: http://bugs.python.org/file38201/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 22:38:31 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 21 Feb 2015 21:38:31 +0000 Subject: [issue13637] binascii.a2b_* functions could accept unicode strings In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za> Message-ID: <1424554711.09.0.616136278713.issue13637@psf.upfronthosting.co.za> Martin Panter added the comment: If I understand what you are saying, you don?t mind not mentioning 3.1 behaviour, but want to mention 3.2 behaviour. Perhaps the existing ?Note? box at the top of the page is good enough for you, as pointed out in . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 23:13:21 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Sat, 21 Feb 2015 22:13:21 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424556801.75.0.0481965683237.issue23465@psf.upfronthosting.co.za> Wolfgang Maier added the comment: >> So, with the current patch users could still not use the py launcher from a virtual environment with scripts that are supposed to work under UNIX :( > > Correct. That's not the problem this PEP is intended to solve. Granted :) > Another PEP could be written to look at this, but I suspect it could be quite > hard to balance the various issues involved. Well, changes to the launcher will not typically break any existing code, but constant changes in behaviour may still be a cause of confusion and be hard to explain, ? la: "since Python 3.5 the launcher supports virtual environments, but the details of this support differ between 3.5 and 3.6, e.g. in 3.5, scripts with a python3 shebang line will be executed by the system python3 independent of the virtual environment, but in 3.6 a virtual environment python3 interpreter will be used." IMO it would be preferable to have all virtualenv related changes happening with one release. > As a start, maybe the > Python Windows installer should be writing a "python3.exe" as well as > "python.exe" and venv should put that in the virtualenv. (That's > certainly something that has been suggested in the past). That may be > a simpler solution than adding yet more complexity and special cases > to the launcher. > As an alternative, virtualenv could be changed to create a pyvenv.cfg file with the interpreter version like pyvenv does. Seems pretty simple and unproblematic to me and it might actually be useful to know the interpreter version without running it in other places besides the launcher. What do the pypa devs think about this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 23:19:44 2015 From: report at bugs.python.org (Daniel Franke) Date: Sat, 21 Feb 2015 22:19:44 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1424557184.23.0.296435982646.issue23199@psf.upfronthosting.co.za> Daniel Franke added the comment: I've downloaded and installed python-2.7.9.amd.msi and spent some hours trying to understand the myriad of i386/x86-64 related linker errors I get when attempting to build an extension module. Now that I found this report I can at least stop doubting my sanity. As I take it that there won't be an updated package any time soon, would someone knowledgeable please be so kind and place copy-paste ready step-by-step instructions here on what to do to get a working 64bit .a file for the 2.7.9 amd64 package? This would be much appreciated. Thanks. ---------- nosy: +franke-daniel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 21 23:53:10 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 21 Feb 2015 22:53:10 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424559190.04.0.131004395317.issue23496@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 00:30:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Feb 2015 23:30:40 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <20150221233038.109524.18937@psf.io> Roundup Robot added the comment: New changeset a824c40e8fc0 by Steve Dower in branch 'default': Issue #23152: Renames time_t_to_FILE_TIME to _Py_time_t_to_FILE_TIME, removes unused struct win32_stat and return value https://hg.python.org/cpython/rev/a824c40e8fc0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 00:41:24 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 21 Feb 2015 23:41:24 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1424556801.75.0.0481965683237.issue23465@psf.upfronthosting.co.za> Message-ID: Paul Moore added the comment: > As an alternative, virtualenv could be changed to create a pyvenv.cfg file with the interpreter version like pyvenv does. Seems pretty simple and unproblematic to me and it might actually be useful to know the interpreter version without running it in other places besides the launcher. What do the pypa devs think about this? As one of the pypa devs, I'm in favour of this. I'll probably implement it in due course, time permitting. But of course, a PR from someone else would be a help :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 01:17:47 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 22 Feb 2015 00:17:47 +0000 Subject: [issue13637] binascii.a2b_* functions could accept unicode strings In-Reply-To: <1324312244.97.0.383716057437.issue13637@psf.upfronthosting.co.za> Message-ID: <1424564267.72.0.944210512586.issue13637@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, yes, I see. Sorry for the confusion, I misread that part of the discussion and did not look at that part of the docs. (I find that note confusing...it seems to imply that a2b only accepts ascii. But that's a different issue and I don't feel strongly enough about it to open one :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 01:19:50 2015 From: report at bugs.python.org (Russell Keith-Magee) Date: Sun, 22 Feb 2015 00:19:50 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424564390.23.0.588289075785.issue23496@psf.upfronthosting.co.za> Changes by Russell Keith-Magee : ---------- nosy: +freakboy3742 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 01:57:55 2015 From: report at bugs.python.org (Myles Dear) Date: Sun, 22 Feb 2015 00:57:55 +0000 Subject: [issue23497] textwrap.dedent doesn't work properly with embedded strings containing linefeeds Message-ID: <1424566675.14.0.0615952821634.issue23497@psf.upfronthosting.co.za> New submission from Myles Dear: The textwrap.dedent function does not work when the string to dedent itself contains embedded strings that contain newline characters. https://docs.python.org/3.4/library/textwrap.html?highlight=dedent#textwrap.dedent states that this function "can be used to make triple-quoted strings line up with the left edge of the display". It just so happens that my triple-quoted string itself contains a single-quoted string with newline characters. I would have expected textwrap.dedent to ignore these newline characters inside single or double quoted strings contained in the larger triple-quoted string. The semantics of this bug may be slightly different than https://bugs.python.org/issue19479 "textwrap.dedent doesn't work properly with strings containing CRLF", so I'm raising a new issue. I am seeing this in a module I'm writing that emits synthetic python code that is subsequently passed back into the interpreter via "exec". Python 3.4.1 (default, Nov 12 2014, 13:34:29) [GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from textwrap import dedent >>> s = ''' ... 'my_key' : r'my value which contains \n character' ... ''' >>> s "\n 'my_key' : r'my value which contains \n character'\n" >>> dedent(s) "\n 'my_key' : r'my value which contains \ncharacter'\n" >>> ---------- messages: 236396 nosy: mdear priority: normal severity: normal status: open title: textwrap.dedent doesn't work properly with embedded strings containing linefeeds _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 01:58:12 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Feb 2015 00:58:12 +0000 Subject: [issue23498] Expose http.cookiejar.split_header_words() Message-ID: <1424566690.92.0.444204836552.issue23498@psf.upfronthosting.co.za> New submission from Martin Panter: I propose to document the split_header_words() so that it can be used to parse various kinds of HTTP-based header fields. Perhaps it should live in a more general module like ?http?, or ?email.policy.HTTP? (hinted in Issue 3609). Perhaps there is also room for finding a better name, such as parse_header_attributes() or something, since splitting space-separated words is not its most important property. The function takes a series of header field values, as returned from Message.get_all(failobj=()). The field values may be separate strings and may also be comma-separated. It parses space- or semicolon-separated name=value attributes from each field value. Examples: RFC 2965 Set-Cookie2 fields: >>> cookies = ( ... 'Cookie1="VALUE";Version=1;Discard, Cookie2="Same field";Version=1', ... 'Cookie3="Separate header field";Version=1', ... ) >>> pprint(http.cookiejar.split_header_words(cookies)) [[('Cookie1', 'VALUE'), ('Version', '1'), ('Discard', None)], [('Cookie2', 'Same field'), ('Version', '1')], [('Cookie3', 'Separate header field'), ('Version', '1')]] RTSP 1.0 (RFC 2326) Transport header field: >>> transport = 'RTP/AVP;unicast;mode="PLAY, RECORD", RTP/AVP/TCP;interleaved=0-1' >>> pprint(http.cookiejar.split_header_words((transport,))) [[('RTP/AVP', None), ('unicast', None), ('mode', 'PLAY, RECORD')], [('RTP/AVP/TCP', None), ('interleaved', '0-1')]] The parsing of spaces seems to be an attempt to parse headers like WWW-Authenticate, although it mixes up the parameters when given this example from RFC 7235: >>> auth = 'Newauth realm="apps", type=1, title="Login to \\"apps\\"", Basic realm="simple"' >>> pprint(http.cookiejar.split_header_words((auth,))) [[('Newauth', None), ('realm', 'apps')], [('type', '1')], [('title', 'Login to "apps"')], [('Basic', None), ('realm', 'simple')]] Despite that, the function is still very useful for parsing many kinds of header fields that use semicolons. All the alternatives in the standard library that I know of have disadvantages: * cgi.parse_header() does not split comma-separated values apart, and ignores any attribute without an equals sign, such as ?Discard? and ?unicast? above * email.message.Message.get_params() and get_param() do not split comma-separated values either, and parsing header values other than the first one in a Message object is awkward * email.headerregistry.ParameterizedMIMEHeader looks relevant, but I couldn?t figure out how to use it ---------- components: Library (Lib) messages: 236397 nosy: vadmium priority: normal severity: normal status: open title: Expose http.cookiejar.split_header_words() type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 02:19:26 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 22 Feb 2015 01:19:26 +0000 Subject: [issue23497] textwrap.dedent doesn't work properly with embedded strings containing linefeeds In-Reply-To: <1424566675.14.0.0615952821634.issue23497@psf.upfronthosting.co.za> Message-ID: <1424567966.65.0.441284793318.issue23497@psf.upfronthosting.co.za> Ned Deily added the comment: If you do not want the `\n` to be interpreted as a linefeed, you need to use a raw string literal, like: a = r''' ... 'my_key' : r'my value which contains \n character' ... ''' >>> print(dedent(a)) 'my_key' : r'my value which contains \n character' ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 02:25:44 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Feb 2015 01:25:44 +0000 Subject: [issue3609] does parse_header really belong in CGI module? In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za> Message-ID: <1424568344.23.0.238997830048.issue3609@psf.upfronthosting.co.za> Martin Panter added the comment: I opened Issue 23498 about exposing split_header_words() or similar. So this issue can focus on moving parse_header() to an email.policy.HTTP method or whatever. RTSP 1.0 and its Transport header is defined in RFC 2326: . However it makes more sense to me to provide the generic header value parsing routines where possible, like parse_header() and Message.get_param/s(), rather than hard-coding them for specific header names (my vague understanding of what the header registry module does). The python-dev post mentioned above seems to be at , with one response. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 07:56:51 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 22 Feb 2015 06:56:51 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1424588211.28.0.638353100058.issue23152@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 07:58:57 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 22 Feb 2015 06:58:57 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1424588337.1.0.755102217426.issue23199@psf.upfronthosting.co.za> Steve Dower added the comment: I posted these commands above (modulo version number). If you have MinGW and binutils then it should Just Work, but I'm not very experienced with the range of installations you could have, so you may need to track down the gendef and dlltool tools: gendef - python27.dll > mingwlib.def dlltool --dllname python27.dll --def mingwlib.def --output-lib amd64\libpython27.a -m i386:x86-64 dlltool --dllname python27.dll --def mingwlib.def --output-lib win32\libpython27.a -m i386 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 08:37:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 22 Feb 2015 07:37:14 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1424588211.38.0.532974210287.issue23152@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: You didn't reply to my question on getfilesize(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 11:03:27 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 22 Feb 2015 10:03:27 +0000 Subject: [issue23499] Minor grammar issue in mimetypes.rst Message-ID: <1424599407.74.0.534363562696.issue23499@psf.upfronthosting.co.za> New submission from SilentGhost: Just a minor grammar issue: missing "be" in mimetypes.rst ---------- assignee: docs at python components: Documentation files: mimetypes.diff keywords: patch messages: 236402 nosy: SilentGhost, docs at python, eric.araujo, ezio.melotti, georg.brandl priority: normal severity: normal stage: patch review status: open title: Minor grammar issue in mimetypes.rst versions: Python 3.5 Added file: http://bugs.python.org/file38202/mimetypes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 11:37:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Feb 2015 10:37:42 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition Message-ID: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Argument Clinic generates multiple definitions in non-block mode for functions with alternating signature. See example file. If FOO is not defines, SPAM_METHODDEF is defined twice. First time in: #ifndef SPAM_METHODDEF #define SPAM_METHODDEF #endif /* !defined(SPAM_METHODDEF) */ Second time in: #if !defined(FOO) ... #define SPAM_METHODDEF \ ---------- components: Build, Demos and Tools messages: 236403 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: multiple macro definition type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 11:38:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Feb 2015 10:38:05 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1424601485.95.0.30423029393.issue23500@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 11:56:31 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 22 Feb 2015 10:56:31 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1424602591.68.0.0185997902504.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Posting RemoteDisconnected.v5.patch: * Rebased and fixed minor merge conflict * Change RemoteDisconnected base class from ConnectionError to ConnectionResetError * Minor tweaks to tests It seems that having a separate RemoteDisconnected exception (as in this patch) has at least two benefits: 1. It would allow the user to distinguish between a true ConnectionResetError (due to TCP reset or whatever) from a clean TCP shutdown 2. Backwards compatibility with user code that only handles BadStatusLine The only disadvantage seems to be the bloat of adding a new exception type. But if some other comitter agrees that merging them is better and dropping backwards compatibility is okay I am happy to adjust the patch to go along with that. ---------- Added file: http://bugs.python.org/file38203/RemoteDisconnected.v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 11:56:53 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 22 Feb 2015 10:56:53 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1424602613.19.0.857822334233.issue23500@psf.upfronthosting.co.za> Larry Hastings added the comment: Can you give me a test case? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 12:04:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Feb 2015 11:04:59 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default Message-ID: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes Argument Clinic to generate code into separate files by default. This will help maintaining in the case of enhancements of Argument Clinic generation (such as issue23492). See thread on http://comments.gmane.org/gmane.comp.python.devel/151585 . There is an issue with multiple macro definition in the posix module (see issue23500). ---------- components: Build, Demos and Tools files: clinic_file.patch keywords: patch messages: 236406 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Argument Clinic: generate code into separate files by default type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38204/clinic_file.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 12:05:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Feb 2015 11:05:50 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default In-Reply-To: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> Message-ID: <1424603150.95.0.650722386496.issue23501@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic: multiple macro definition _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 12:06:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Feb 2015 11:06:40 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424603200.43.0.376003240817.issue23492@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka dependencies: +Argument Clinic: generate code into separate files by default _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 12:08:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Feb 2015 11:08:43 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1424603323.38.0.0658145756175.issue23500@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry. Here is a sample. Other sample see in issue23501. ---------- Added file: http://bugs.python.org/file38205/sample.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 12:21:40 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 22 Feb 2015 11:21:40 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424604100.76.0.976016171124.issue23492@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Let's make Argument Clinic a fierce optimizer! (+1 on this) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 15:11:30 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 22 Feb 2015 14:11:30 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1424614290.87.0.188868706947.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: Two posts ago: "The caller to getfilesize is only using it to check whether it's small enough to load the file into memory all at once, so "too big" is an okay response (that function is in marshal.c and not used anywhere else)." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 16:28:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Feb 2015 15:28:07 +0000 Subject: [issue6639] turtle: _tkinter.TclError: invalid command name ".10170160" In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za> Message-ID: <20150222152804.6716.23575@psf.io> Roundup Robot added the comment: New changeset 15dd9d6cc632 by Serhiy Storchaka in branch '2.7': Issue #6639: Module-level turtle functions no longer raise TclError after https://hg.python.org/cpython/rev/15dd9d6cc632 New changeset 1628484c9408 by Serhiy Storchaka in branch '3.4': Issue #6639: Module-level turtle functions no longer raise TclError after https://hg.python.org/cpython/rev/1628484c9408 New changeset d8e494986caf by Serhiy Storchaka in branch 'default': Issue #6639: Module-level turtle functions no longer raise TclError after https://hg.python.org/cpython/rev/d8e494986caf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 16:30:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Feb 2015 15:30:30 +0000 Subject: [issue6639] turtle: _tkinter.TclError: invalid command name ".10170160" In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za> Message-ID: <1424619030.21.0.0156244045212.issue6639@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 17:12:27 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 22 Feb 2015 16:12:27 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1424621547.97.0.254317235597.issue22885@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 18:28:51 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 22 Feb 2015 17:28:51 +0000 Subject: [issue20482] smtplib.SMTP.sendmail: improve exception message In-Reply-To: <1391308888.03.0.522502415802.issue20482@psf.upfronthosting.co.za> Message-ID: <1424626131.13.0.20009970228.issue20482@psf.upfronthosting.co.za> Mark Lawrence added the comment: Assuming that the inline patch in msg209943 is acceptable I'll volunteer to change the test code unless the originator wants the job. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 18:40:02 2015 From: report at bugs.python.org (yegle) Date: Sun, 22 Feb 2015 17:40:02 +0000 Subject: [issue20482] smtplib.SMTP.sendmail: improve exception message In-Reply-To: <1391308888.03.0.522502415802.issue20482@psf.upfronthosting.co.za> Message-ID: <1424626802.04.0.141377372796.issue20482@psf.upfronthosting.co.za> yegle added the comment: I have no plan to work further, Mark can take the code and improve anyway you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 18:40:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Feb 2015 17:40:23 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <20150222174021.4012.14611@psf.io> Roundup Robot added the comment: New changeset b4f9e787b857 by Serhiy Storchaka in branch 'default': Issue #23152: Move declaration into a header and exclude from stable API. https://hg.python.org/cpython/rev/b4f9e787b857 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 19:49:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Feb 2015 18:49:39 +0000 Subject: [issue22623] Missing guards for some POSIX functions In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za> Message-ID: <1424630979.93.0.154659946326.issue22623@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: HAVE_SYS_RESOURCE_H still is used for #include in several files. If guards are added to pwd functions, shouldn't it be added to grp and spwd functions? Is there a platform that have pwd.h, but not getpwuid, getpwnam or getpwent. May be instead testing the existence of separate functions adds the test about the existence of pwd.h in configure? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 19:55:44 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 22 Feb 2015 18:55:44 +0000 Subject: [issue23498] Expose http.cookiejar.split_header_words() In-Reply-To: <1424566690.92.0.444204836552.issue23498@psf.upfronthosting.co.za> Message-ID: <1424631344.51.0.226045103077.issue23498@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag, orsenthil, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 20:21:59 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 22 Feb 2015 19:21:59 +0000 Subject: [issue20482] smtplib.SMTP.sendmail: improve exception message In-Reply-To: <1391308888.03.0.522502415802.issue20482@psf.upfronthosting.co.za> Message-ID: <1424632919.75.0.251836116232.issue20482@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 20:35:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Feb 2015 19:35:42 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <20150222193538.4036.16083@psf.io> Roundup Robot added the comment: New changeset 72cf174cc0eb by Serhiy Storchaka in branch 'default': Issue #23152: Move declarations back to posixmodule.c. https://hg.python.org/cpython/rev/72cf174cc0eb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 20:45:59 2015 From: report at bugs.python.org (Davin Potts) Date: Sun, 22 Feb 2015 19:45:59 +0000 Subject: [issue18382] multiprocessing's overlapped PipeConnection issues on Windows 8 In-Reply-To: <1373114737.55.0.0779572840335.issue18382@psf.upfronthosting.co.za> Message-ID: <1424634359.46.0.856252855202.issue18382@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 20:51:31 2015 From: report at bugs.python.org (Davin Potts) Date: Sun, 22 Feb 2015 19:51:31 +0000 Subject: [issue22872] multiprocessing.Queue raises AssertionError In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za> Message-ID: <1424634691.46.0.0371185889653.issue22872@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 21:11:56 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 22 Feb 2015 20:11:56 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424635916.76.0.683808088337.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Updated patch attached. ---------- Added file: http://bugs.python.org/file38206/issue15955_bz2_rev2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 23:34:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Feb 2015 22:34:00 +0000 Subject: [issue5700] io.FileIO calls flush() after file closed In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za> Message-ID: <20150222223357.4022.15667@psf.io> Roundup Robot added the comment: New changeset bf52f69d6948 by Serhiy Storchaka in branch '2.7': Broke reference loops in tests added in issue #5700. https://hg.python.org/cpython/rev/bf52f69d6948 New changeset 00bde0743690 by Serhiy Storchaka in branch '3.4': Broke reference loops in tests added in issue #5700. https://hg.python.org/cpython/rev/00bde0743690 New changeset a8df1ca60452 by Serhiy Storchaka in branch 'default': Broke reference loops in tests added in issue #5700. https://hg.python.org/cpython/rev/a8df1ca60452 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 23:49:26 2015 From: report at bugs.python.org (Lorenz Quack) Date: Sun, 22 Feb 2015 22:49:26 +0000 Subject: [issue22141] rlcompleter.Completer matches too much In-Reply-To: <1407254399.39.0.799670201718.issue22141@psf.upfronthosting.co.za> Message-ID: <1424645366.43.0.724481754596.issue22141@psf.upfronthosting.co.za> Lorenz Quack added the comment: sorry it took so long but the contributor agreement is now signed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 22 23:52:24 2015 From: report at bugs.python.org (Lorenz Quack) Date: Sun, 22 Feb 2015 22:52:24 +0000 Subject: [issue22143] rlcompleter.Completer has duplicate matches In-Reply-To: <1407255195.5.0.870338576239.issue22143@psf.upfronthosting.co.za> Message-ID: <1424645544.61.0.395692809861.issue22143@psf.upfronthosting.co.za> Lorenz Quack added the comment: sorry it took so long but my contributor agreement is now signed. Do you want me to write a patch with the results sorted? If so, should I also change the docs to reflect that the results are sorted? This would then also affect other implementations because they would be required to also return sorted results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 01:16:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Feb 2015 00:16:07 +0000 Subject: [issue23499] Minor grammar issue in mimetypes.rst In-Reply-To: <1424599407.74.0.534363562696.issue23499@psf.upfronthosting.co.za> Message-ID: <20150223001541.3871.83360@psf.io> Roundup Robot added the comment: New changeset 2b8c5ed7b38b by Ned Deily in branch '2.7': Issue #23499: Fix grammar error noticed by SilentGhost https://hg.python.org/cpython/rev/2b8c5ed7b38b New changeset 5dfdaec85345 by Ned Deily in branch '3.4': Issue #23499: Fix grammar error noticed by SilentGhost https://hg.python.org/cpython/rev/5dfdaec85345 New changeset 49130b06e3ac by Ned Deily in branch 'default': Issue #23499: Fix grammar error noticed by SilentGhost https://hg.python.org/cpython/rev/49130b06e3ac ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 01:16:58 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 23 Feb 2015 00:16:58 +0000 Subject: [issue23499] Minor grammar issue in mimetypes.rst In-Reply-To: <1424599407.74.0.534363562696.issue23499@psf.upfronthosting.co.za> Message-ID: <1424650618.67.0.548734261767.issue23499@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks! ---------- nosy: +ned.deily resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 02:13:16 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 23 Feb 2015 01:13:16 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424653996.94.0.22277308669.issue23493@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm -0 on this proposal. There is a small speed-up to be had here: $ python3.4 -m timeit -s 'f=lambda kv: kv[0]' -s 's=[10, 20]' 'f(s)' 10000000 loops, best of 3: 0.105 usec per loop $ python3.4 -m timeit -s 'import operator' -s 'f=operator.itemgetter(0)' -s 's=[10, 20]' 'f(s)' 10000000 loops, best of 3: 0.0717 usec per loop That said, it is applied only n-times and is likely insignificant when compared to the O(n log n) sort. I think it is better to not add an intermodule dependency when we don't have to. Also if you're using CPython, then the C version of JSON is used instead of this code. So, any timings or optimizations should be tested against the other implementations (Jython or PyPy) that use them. In those implementations, I don't think itemgetter() has any performance benefit over the lambda. ---------- nosy: +rhettinger type: -> performance versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 03:05:00 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 23 Feb 2015 02:05:00 +0000 Subject: [issue18382] multiprocessing's overlapped PipeConnection issues on Windows 8 In-Reply-To: <1373114737.55.0.0779572840335.issue18382@psf.upfronthosting.co.za> Message-ID: <1424657100.64.0.546468283438.issue18382@psf.upfronthosting.co.za> Davin Potts added the comment: Tested Steve's code snippet on Windows 7 64-bit without the patch on default (3.5) and got result: True Not knowing the full history here, I blindly tried on the same Win7 system with 2.7.8 and got a False. Looks like Richard's patches made in #12328 were only applied to 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 04:57:45 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 23 Feb 2015 03:57:45 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424663865.14.0.127106108624.issue23496@psf.upfronthosting.co.za> Changes by Ryan Gonzalez : ---------- nosy: +Ryan.Gonzalez _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 05:23:27 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Feb 2015 04:23:27 +0000 Subject: [issue17322] urllib.request add_header() currently allows trailing spaces (and other weird stuff) In-Reply-To: <1362086834.26.0.0452612015515.issue17322@psf.upfronthosting.co.za> Message-ID: <1424665407.57.0.763802457335.issue17322@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 22928 for a patch making the ?http.client? module even more stricter with header field names and values. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 05:29:13 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Feb 2015 04:29:13 +0000 Subject: [issue626452] Support RFC 2392 in email package Message-ID: <1424665753.98.0.0722103952296.issue626452@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 05:37:52 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Feb 2015 04:37:52 +0000 Subject: [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1424666272.48.0.480956902229.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: Posting bytes-like-param.v4.patch, with David?s suggested wording ---------- Added file: http://bugs.python.org/file38207/bytes-like-param.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 07:59:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 06:59:26 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1424674766.83.0.420427719711.issue15178@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 08:36:18 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 23 Feb 2015 07:36:18 +0000 Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()] deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1424676978.37.0.166944647979.issue23051@psf.upfronthosting.co.za> Davin Potts added the comment: For my part, I'm now good with all aspects of the patch supplied by Alon. I have a working set of tests that will be attached in the next day or two after seeing them behave on more than one platform. ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 08:51:58 2015 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 23 Feb 2015 07:51:58 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424677918.73.0.691000881744.issue23488@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Here is a patch. Where?! BYW, we might want to use PY_UINT32_T rather than uint32_t directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 09:14:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 08:14:17 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424679257.94.0.385334648224.issue23488@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry, here is it. ---------- keywords: +patch Added file: http://bugs.python.org/file38208/random_uint32.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 09:29:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 08:29:34 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424680174.29.0.00933656207472.issue23488@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Some microbenchmark results on 32-bit Linux: $ ./python -m timeit -s "from random import getrandbits" -- "getrandbits(64)" Before: 1000000 loops, best of 3: 1.41 usec per loop After: 1000000 loops, best of 3: 1.34 usec per loop $ ./python -m timeit -s "from random import getrandbits" -- "getrandbits(2048)" Before: 100000 loops, best of 3: 5.84 usec per loop After: 100000 loops, best of 3: 5.61 usec per loop $ ./python -m timeit -s "from random import getrandbits" -- "getrandbits(65536)" Before: 10000 loops, best of 3: 145 usec per loop After: 10000 loops, best of 3: 137 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 09:47:41 2015 From: report at bugs.python.org (Teodor Dima) Date: Mon, 23 Feb 2015 08:47:41 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1424681261.07.0.724830749635.issue23484@psf.upfronthosting.co.za> Teodor Dima added the comment: >>> Of course, there's code in the wild that expects and uses the parameter named 'block' so simply changing this keyword will result in breaking others' code. That is, indeed, the case with my company's code as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 10:50:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Feb 2015 09:50:48 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1424685048.21.0.165364674395.issue23488@psf.upfronthosting.co.za> STINNER Victor added the comment: The patch looks good to me. For utint32_t, see my old issue #17884: "Try to reuse stdint.h types like int32_t". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 11:26:30 2015 From: report at bugs.python.org (Douman) Date: Mon, 23 Feb 2015 10:26:30 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) In-Reply-To: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> Message-ID: <1424687190.2.0.573796552317.issue23245@psf.upfronthosting.co.za> Douman added the comment: Just to up issue. It seems that there is some changes in 2.7.9 that breaks usage of urllib2.urlopen() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 11:44:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 10:44:11 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424688251.31.0.903385492971.issue23493@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: CPython: $ python3.4 -m timeit -s 'f = lambda kv: kv[0]' -s 's = list(dict.fromkeys(range(1000)).items())' -- 'sorted(s, key=f)' 1000 loops, best of 3: 904 usec per loop $ python3.4 -m timeit -s 'import operator' -s 'f = operator.itemgetter(0)' -s 's = list(dict.fromkeys(range(1000)).items())' -- 'sorted(s, key=f)' 1000 loops, best of 3: 462 usec per loop PyPy: $ pypy -m timeit -s 'f = lambda kv: kv[0]' -s 's = list(dict.fromkeys(range(1000)).items())' -- 'sorted(s, key=f)' 1000 loops, best of 3: 1.23 msec per loop $ pypy -m timeit -s 'import operator' -s 'f = operator.itemgetter(0)' -s 's = list(dict.fromkeys(range(1000)).items())' -- 'sorted(s, key=f)' 1000 loops, best of 3: 1.27 msec per loop ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 11:56:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Feb 2015 10:56:11 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424688971.15.0.492360579953.issue23493@psf.upfronthosting.co.za> STINNER Victor added the comment: If I remember correctly, the complexity and performance of sort/sorted depends if the data set is sorted or not. You may recreated the list/dictionary at each iteration to get performances closer to "items = sorted(dct.items(), key=lambda kv: kv[0])" (dict keys are not sorted by their content, especially with strings). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 12:09:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Feb 2015 11:09:48 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424689788.61.0.505502438001.issue23493@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, forget my comment. sorted() never changes the input list, so the microbenchmark is ok. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 12:10:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 11:10:40 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424689840.09.0.182732673256.issue23493@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unless we use recent PyPy with ordered dicts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 12:15:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Feb 2015 11:15:16 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424690116.66.0.717811591244.issue23493@psf.upfronthosting.co.za> STINNER Victor added the comment: > That said, it is applied only n-times and is likely insignificant when compared to the O(n log n) sort. (...) 904 usec => 462 usec is very significant: it's 49% faster. So I'm ok for the change. Note: PyPy JIT may not be able to optimize operator.itemgetter, whereas it optimizes the simple lambda function. You may report this performance issue to PyPy. PyPy may use different code in json for best performances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 12:26:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 11:26:40 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424690800.7.0.0510580666562.issue23493@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My interpretation of the results. In CPython using operator.itemgetter() makes sorting up to 2 times faster (only 25% faster with string keys), in PyPy it make sorting slightly slower (because operator.itemgetter() is implemented in Python, but the lambda is more specialized and could be better optimized). The lambda looks more clear to me, and I think there is the possibility to optimize CPython to replace the body of such functions with builtins from the operator module. ---------- priority: normal -> low status: open -> languishing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 12:30:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Feb 2015 11:30:10 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424691010.23.0.0950197012527.issue23493@psf.upfronthosting.co.za> STINNER Victor added the comment: "My interpretation of the results. In CPython using operator.itemgetter() makes sorting up to 2 times faster" If I remember correctly, Python functions implemented in C don't create a Python frame. The Python frame is an important cost in term of performances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 13:57:49 2015 From: report at bugs.python.org (Wouter Bolsterlee) Date: Mon, 23 Feb 2015 12:57:49 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424696269.94.0.574238293502.issue23493@psf.upfronthosting.co.za> Wouter Bolsterlee added the comment: Using IPython and CPython 3.4: >>> d = dict.fromkeys(map(str, range(1000))) Current implementation: >>> %timeit sorted(d.items(), key=lambda kv: kv[0]) 1000 loops, best of 3: 605 ?s per loop >>> %timeit sorted(d.items(), key=lambda kv: kv[0]) 1000 loops, best of 3: 614 ?s per loop Proposed change: >>> %timeit sorted(d.items(), key=operator.itemgetter(0)) 1000 loops, best of 3: 527 ?s per loop >>> %timeit sorted(d.items(), key=operator.itemgetter(0)) 1000 loops, best of 3: 523 ?s per loop Alternative without 'key' arg, since all keys in a JSON object must be strings, so the tuples from .items() can be compared directly.: >>> %timeit sorted(d.items()) 1000 loops, best of 3: 755 ?s per loop >>> %timeit sorted(d.items()) 1000 loops, best of 3: 756 ?s per loop As you can see, the operator approach seems the fastest on CPython 3.4, even faster than not having a 'key' arg at all (possibly because it avoids doing a tuple compare, which descends into a string compare for the first item). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 14:09:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 13:09:10 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424696950.49.0.968888656045.issue23493@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: languishing -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 14:13:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 13:13:05 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424697185.47.0.750491536868.issue23493@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you measure the effect on json.encode()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 14:55:54 2015 From: report at bugs.python.org (Marc Schlaich) Date: Mon, 23 Feb 2015 13:55:54 +0000 Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za> Message-ID: <1424699754.48.0.985385256926.issue10128@psf.upfronthosting.co.za> Marc Schlaich added the comment: Please fix this. Scripts with multiprocessing bundled as wheels are broken with Python 2.7 on Windows: https://github.com/pypa/pip/issues/1891 ---------- nosy: +schlamar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 15:13:32 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 23 Feb 2015 14:13:32 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424700812.27.0.942244730403.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: The attached g-zipped file contains the first set of patches required to build Python 3.4.2 from source in the environment specified in the origonal post. Will post the second/final set ASAP ---------- Added file: http://bugs.python.org/file38209/python-3.4.2-androidpatches-1.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 15:38:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Feb 2015 14:38:36 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424702316.84.0.241710370575.issue23496@psf.upfronthosting.co.za> STINNER Victor added the comment: It's not convinient to have patches in a tarball. Please at least open patches one by one, or better: open one issue per patch. You should group similar changes in a single patch: for example all changes related to wcstombs(). You should explain each change. For example, the following change (os.patch) looks like a bug. You cannot simply rename a function. It completly breaks backward compatibility. -.. function :: get_shell() +.. function :: get_shell_executable() selectmodule.patch: - timeout = (int)ceill(dtimeout * 1000.0); + timeout = (int)ceil(dtimeout * 1000.0); I don't understand where ceill() does come from. I cannot find it in the current source code. Maybe the patch was produced in the wrong direction? patch.diff: please generate unified patches. Your format is ugly, I cannot read it. And the bug tracker failed to create a "review" button. It's hard to follow instructions to apply patches. Maybe you should use a Mercurial repository, which include all changes? ---------- dependencies: +Android's incomplete locale.h implementation prevents cross-compilation, The select and time modules uses libm functions without linking against it, add function to os module for getting path to default shell nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 15:41:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Feb 2015 14:41:10 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1424702470.98.0.773860581042.issue23314@psf.upfronthosting.co.za> STINNER Victor added the comment: 23314_tf_inherit_check.diff: I would prefer to see this complex code in a function of the support module. For example, the SuppressCrashReport class is a good candidate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 16:26:16 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 23 Feb 2015 15:26:16 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424705176.98.0.802081666696.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Apologies for the tarball, but all patches within are related to this "issue" Removing tarball and will re-post individual, cleaned-up patches, grouped by issue. Ryan, can you re-do patch for pythonrun.c? If not. I'l. work it in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 16:28:41 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 23 Feb 2015 15:28:41 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424705321.51.0.716633247832.issue23496@psf.upfronthosting.co.za> Changes by Cyd Haselton : Removed file: http://bugs.python.org/file38209/python-3.4.2-androidpatches-1.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 17:24:58 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 23 Feb 2015 16:24:58 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1424708698.01.0.694540281745.issue23314@psf.upfronthosting.co.za> Steve Dower added the comment: You're right, SuppressCrashReport also makes more sense here, though it still needs to be used explicitly in every new process. New patch attached. ---------- Added file: http://bugs.python.org/file38210/23314_tf_inhert_check_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 17:32:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Feb 2015 16:32:15 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1424709135.09.0.454662504749.issue23314@psf.upfronthosting.co.za> STINNER Victor added the comment: I reviewed 23314_tf_inhert_check_2.diff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 17:44:15 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 23 Feb 2015 16:44:15 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424709855.8.0.0224582113371.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Attached rev3 with fixed indentation and explicit cast to avoid compiler warning on 32-bit systems. ---------- Added file: http://bugs.python.org/file38211/issue15955_bz2_rev3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 17:45:20 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 23 Feb 2015 16:45:20 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1424709920.91.0.0133471600487.issue23314@psf.upfronthosting.co.za> Steve Dower added the comment: Updated patch ---------- Added file: http://bugs.python.org/file38212/23314_tf_inhert_check_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 17:53:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Feb 2015 16:53:50 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1424710430.19.0.90869495141.issue23314@psf.upfronthosting.co.za> STINNER Victor added the comment: 23314_tf_inhert_check_3.diff looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 18:59:03 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Mon, 23 Feb 2015 17:59:03 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1424714343.94.0.826804081357.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 19:09:18 2015 From: report at bugs.python.org (Joshua J Cogliati) Date: Mon, 23 Feb 2015 18:09:18 +0000 Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za> Message-ID: <1424714958.85.0.730347499713.issue8027@psf.upfronthosting.co.za> Joshua J Cogliati added the comment: I can confirm this bug on Python 2.7.8 and Python 3.4.1, and given that the code is still in later versions, I expect that it will fail in them as well. >From Python-3.4.2/Lib/distutils/unixcompiler.py, lines 179-189: # skip over environment variable settings if /usr/bin/env # is used to set up the linker's environment. # This is needed on OSX. Note: this assumes that the # normal and C++ compiler have the same environment # settings. i = 0 if os.path.basename(linker[0]) == "env": i = 1 while '=' in linker[i]: i += 1 linker[i] = self.compiler_cxx[i] First of all, as has been noted, this will fail if len(self.compiler_cxx) > 1. Second of all, I do not understand how this code was supposed to work correctly in the first place. If env is in linker[0], then variable i will be greater than 0, so why are we then using self.compiler_cxx[i]? As I understand the code, I should be able to do something like: export CXX="env BAR=FOO g++" and then have env work. However, when I tried this, my python setup.py build failed. However, if I do something like: if target_lang == "c++" and self.compiler_cxx and False: to the line in unixcompiler.py, then I can do: export CXX="env BAR=FOO g++" in the shell and have it compile. I don't know if it would work if I actually needed BAR=FOO, but so far as I can tell this code is broken, and has been for a while, and therefore should be flat out removed. ---------- nosy: +Joshua.J.Cogliati, jrincayc versions: +Python 3.4 Added file: http://bugs.python.org/file38213/fix-distutils-279.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 19:16:07 2015 From: report at bugs.python.org (Daniel Holth) Date: Mon, 23 Feb 2015 18:16:07 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424715367.72.0.904272081184.issue23491@psf.upfronthosting.co.za> Daniel Holth added the comment: It looks like your patch does not register PYZW in Windows ---------- nosy: +dholth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 19:18:03 2015 From: report at bugs.python.org (Joshua J Cogliati) Date: Mon, 23 Feb 2015 18:18:03 +0000 Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za> Message-ID: <1424715483.12.0.178554960079.issue8027@psf.upfronthosting.co.za> Joshua J Cogliati added the comment: Patch for 3.4.2 that removes the code. ---------- Added file: http://bugs.python.org/file38214/fix-distutils-342.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 19:19:32 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 23 Feb 2015 18:19:32 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424715572.56.0.446372767215.issue23491@psf.upfronthosting.co.za> Steve Dower added the comment: It registers the association, but doesn't add it to PATHEXT. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 19:25:52 2015 From: report at bugs.python.org (Daniel Holth) Date: Mon, 23 Feb 2015 18:25:52 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424715572.56.0.446372767215.issue23491@psf.upfronthosting.co.za> Message-ID: <1424715950.2445063.231333685.6C40752A@webmail.messagingengine.com> Daniel Holth added the comment: I don't see the string PYZW anywhere in the patch, I only see PYZ, perhaps I don't know enough about this bug tracker or registering file extensions? On Mon, Feb 23, 2015, at 01:19 PM, Steve Dower wrote: > > Steve Dower added the comment: > > It registers the association, but doesn't add it to PATHEXT. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 19:28:16 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 23 Feb 2015 18:28:16 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424716096.9.0.221879430271.issue23491@psf.upfronthosting.co.za> Steve Dower added the comment: It's this line: $(var.ArchiveFileExtension) expands to "pyz" or "pxz" depending on the build options, and the literal w makes it pyzw or pxzw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 20:21:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 19:21:48 +0000 Subject: [issue23502] pprint: added support for mapping proxy Message-ID: <1424719308.61.0.00451137981633.issue23502@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Mapping proxy is quite often used in building . For example types __dict__ are mapping proxy. >>> bool.__dict__ mappingproxy({'__or__': , '__doc__': 'bool(x) -> bool\n\nReturns True when the argument x is true, False otherwise.\nThe builtins True and False are the only two instances of the class bool.\nThe class bool is a subclass of the class int, and cannot be subclassed.', '__xor__': , '__and__': , '__rxor__': , '__repr__': , '__new__': , '__rand__': , '__str__': , '__ror__': }) Mapping proxy is not a subclass of dict, so pprint doesn't print it pretty. Proposed patch adds support for mapping proxies in pprint. >>> from pprint import pprint as pp >>> pp(bool.__dict__) mappingproxy({'__and__': , '__doc__': 'bool(x) -> bool\n' '\n' 'Returns True when the argument x is true, False ' 'otherwise.\n' 'The builtins True and False are the only two ' 'instances of the class bool.\n' 'The class bool is a subclass of the class int, and ' 'cannot be subclassed.', '__new__': , '__or__': , '__rand__': , '__repr__': , '__ror__': , '__rxor__': , '__str__': , '__xor__': }) ---------- components: Library (Lib) files: pprint_mappingproxy.patch keywords: patch messages: 236460 nosy: fdrake, pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: pprint: added support for mapping proxy type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38215/pprint_mappingproxy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 20:45:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Feb 2015 19:45:30 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <20150223194525.109579.63424@psf.io> Roundup Robot added the comment: New changeset bb67b810aac1 by Steve Dower in branch 'default': Issue 23314: SuppressCrashReports now disables CRT assertions https://hg.python.org/cpython/rev/bb67b810aac1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 20:47:17 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 23 Feb 2015 19:47:17 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424720837.26.0.153382783044.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Cyd, What revision of the Python 3.4 source is this against? The tarball? I'm not quite sure what to redo that patch against. Also, shouldn't the code be selectively enabled with macros/configure.ac edits? Or did I miss where someone said this should be in its own branch (which, in my opinion, isn't very clean)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 21:53:06 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 23 Feb 2015 20:53:06 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424724786.05.0.790446325789.issue15955@psf.upfronthosting.co.za> Martin Panter added the comment: Rev3 still seems to have the same weird indentation as rev2. Are you using some sort of diff --ignore-all-space option by accident? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 21:55:52 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 23 Feb 2015 20:55:52 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) In-Reply-To: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> Message-ID: <1424724952.93.0.158878123671.issue23245@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 22:13:48 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 23 Feb 2015 21:13:48 +0000 Subject: [issue20482] smtplib.SMTP.sendmail: improve exception message In-Reply-To: <1391308888.03.0.522502415802.issue20482@psf.upfronthosting.co.za> Message-ID: <1424726028.67.0.362766852498.issue20482@psf.upfronthosting.co.za> Mark Lawrence added the comment: I don't believe that there is much sense in implementing the proposed change. If the stdlib was changed every time a UnicodeEncodeError was reported just to show a slightly clearer exception message, I dread to think how much extra code would be added in total. Committing a change such as this takes core dev time which IMHO opinion could be put to better use. ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 22:18:56 2015 From: report at bugs.python.org (Dwight Guth) Date: Mon, 23 Feb 2015 21:18:56 +0000 Subject: [issue23503] undefined behavior in Objects/obmalloc.c Message-ID: <1424726336.65.0.769638302679.issue23503@psf.upfronthosting.co.za> New submission from Dwight Guth: According to the ISO C standard (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf) section 6.5.6 paragraph 8, the behavior of the C addition operator is undefined if the result of the operand does not either fall inside the same array object that is being indexed, or one index past the end of the array object. In Objects/obmalloc.c line 841, the macros PT(0) through PT(7) expand to references to array indexes before the beginning of the usedpools array. As a result, this initializer causes this file to be undefined. ---------- components: Interpreter Core messages: 236465 nosy: dwight.guth priority: normal severity: normal status: open title: undefined behavior in Objects/obmalloc.c type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 22:21:14 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 23 Feb 2015 21:21:14 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1424602591.68.0.0185997902504.issue3566@psf.upfronthosting.co.za> Message-ID: <41AF6A10-B8B5-4160-9F4F-E53DC6F807D5@gmail.com> Demian Brecht added the comment: Pending review of the exceptions from another core dev, the patch looks good to me. Thanks for sticking with it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 23:14:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Feb 2015 22:14:05 +0000 Subject: [issue23504] Add __all__ into types Message-ID: <1424729645.56.0.912988413489.issue23504@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently pydoc outputs only two classes and two functions in the types module. Proposed patch add __all__ into the types module, so that pydoc will output builtin class deliberately added into the types module. ---------- components: Library (Lib) files: types___all__.patch keywords: patch messages: 236467 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add __all__ into types type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38216/types___all__.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 23 23:22:45 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 23 Feb 2015 22:22:45 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1424724786.05.0.790446325789.issue15955@psf.upfronthosting.co.za> (Martin Panter's message of "Mon, 23 Feb 2015 20:53:06 +0000") Message-ID: <87d2508dzi.fsf@thinkpad.rath.org> Nikolaus Rath added the comment: On Feb 23 2015, Martin Panter wrote: > Rev3 still seems to have the same weird indentation as rev2. Are you > using some sort of diff --ignore-all-space option by accident? I used "diff -w" for revision 2, but revision 3 should be good. Can you give me a line number where you see problems in rev3? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F ?Time flies like an arrow, fruit flies like a Banana.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 00:07:37 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 23 Feb 2015 23:07:37 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424732857.1.0.450151882023.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Ryan, I manually applied the patch to the Python 3.4.2 source tarball, dowmloaded from the main site to my Android tablet. I'm guessing (re)generating the patch from that source should work. I've no knowledge of configure syntax, but most of the patches apply only if __ANDROID__ is defined. This can be enabled with the -mandroid/-mbionic CFLAGS that work with GCC 4.8.x and later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 01:09:21 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Feb 2015 00:09:21 +0000 Subject: [issue23504] Add __all__ into types In-Reply-To: <1424729645.56.0.912988413489.issue23504@psf.upfronthosting.co.za> Message-ID: <1424736561.88.0.788351688652.issue23504@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 01:11:53 2015 From: report at bugs.python.org (Yassine ABOUKIR) Date: Tue, 24 Feb 2015 00:11:53 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect Message-ID: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za> New submission from Yassine ABOUKIR: The module urlparse lacks proper validation of the input leading to open redirect vulnerability. The issue is that URLs do not survive the round-trip through `urlunparse(urlparse(url))`. Python sees `/////foo.com` as a URL with no hostname or scheme and a path of `//foo.com`, but when it reconstructs the URL after parsing, it becomes `//foo.com`. This can be practically exploited this way : http://example.com/login?next=/////evil.com The for fix this would be for `urlunparse()` to serialize paths with two leading slashes as '/%2F', at least when `scheme` and `netloc` are empty. ---------- components: Library (Lib) messages: 236470 nosy: yaaboukir priority: normal severity: normal status: open title: Urlparse insufficient validation leads to open redirect type: security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 01:13:00 2015 From: report at bugs.python.org (Yassine ABOUKIR) Date: Tue, 24 Feb 2015 00:13:00 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za> Message-ID: <1424736780.02.0.0545382402935.issue23505@psf.upfronthosting.co.za> Changes by Yassine ABOUKIR : ---------- versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 01:35:49 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Feb 2015 00:35:49 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za> Message-ID: <1424738149.68.0.585857476721.issue23505@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps you actually meant four input slashes, producing two output slashes. That seems more of a bug to me: >>> urlparse("////foo.com") ParseResult(scheme='', netloc='', path='//foo.com', params='', query='', fragment='') >>> urlunparse(_) '//foo.com' Solving Issue 22852, which proposes some flags including ?has_netloc? on the ParseResult object, might help with this. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 01:39:15 2015 From: report at bugs.python.org (Yassine ABOUKIR) Date: Tue, 24 Feb 2015 00:39:15 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za> Message-ID: <1424738355.11.0.887772700373.issue23505@psf.upfronthosting.co.za> Yassine ABOUKIR added the comment: Yes! forgive my mistake I meant four slashes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 02:09:43 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 24 Feb 2015 01:09:43 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za> Message-ID: <1424740183.72.0.198106675137.issue23493@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 02:27:57 2015 From: report at bugs.python.org (Yassine ABOUKIR) Date: Tue, 24 Feb 2015 01:27:57 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za> Message-ID: <1424741277.57.0.155317209093.issue23505@psf.upfronthosting.co.za> Changes by Yassine ABOUKIR : ---------- nosy: +orsenthil, soilandreyes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 02:39:55 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 24 Feb 2015 01:39:55 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424741995.17.0.352636577256.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: One more try before I give up. ---------- Added file: http://bugs.python.org/file38217/issue15955_bz2_rev5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 02:58:25 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 24 Feb 2015 01:58:25 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424743105.35.0.359219531034.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: grmblfhargs#@$@# ---------- Added file: http://bugs.python.org/file38218/issue15955_bz2_rev6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 03:11:54 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 24 Feb 2015 02:11:54 +0000 Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za> Message-ID: <1424743914.87.0.118719043886.issue10128@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 05:29:14 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Feb 2015 04:29:14 +0000 Subject: [issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za> Message-ID: <1424752154.2.0.471173353395.issue4806@psf.upfronthosting.co.za> Martin Panter added the comment: I am posting a new version of Daniel?s patch as issue4806-star-TypeError.v2.patch: * Merged with recent ?default? (3.5) branch * Dropped the documentation fix, since revision a8aa918041c2 already fixed that in an identical fashion * Changed to a ?look before you leap? style check before attempting PySequence_Tuple(). This way we get to keep other valid errors such as ?iter() returned non-iterator?. I am comfortable with the code changes previous patch as well as mine. Checking the ?tp_iter? field and PySequence_Check() is basically what happens behind the scenes, via PyObject_GetIter() anyway. So I think either patch is valid and a worthwhile improvement. ---------- Added file: http://bugs.python.org/file38219/issue4806-star-TypeError.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 05:51:45 2015 From: report at bugs.python.org (Stan) Date: Tue, 24 Feb 2015 04:51:45 +0000 Subject: [issue23506] Data Structure of Dict not changing its value as expected Message-ID: <1424753505.27.0.912963667947.issue23506@psf.upfronthosting.co.za> New submission from Stan: Expected the following code to change the value of the variable, it is not, comment are appreciated at this point. GUMMIE_BEARS = '' arr2 = { 'GUMMIE_BEARS' : GUMMIE_BEARS } arr2['GUMMIE_BEARS'] = 'hello world' print arr2['GUMMIE_BEARS'] print 'and this too' + GUMMIE_BEARS + '<---should be' # point #1 Expected output at point #1 should have 'hello world' contained within the string, it does not however. # I note this description: # Mutable variables ? such as dictionaries and lists ? are passed by reference, # and so if your function accepts mutable argument, it may modify the contents of that mutable variable # outside the scope of the function. Thank You. ---------- messages: 236476 nosy: opensource3 priority: normal severity: normal status: open title: Data Structure of Dict not changing its value as expected type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 05:53:59 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 24 Feb 2015 04:53:59 +0000 Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()] deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1424753639.01.0.570969438403.issue23051@psf.upfronthosting.co.za> Davin Potts added the comment: Attaching updated patch files that combine both Alon's fix with unit tests for it. Review of the unit tests especially would be welcomed. My one misgiving about these unit tests is that if at some future date there were a regression, the unhandled issue would potentially cause this unit test to hang -- it would be nicer if that did not have to be so. These two combined patches (one for default/3.5 and 3.4, one for 2.7) have been tested on OS X 10.10, Ubuntu Linux 12.04.5 64-bit, and Windows 7 64-bit (though only for the default/3.5 and 3.4 patch on Win7). ---------- Added file: http://bugs.python.org/file38220/issue_23051_fix_and_tests_v35_and_v34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 05:54:56 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 24 Feb 2015 04:54:56 +0000 Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()] deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1424753696.09.0.255443512682.issue23051@psf.upfronthosting.co.za> Changes by Davin Potts : Added file: http://bugs.python.org/file38221/issue_23051_fix_and_tests_v27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 05:56:51 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 24 Feb 2015 04:56:51 +0000 Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()] deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1424753811.13.0.170756136985.issue23051@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- stage: test needed -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 06:03:46 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 24 Feb 2015 05:03:46 +0000 Subject: [issue23506] Data Structure of Dict not changing its value as expected In-Reply-To: <1424753505.27.0.912963667947.issue23506@psf.upfronthosting.co.za> Message-ID: <1424754226.13.0.219284826612.issue23506@psf.upfronthosting.co.za> Zachary Ware added the comment: Python's "variables" don't work quite the same as you may be used to thinking of them in other languages. See http://nedbatchelder.com/text/names.html for a very good description of how Python's name binding works. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 06:53:55 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Feb 2015 05:53:55 +0000 Subject: [issue22347] mimetypes.guess_type("//example.com") misinterprets host name as file name In-Reply-To: <1409971957.28.0.64915967452.issue22347@psf.upfronthosting.co.za> Message-ID: <1424757235.78.0.61886635276.issue22347@psf.upfronthosting.co.za> Martin Panter added the comment: Posting a patch to fix this. It passes the URL through a urlsplit() ? urlunsplit() stage, while removing the scheme://netloc parts. ---------- keywords: +patch Added file: http://bugs.python.org/file38222/mimetypes-host.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 09:08:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 08:08:32 +0000 Subject: [issue23507] Tuple creation is two slow Message-ID: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently tuples creating uses free lists. But this optimization is not enough. When reuse cached tuple for arguments of repeatedly called functions, the performance of some builtins can be significantly increased. $ ./python -m timeit -s "f = lambda x: x" -s "s = list(range(1000))" -- "list(filter(f, s))" Unpatched: 1000 loops, best of 3: 773 usec per loop Patched: 1000 loops, best of 3: 558 usec per loop $ ./python -m timeit -s "f = lambda x: x" -s "s = list(range(1000))" -- "list(map(f, s))" Unpatched: 1000 loops, best of 3: 689 usec per loop Patched: 1000 loops, best of 3: 556 usec per loop $ ./python -m timeit -s "f = lambda x: x" -s "s = list(range(1000))" -- "sorted(s, key=f)" Unpatched: 1000 loops, best of 3: 758 usec per loop Patched: 1000 loops, best of 3: 550 usec per loop The same effect can be achieved for itertools functions. I don't propose to commit this complicated patch, but these results can be used as a guide to the optimization of tuple creating. It is surprising to me that this patch has any effect at all. ---------- components: Interpreter Core files: reuse_argtuples.patch keywords: patch messages: 236480 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Tuple creation is two slow type: performance versions: Python 3.5 Added file: http://bugs.python.org/file38223/reuse_argtuples.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 09:09:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 08:09:04 +0000 Subject: [issue23507] Tuple creation is too slow In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> Message-ID: <1424765344.88.0.845900906815.issue23507@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: Tuple creation is two slow -> Tuple creation is too slow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 09:34:06 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 24 Feb 2015 08:34:06 +0000 Subject: [issue23507] Tuple creation is too slow In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> Message-ID: <1424766846.9.0.548123116418.issue23507@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 09:49:25 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 24 Feb 2015 08:49:25 +0000 Subject: [issue10197] subprocess.getoutput fails on win32 In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za> Message-ID: <1424767765.3.0.499752786027.issue10197@psf.upfronthosting.co.za> Gregory P. Smith added the comment: A side effect of the changes made within are that getstatusoutput() on POSIX systems now returns a different value for status. The old implementation present in Python 2 and Python 3.3 before this patch returned the raw waitpid() status result as the status value. ie: getstatusoutput("exit 1")[0] == 256. the lower 8 bits were reserved for the signal number the process died with, if any. Now it returns the sanitized subprocess style returncode: positive numbers are the process exit code (so the above example returns 1) and negative numbers are the negative signal number the process died with. I prefer the new behavior, but this API change is not documented anywhere that I can find. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 09:56:18 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 24 Feb 2015 08:56:18 +0000 Subject: [issue23508] Document & unittest the subprocess.getstatusoutput() status value Message-ID: <1424768178.86.0.938424229154.issue23508@psf.upfronthosting.co.za> New submission from Gregory P. Smith: The changes from http://bugs.python.org/issue10197 caused subprocess.getstatusoutput() to start returning a subprocess returncode style status for the child process instead of a POSIX style status. before that bug's changes: >>> getstatusoutput("exit 1")[0] 256 >>> getstatusoutput("kill -TERM $$")[0] 15 after that bug's changes: >>> getstatusoutput("exit 1")[0] 1 >>> getstatusoutput("kill -TERM $$")[0] -15 This behavior was entirely untested so it was missed when fixing issue10197. Given the new behavior has shipped in a stable Python release starting with (I believe) 3.3.4 and all 3.4 releases I do not think it should be changed. But we should document it with proper versionchanged notices. ---------- messages: 236482 nosy: gregory.p.smith priority: normal severity: normal status: open title: Document & unittest the subprocess.getstatusoutput() status value _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 09:56:36 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 24 Feb 2015 08:56:36 +0000 Subject: [issue10197] subprocess.getoutput fails on win32 In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za> Message-ID: <1424768196.55.0.280148241317.issue10197@psf.upfronthosting.co.za> Gregory P. Smith added the comment: http://bugs.python.org/issue23508 to track the fall out of that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 10:43:42 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Hees?=) Date: Tue, 24 Feb 2015 09:43:42 +0000 Subject: [issue23509] Counter.__iadd__ falls back to __add__ with bad performance impact Message-ID: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> New submission from J?rn Hees: This caught me when i worked on a stats script and updated c = Counter() in a loop with c += Counter(temp_dict). After profiling, i found out that my script spent 2 minutes in Counter.__add__ which seemed terribly slow (each invocation was in the ms not ?s range). Looking into this i found out that there is no implementation for Counter.__iadd__ (or __isub__) which i just assumed to be based on Counter.update (Counter.subtract). Here's some timing output: In [1]: from collections import Counter In [2]: a = range(1000) In [3]: b = range(1000) In [4]: ab = a+b In [5]: len(ab) Out[5]: 2000 In [6]: %timeit c=Counter(a) 1000 loops, best of 3: 361 ?s per loop In [7]: %timeit c=Counter(ab) 1000 loops, best of 3: 734 ?s per loop In [8]: %timeit c=Counter(a) ; c += Counter(b) 1000 loops, best of 3: 1.51 ms per loop In [9]: %timeit c=Counter(a) ; c.update(b) 1000 loops, best of 3: 741 ?s per loop Counter.update is way faster than +=, even if you re-add the overhead to create a new Counter: In [10]: %timeit c=Counter(a) ; c.update(Counter(b)) 1000 loops, best of 3: 1.16 ms per loop In [11]: %timeit c=Counter(a) ; c.update({x:1 for x in b}) 1000 loops, best of 3: 844 ?s per loop Would it be welcome if i add __iadd__ and __isub__ which just invoke update and subtract? One reason not to have this is the current __add__ and __sub__ behavior of min values > 0, which from a set-theoretic standpoint makes sense, but has a certain potential of confusing developers who just use it as a simplistic Stats module. ---------- messages: 236484 nosy: joern priority: normal severity: normal status: open title: Counter.__iadd__ falls back to __add__ with bad performance impact type: performance versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 10:59:58 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 24 Feb 2015 09:59:58 +0000 Subject: [issue19946] Handle a non-importable __main__ in multiprocessing In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za> Message-ID: <1424771998.5.0.0964970378596.issue19946@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 11:06:23 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 24 Feb 2015 10:06:23 +0000 Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za> Message-ID: <1424772383.1.0.203792283095.issue10128@psf.upfronthosting.co.za> Nick Coghlan added the comment: Marc's reference to pip meant I noticed something that I had missed previously - that this issue is referring specifically to the use of setuptools/pip entry points, not to the -m switch. Entry points shouldn't be hitting this if they're importing the module containing the entry point normally - #10845 specifically related to invoking multiprocessing from a module run directly with the -m switch, which was worked around in 3.2 and 3.3, and then finally fixed properly in 3.4 by the implementation of #19946 So if there's an incompatibility between multiprocessing and entry points, it would be preferable to fix it in pip/setuptools, as that will reach many more installations than just fixing multiprocessing to better tolerate that situation. ---------- nosy: +bkabrda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 11:09:32 2015 From: report at bugs.python.org (Pavel Labath) Date: Tue, 24 Feb 2015 10:09:32 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1424772572.0.0.260171160093.issue23458@psf.upfronthosting.co.za> Changes by Pavel Labath : ---------- nosy: +Pavel.Labath _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 11:32:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 10:32:30 +0000 Subject: [issue23509] Counter.__iadd__ falls back to __add__ with bad performance impact In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1424773950.44.0.499063636708.issue23509@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Support of in-place math operators is already added in issue13121. ---------- nosy: +rhettinger, serhiy.storchaka resolution: -> out of date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 12:49:28 2015 From: report at bugs.python.org (Stan) Date: Tue, 24 Feb 2015 11:49:28 +0000 Subject: [issue23506] Data Structure of Dict not changing its value as expected In-Reply-To: <1424754226.13.0.219284826612.issue23506@psf.upfronthosting.co.za> Message-ID: <1424778566.89726.YahooMailBasic@web121105.mail.ne1.yahoo.com> Stan added the comment: Thank You. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 13:32:50 2015 From: report at bugs.python.org (Cyd Haselton) Date: Tue, 24 Feb 2015 12:32:50 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424781169.98.0.127163936711.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Additionally, for the Lib/plat- specific changes, I can create Lib/plat-android and move the modified DLFCN.py and others there, provided someone could help with the appropriate configure.ac syntax. I can/could do it myself, but it would take a *while* as I'd need to learn a fair amount of configure scripting first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 13:44:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 12:44:22 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1424781862.43.0.674356598113.issue23509@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: However it is possible to speed up the implementation. Proposed patch increases performance of Counter operators from 20% to 1200%. Unpatched Patched 422 (-3%) 411 c = Counter(a) 260 (-4%) 251 c = Counter(b) 15568 (-118%) 7155 c = Counter(a); c + b 11536 (-56%) 7377 c = Counter(a); c - b 15354 (-190%) 5291 c = Counter(a); c | b 11291 (-60%) 7043 c = Counter(a); c & b 8176 (-22%) 6712 c = Counter(a); c += b 21976 (-162%) 8379 c = Counter(a); c -= b 6090 (-24%) 4895 c = Counter(a); c |= b 16346 (-34%) 12226 c = Counter(a); c &= b 17125 (-1160%) 1359 +a 10484 (-289%) 2693 +c # c = Counter(); c.subtract(a) 3325 (-234%) 997 -a 10094 (-56%) 6480 -c # c = Counter(); c.subtract(a) ---------- components: +Library (Lib) keywords: +patch resolution: out of date -> stage: -> patch review title: Counter.__iadd__ falls back to __add__ with bad performance impact -> Speed up Counter operators versions: +Python 3.5 -Python 2.7, Python 3.4 Added file: http://bugs.python.org/file38224/counter_faster.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 13:45:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 12:45:08 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1424781908.8.0.448813689472.issue23509@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file38225/counter_bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 14:08:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 24 Feb 2015 13:08:04 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1424783284.94.0.076070311729.issue3566@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 14:27:54 2015 From: report at bugs.python.org (Cezary Wagner) Date: Tue, 24 Feb 2015 13:27:54 +0000 Subject: [issue23510] multiprocessing bug Message-ID: <1424784474.12.0.228863603483.issue23510@psf.upfronthosting.co.za> New submission from Cezary Wagner: 'with' code with manager will not work: AttributeError: 'SyncManager' object has no attribute 'shutdown' Test code: # coding=utf-8 import multiprocessing import multiprocessing.managers import logging def callback(result): print multiprocessing.current_process().name, 'callback', result def worker(io_lock, value): # error raise RuntimeError() result = value + 1 with io_lock: print multiprocessing.current_process().name, value, result return result def main(): manager = multiprocessing.managers.SyncManager() with manager: io_lock = manager.Lock() pool = multiprocessing.Pool(multiprocessing.cpu_count()) for i in range(10): print pool.apply_async(worker, args=(io_lock, i), callback = callback) pool.close() pool.join() if __name__ == '__main__': logging.basicConfig(level = logging.DEBUG) main() See this code from multiprocessing.managers.SyncManager: class SyncManager(BaseManager): pass And now see 'with' methods in Basemanager: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): self.shutdown() ---------- components: Library (Lib) messages: 236490 nosy: Cezary.Wagner priority: normal severity: normal status: open title: multiprocessing bug type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 14:28:23 2015 From: report at bugs.python.org (Cezary Wagner) Date: Tue, 24 Feb 2015 13:28:23 +0000 Subject: [issue23510] multiprocessing bug SyncManager and 'with' In-Reply-To: <1424784474.12.0.228863603483.issue23510@psf.upfronthosting.co.za> Message-ID: <1424784503.08.0.35451383595.issue23510@psf.upfronthosting.co.za> Changes by Cezary Wagner : ---------- title: multiprocessing bug -> multiprocessing bug SyncManager and 'with' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 14:31:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Feb 2015 13:31:02 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <20150224133058.29670.10767@psf.io> Roundup Robot added the comment: New changeset 88a99ea8a4cf by Victor Stinner in branch '2.7': Issue #23458: On POSIX, the file descriptor kept open by os.urandom() is now https://hg.python.org/cpython/rev/88a99ea8a4cf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 14:32:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Feb 2015 13:32:10 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1424784730.08.0.0584420719251.issue23458@psf.upfronthosting.co.za> STINNER Victor added the comment: I simplified the patch on random.c to avoid O_CLOEXEC, there is no need to have an atomic operation. I also fixed the test: it now uses two subprocesses, to avoid inheritable file descriptors created by the Python test suite. Thanks for the report. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 14:38:34 2015 From: report at bugs.python.org (Manuel Jacob) Date: Tue, 24 Feb 2015 13:38:34 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1424785113.99.0.976503966177.issue17576@psf.upfronthosting.co.za> Manuel Jacob added the comment: Maybe I'm missing something, but it seems to me that test_int_subclass_with_index() is testing for the exactly wrong behaviour. Isn't the point of this issue that operator.index(a) should be equal to a.__index__()? Why are the tests checking that they are different? ---------- nosy: +mjacob _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 14:43:43 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 13:43:43 +0000 Subject: [issue14367] try/except block in ismethoddescriptor() in inspect.py, so that pydoc works with pygame in Python 3.2 In-Reply-To: <1332132143.66.0.7093323157.issue14367@psf.upfronthosting.co.za> Message-ID: <1424785423.76.0.482669097087.issue14367@psf.upfronthosting.co.za> Mark Lawrence added the comment: The code in ismethoddescriptor was completely rewritten as a result of #1785 rendering the attached patch obsolete. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 14:48:16 2015 From: report at bugs.python.org (Pavel Labath) Date: Tue, 24 Feb 2015 13:48:16 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1424785696.56.0.593889340085.issue23458@psf.upfronthosting.co.za> Pavel Labath added the comment: Thanks for fixing this. Still, I would like to argue that an atomic operation is important. Python interpreter can run embedded in an multi-threaded application (as we do in the case of LLDB). If this is the case, then file descriptors opened by python in one thread are visible to other application threads even though they may have nothing to do with python -- they may not even know that python exists. Now if these other threads do a fork between the time you do open() and fcntl(), you've got yourself a race condition. Granted, this is not very likely, but this is precisely the reason why O_CLOEXEC was created, and I think we should take advantage of that. And it is not even linux specific, the flag is now recent versions of mac and freebsd too. Therefore I think the original patch is better, even though it may be more complex. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 14:54:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Feb 2015 13:54:23 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1424786063.14.0.120907865709.issue23458@psf.upfronthosting.co.za> STINNER Victor added the comment: > Still, I would like to argue that an atomic operation is important. Yes, and that's why I wrote the whole PEP 446 :-) But we are *not* going to backport the PEP. New features and bug fixes requiring large code change are only done in the development branch, not on stable branches. Fixing os.urandom() to have atomic operation creating the file descriptor non-inheritable is useless, because they are a *lot* of other functions which create inheritable file descriptors, and a few others which create non-inheritable file descriptor but are not atomic. You don't have to search too far: Popen.pipe_cloexec() is not atomic... Reminder: subprocess is not thread-safe => issue #19809 (doc issue). See my "Bugs already fixed in Python 3" and "Bugs that won?t be fixed in Python 2 anymore" lists: http://haypo-notes.readthedocs.org/python.html#python-3-is-better-than-python-2 -- I reopen the issue because the test is failing on Windows and OpenIndiana buildbots. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 15:11:50 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 14:11:50 +0000 Subject: [issue23138] cookiejar parses cookie value as int with empty name-value pair and Expires In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za> Message-ID: <1424787110.37.0.766325846645.issue23138@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Demian I believe this may be of interest to you. ---------- nosy: +BreamoreBoy, demian.brecht versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 15:13:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Feb 2015 14:13:25 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <20150224141322.14029.91674@psf.io> Roundup Robot added the comment: New changeset 8969c7f44d9e by Victor Stinner in branch '2.7': Issue #23458: skip test_os.test_urandom_fd_non_inheritable() on Windows https://hg.python.org/cpython/rev/8969c7f44d9e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 15:25:05 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 14:25:05 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1424787905.8.0.975052846777.issue15753@psf.upfronthosting.co.za> Mark Lawrence added the comment: RuntimeError is now given instead of SystemError. Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:16:31) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def f(*args): ... print(super().__repr__()) ... >>> A().f() Traceback (most recent call last): File "", line 1, in File "", line 3, in f RuntimeError: super(): no arguments so presumably this can be closed as "out of date"? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 15:27:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Feb 2015 14:27:35 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1424788055.07.0.741504444428.issue23458@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, the test also fails on Mac OS X Tiger: http://buildbot.python.org/all/builders/x86%20Tiger%202.7/builds/2944/steps/test/logs/stdio ====================================================================== FAIL: test_urandom_fd_non_inheritable (test.test_os.URandomTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_os.py", line 597, in test_urandom_fd_non_inheritable self.assertEqual(open_fds - set(range(3)), set()) AssertionError: Items in the first set but not the second: 5 Why do we still maintain these old operating systems? :-p ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 15:56:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 14:56:06 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1424789766.93.0.953211879944.issue15753@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 16:02:30 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 15:02:30 +0000 Subject: [issue14073] allow per-thread atexit() In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za> Message-ID: <1424790150.11.0.0978293254576.issue14073@psf.upfronthosting.co.za> Mark Lawrence added the comment: The changes referenced in msg204494 ref: #19466 were reverted via changesets 9ce58a73b6b5 and 1166b3321012 ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 16:05:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 15:05:19 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1424790319.4.0.101978356403.issue17576@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The tests are checking that they are the same value (8) and the same type (int)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 16:15:02 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Tue, 24 Feb 2015 15:15:02 +0000 Subject: [issue23511] Broken code example in email module documentation Message-ID: <1424790902.68.0.738942973553.issue23511@psf.upfronthosting.co.za> New submission from Baptiste Mispelon: The first code example at https://docs.python.org/3.5/library/email-examples.html throws an `AttributeError` because `MIMEText`'s constructor expects a `str` object, not a `bytes` one: >>> # Import smtplib for the actual sending function ... import smtplib >>> >>> # Import the email modules we'll need ... from email.mime.text import MIMEText >>> >>> # Open a plain text file for reading. For this example, assume that ... # the text file contains only ASCII characters. ... fp = open(textfile, 'rb') >>> # Create a text/plain message ... msg = MIMEText(fp.read()) Traceback (most recent call last): File "", line 2, in File "/usr/lib/python3.4/email/mime/text.py", line 33, in __init__ _text.encode('us-ascii') AttributeError: 'bytes' object has no attribute 'encode' ---------- assignee: docs at python components: Documentation messages: 236503 nosy: bmispelon, docs at python priority: normal severity: normal status: open title: Broken code example in email module documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 16:18:59 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 15:18:59 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1424791139.25.0.88704603613.issue6598@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can we have a patch review please. If nothing else xrange will have to change for Python 3. ---------- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 16:25:11 2015 From: report at bugs.python.org (Edward D'Souza) Date: Tue, 24 Feb 2015 15:25:11 +0000 Subject: [issue23512] List of builtins is not alphabetical on https://docs.python.org/2/library/functions.html Message-ID: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za> New submission from Edward D'Souza: The list of built-in functions at the top of https://docs.python.org/2/library/functions.html is not alphabetical. Specifically, (apply, coerce, intern, buffer) allow appear out of order at the end of the list, instead of where they should be alphabetically. ---------- assignee: docs at python components: Documentation messages: 236505 nosy: docs at python, edsouza priority: normal severity: normal status: open title: List of builtins is not alphabetical on https://docs.python.org/2/library/functions.html type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 16:34:38 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Feb 2015 15:34:38 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424792078.32.0.241375249871.issue23476@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Python's SSL isn't using that. Python is taking in one big text file > of SSL certs, with no link structure, and feeding it to OpenSSL. Python's SSL is not "taking" anything: >>> r = urlopen('https://www.verisign.com') >>> r.read(10) b' >> cafile = 'cacert.pem' >>> r = urlopen('https://www.verisign.com', cafile=cafile) [...] urllib.error.URLError: You can *also* feed it a CA directory by using the "CApath" argument (*not* "CAfile"). Now it remains to be seen why "openssl s_client" works with the file nevertheless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 16:39:44 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Feb 2015 15:39:44 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424792384.89.0.760663261977.issue23476@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 16:49:19 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Hees?=) Date: Tue, 24 Feb 2015 15:49:19 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1424792959.07.0.167295152397.issue23509@psf.upfronthosting.co.za> J?rn Hees added the comment: cool minor question: - in the given patch __add__ uses __iadd__, but __sub__ doesn't use __isub__, which seems a bit weird. maybe off-topic, but maybe not, because of _keep_positive(self): - is there place for a non multi-set centric "Stats" object which is like Counter but with + and - actually behaving without the (in my use cases of Counter often counter intuitive) "> 0" stuff? (pun intended ;) ) Counter feels like a sub-class of Stats with the added _keep_positive(self). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 16:50:41 2015 From: report at bugs.python.org (Douman) Date: Tue, 24 Feb 2015 15:50:41 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) In-Reply-To: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> Message-ID: <1424793041.81.0.321311812195.issue23245@psf.upfronthosting.co.za> Douman added the comment: No problem in python implementation of HTTPSConnection Sorry ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 17:02:00 2015 From: report at bugs.python.org (Christian Heimes) Date: Tue, 24 Feb 2015 16:02:00 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424793720.13.0.39890797591.issue23476@psf.upfronthosting.co.za> Christian Heimes added the comment: John, neither Python nor OpenSSL are shipped with certificates. Python uses certificates from operating system. We decided against our own certificate store because we wanted to avoid exactly this kind of trouble. If Python can't verify a certificate then you have to update the certificate storage of your OS. On Linux and BSD Python, curl, wget and most other system tools use the OS's cert store. On Windows Python uses the same store as the IE, Chrome and other apps. Contrary to IE Python doesn't enforce cert store updates. You can reproduce the problem with curl, too. The first call uses the OS' store, the second overwrite the default store. $ curl https://www.verisign.com $ SSL_CERT_DIR=/tmp SSL_CERT_FILE=/tmp curl https://www.verisign.com ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 17:06:19 2015 From: report at bugs.python.org (Cory Benfield) Date: Tue, 24 Feb 2015 16:06:19 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424793979.91.0.812201088293.issue23476@psf.upfronthosting.co.za> Changes by Cory Benfield : ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 17:15:54 2015 From: report at bugs.python.org (Ian Cordasco) Date: Tue, 24 Feb 2015 16:15:54 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424794554.47.0.109338844376.issue23476@psf.upfronthosting.co.za> Ian Cordasco added the comment: So requests is running into this issue as well (see: https://github.com/kennethreitz/requests/issues/2455, https://github.com/kennethreitz/requests/issues/2456). With the specific code in Cory Benfield's comment (see: https://github.com/kennethreitz/requests/issues/2455#issuecomment-75773677) and the certificate file that requests 2.5.2 used (see: https://github.com/kennethreitz/requests/blob/d8be2473d1a586a3673d728d49e10fd4286e3b0e/requests/cacert.pem, raw: https://raw.githubusercontent.com/kennethreitz/requests/d8be2473d1a586a3673d728d49e10fd4286e3b0e/requests/cacert.pem) we can reproduce a similar problem on all versions of Python. At the moment, we're investigating the possibility that it has to do with cross-signed certificates (see: http://openssl.6102.n7.nabble.com/Problems-with-cross-signed-certificates-and-Authority-Key-Info-td52280.html). We have a number of servers that we can reproduce this against and it is not reproducible using openssl s_client which means it is an issue with how Python has written its openssl compatibility layer. ---------- nosy: +icordasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 17:20:37 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Feb 2015 16:20:37 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424794837.63.0.58320185886.issue23476@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, this is really a bug in the cert bundle provided by requests and Firefox. With requests 2.5.1: $ SSL_CERT_DIR=/tmp SSL_CERT_FILE=/tmp openssl s_client -CAfile requests/cacert.pem -connect verisign.com:443 => ok With requests 2.5.2: $ SSL_CERT_DIR=/tmp SSL_CERT_FILE=/tmp openssl s_client -CAfile requests/cacert.pem -connect verisign.com:443 => Verify return code: 20 (unable to get local issuer certificate) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 17:22:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Feb 2015 16:22:57 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424794977.54.0.729580281908.issue23476@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > and it is not reproducible using openssl s_client I have determined that s_client is buggy. It will always load the system certs *if and only if* you also pass it a valid custom CA cert (which is the reverse of what's expected). This is where it happens (in apps/s_client.c): if ((!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) || (!SSL_CTX_set_default_verify_paths(ctx))) { /* * BIO_printf(bio_err,"error setting default verify locations\n"); */ ERR_print_errors(bio_err); /* goto end; */ } This is why I forced SSL_CERT_* to empty locations in the examples above, so that only the custom CA bundle is used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 17:23:47 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Feb 2015 16:23:47 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424795027.59.0.639691495878.issue23476@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 17:31:27 2015 From: report at bugs.python.org (Donald Stufft) Date: Tue, 24 Feb 2015 16:31:27 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424795487.08.0.675510538108.issue23476@psf.upfronthosting.co.za> Donald Stufft added the comment: It appears it's not actually an issue with the CA Bundle, but I don't think it's actually an issue with Python, though Python might be in the best situation to try and fix it... Basically, it appears that OpenSSL does not look inside the trust root for any certificate served by the server. In this case the sites have a chain that looks like A -> B -> NEW ROOT being served by the server, and NEW ROOT is also signed by OLD ROOT. If I construct the chain being sent from the server so it doens't have NEW ROOT, then everything works, but if the chain being sent from the server has NEW ROOT, then OpenSSL will only trust it if OLD ROOT is in the trust bundle. In this case Mozilla (and requests) has NEW ROOT in the trust bundle but not OLD ROOT, becuase OLD ROOT is a 1024 bit key. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 17:34:53 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 24 Feb 2015 16:34:53 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424795693.01.0.69523077102.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Revision 7 of the bz2 patch is attached. Apologies for the flood of revisions to everyone and many thanks to Martin for noticing the problems every time, it boggles my mind that it took me 5 tries to add a simple cast. Antoine, I think this is ready for commit now. ---------- Added file: http://bugs.python.org/file38226/issue15955_bz2_rev7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 17:56:17 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 24 Feb 2015 16:56:17 +0000 Subject: [issue23510] multiprocessing bug SyncManager and 'with' In-Reply-To: <1424784474.12.0.228863603483.issue23510@psf.upfronthosting.co.za> Message-ID: <1424796977.28.0.565674451333.issue23510@psf.upfronthosting.co.za> Davin Potts added the comment: Successfully reproduced on OS X 10.10 with 2.7.9. Changing the issue type to "behavior" because "crash" is reserved for "Hard crashes of the Python interpreter ? possibly with a core dump or a Windows error box." In this issue, we do see an exception get raised but the interpreter itself is still happy and alive. ---------- nosy: +davin type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:01:43 2015 From: report at bugs.python.org (Cezary Wagner) Date: Tue, 24 Feb 2015 17:01:43 +0000 Subject: [issue23513] Add support for classes/object model in multiprocessing/pickle Message-ID: <1424797303.36.0.545069200968.issue23513@psf.upfronthosting.co.za> New submission from Cezary Wagner: Currently I trying to write multiprocessing program but it is impossible to write it in Python since I can not use many features and write unpythonic code. Simple example - how it should work: class Thing(object): class Result(object): def __init__(self, something): self.something = something def worker(self): return self.Result(1) def master(self): pool.apply_async(self.worker) Now I must do artificial code - not need for anybody and not solving any problem like this - artificial syntax :) class Result(object): def __init__(self, something): self.something = something def call_work_since_can_not_be_called_normally_by_multiprocessing_from_class(self): result = self.worker() return result class Thing(object): def worker(self): return Result(1) # how to overload it??? - no more inheritance def master(self): ... pool.apply_async(worker, args=(self,)) I my opinion that code is ugly and against python Zen. Why to not fix multiprocessing and pickle to support class.class or class.method - make code simpler and allow more people use parallelism in Python way not procedural way. ---------- components: Library (Lib) messages: 236516 nosy: Cezary.Wagner priority: normal severity: normal status: open title: Add support for classes/object model in multiprocessing/pickle type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:04:27 2015 From: report at bugs.python.org (Cezary Wagner) Date: Tue, 24 Feb 2015 17:04:27 +0000 Subject: [issue23513] Add support for classes/object model in multiprocessing/pickle In-Reply-To: <1424797303.36.0.545069200968.issue23513@psf.upfronthosting.co.za> Message-ID: <1424797467.57.0.1906128015.issue23513@psf.upfronthosting.co.za> Cezary Wagner added the comment: I am fighting with multiprocessing and still not won - I need to invent new Python coding style to use it and can not reduce ugly code/microcoding. It is not because it is not possible to do it in Python easier but because it is not improved yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:10:35 2015 From: report at bugs.python.org (Laura Creighton) Date: Tue, 24 Feb 2015 17:10:35 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424797835.51.0.804656967641.issue23476@psf.upfronthosting.co.za> Laura Creighton added the comment: Antione closed this, as a not python error, as if you do not pass a valid certificate to openssl s_client it will not read the system certificates, which is clearly utterly surprising and nuts. The problem, as I see it, is that fixing this clear absurdity may not fix a different underlying problem. So this one may need reopening when the real error us revealed. See if John Nagel's code works ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:12:19 2015 From: report at bugs.python.org (Cezary Wagner) Date: Tue, 24 Feb 2015 17:12:19 +0000 Subject: [issue23514] multiprocessing documentation - little more examples for parallel computing Message-ID: <1424797939.13.0.206434175912.issue23514@psf.upfronthosting.co.za> New submission from Cezary Wagner: I am little confused with multiprocessing documentation since it does not contain enough examples. Parallel computing is not simple by design so documentation can be little improved to make it simpler. No pattern to use pool with classes. No pattern to exchange objects between processes. Understanding usage of Queue and SimpleQueue or JoinableQueue is not very clear. Current documentation in majority is good reference with very rare examples / patterns. ---------- assignee: docs at python components: Documentation messages: 236519 nosy: Cezary.Wagner, docs at python priority: normal severity: normal status: open title: multiprocessing documentation - little more examples for parallel computing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:12:26 2015 From: report at bugs.python.org (Cezary Wagner) Date: Tue, 24 Feb 2015 17:12:26 +0000 Subject: [issue23514] multiprocessing documentation - little more examples for parallel computing In-Reply-To: <1424797939.13.0.206434175912.issue23514@psf.upfronthosting.co.za> Message-ID: <1424797946.33.0.76317007675.issue23514@psf.upfronthosting.co.za> Changes by Cezary Wagner : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:15:40 2015 From: report at bugs.python.org (Cory Benfield) Date: Tue, 24 Feb 2015 17:15:40 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424798140.75.0.615077451413.issue23476@psf.upfronthosting.co.za> Cory Benfield added the comment: The problem specifically is that OpenSSL only uses a *root* in the trust store as an anchor. That means any certificate that is signed by another certificate will not terminate the chain of trust. Browsers do better here, by trusting the entirety of the trust store, regardless of whether or not it's a root certificate. Donald is correct: this is not really Python's fault, it's OpenSSL's. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:19:34 2015 From: report at bugs.python.org (Aaron Meurer) Date: Tue, 24 Feb 2015 17:19:34 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424798374.24.0.0300985463963.issue23476@psf.upfronthosting.co.za> Changes by Aaron Meurer : ---------- nosy: +Aaron.Meurer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:20:55 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 24 Feb 2015 17:20:55 +0000 Subject: [issue23510] multiprocessing bug SyncManager and 'with' In-Reply-To: <1424784474.12.0.228863603483.issue23510@psf.upfronthosting.co.za> Message-ID: <1424798455.15.0.481586469226.issue23510@psf.upfronthosting.co.za> Davin Potts added the comment: A much simpler example of code triggering the described issue: import multiprocessing.managers with multiprocessing.managers.SyncManager() as s: print "here" Running the above code in 2.7.9 results in an exception with the traceback: Traceback (most recent call last): File "", line 2, in File "/home/somewhere/python/lib/python2.7/multiprocessing/managers.py", line 602, in __exit__ self.shutdown() AttributeError: 'SyncManager' object has no attribute 'shutdown' This is because the implementation of context manager functionality for multiprocessing.managers.BaseManager appears to have a bug. The above snippet of code might as well have been written to use BaseManager instead of SyncManager and the resulting behavior would have been the same. To be fair, nothing in the documentation appears to suggest that BaseManager or its subclasses can / should be used with the 'with' statement (as proper context managers). But it is also natural to react to the existence of '__enter__' and '__exit__' and think to try using it with a 'with' statement. Specifically in BaseManager, it looks like self.shutdown should have been set via __enter__'s call to start() yet inside __exit__ it's not resolving. I believe we need: 1) A patch to fix the broken behavior; 2) a test to validate that it works and specifically exercise the use of BaseManager with a 'with' statement; 3) an update to the docs to advertise context manager capability in these classes. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:23:41 2015 From: report at bugs.python.org (Cezary Wagner) Date: Tue, 24 Feb 2015 17:23:41 +0000 Subject: [issue23510] multiprocessing bug SyncManager and 'with' In-Reply-To: <1424784474.12.0.228863603483.issue23510@psf.upfronthosting.co.za> Message-ID: <1424798621.93.0.227757324377.issue23510@psf.upfronthosting.co.za> Cezary Wagner added the comment: Yes it is what is wanted by me and other people I think. 1. enter has not start call. 2. exit has shutdown but it is not supported 3. 'with' is what is need since it is simple to manage Good analysis. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:27:47 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 24 Feb 2015 17:27:47 +0000 Subject: [issue23514] multiprocessing documentation - little more examples for parallel computing In-Reply-To: <1424797939.13.0.206434175912.issue23514@psf.upfronthosting.co.za> Message-ID: <1424798867.37.0.0183389777526.issue23514@psf.upfronthosting.co.za> Davin Potts added the comment: This is a specific suggestion that should be included / addressed as part of issue23100. ---------- nosy: +davin type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:29:10 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 24 Feb 2015 17:29:10 +0000 Subject: [issue23513] Add support for classes/object model in multiprocessing/pickle In-Reply-To: <1424797303.36.0.545069200968.issue23513@psf.upfronthosting.co.za> Message-ID: <1424798950.48.0.134585674868.issue23513@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:30:03 2015 From: report at bugs.python.org (Cezary Wagner) Date: Tue, 24 Feb 2015 17:30:03 +0000 Subject: [issue23514] multiprocessing documentation - little more examples for parallel computing In-Reply-To: <1424797939.13.0.206434175912.issue23514@psf.upfronthosting.co.za> Message-ID: <1424799003.23.0.0917330851761.issue23514@psf.upfronthosting.co.za> Cezary Wagner added the comment: Should I add this suggestion to open before issue? I started doing multiprocessing code in Python so I can have more suggestions since I found that documentation can be improved I will report specific problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:35:05 2015 From: report at bugs.python.org (Cezary Wagner) Date: Tue, 24 Feb 2015 17:35:05 +0000 Subject: [issue23513] Add support for classes/object model in multiprocessing/pickle In-Reply-To: <1424797303.36.0.545069200968.issue23513@psf.upfronthosting.co.za> Message-ID: <1424799305.95.0.465990445479.issue23513@psf.upfronthosting.co.za> Cezary Wagner added the comment: I found that 'dill' module will solve some problems with class.class class.method lambda but not tested too much and it has big memory footprint about 7M. 'dill' not looks good since code need some polish to be more readable to be easy to review - I study 'dill' algorithm but not want use since code is not very clear and memory usage is high but it solve pickling many object is some way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:41:00 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 24 Feb 2015 17:41:00 +0000 Subject: [issue23507] Tuple creation is too slow In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> Message-ID: <1424799660.75.0.641902361446.issue23507@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:44:37 2015 From: report at bugs.python.org (Manuel Jacob) Date: Tue, 24 Feb 2015 17:44:37 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1424799877.97.0.299420041352.issue17576@psf.upfronthosting.co.za> Manuel Jacob added the comment: The tests in the attached patches (for example issue17576_v3.patch) check that both are 8, but the tests which were actually committed are checking that "my_int.__index__() == 8" and "operator.index(my_int) == 7". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:52:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 17:52:00 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1424800320.32.0.828642766402.issue6598@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The probability of a collision when generated n numbers from 0 to m-1 is 1 - factorial(m)/factorial(m-n)/m**n When n << sqrt(m), it is approximately equal to n**2/(2*m). When m = 1000000, we have problems for n about 1000. When increase m to 2**32, the probability of collisions is decreased to 0.01%. When increase m to 2**64 as recommended in [1], it is decreased to 2.7e-14. I.e. when generate 1000 IDs per second, collisions happen one per a million years. We could also take datetime with larger precision. E.g with 2 digits after the dot, as recommended in [1]. When apply both changes, we could generate 100000 IDs per second with one collision per 10000 years or 10000 IDs per second with one collision per 1000000 years. [1] https://tools.ietf.org/html/draft-ietf-usefor-message-id-01 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 18:59:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 17:59:40 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1424800780.77.0.745593392963.issue17576@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, it just checks current behavior. So we will know when this will be changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:02:51 2015 From: report at bugs.python.org (Oleg Broytman) Date: Tue, 24 Feb 2015 19:02:51 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1424804571.39.0.237865261061.issue23262@psf.upfronthosting.co.za> Oleg Broytman added the comment: I created the attached module to work with new FF in Python 2.7. You can convert it to proper patch for webbrowser.py. ---------- nosy: +phd Added file: http://bugs.python.org/file38227/new_firefox.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:08:09 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Tue, 24 Feb 2015 19:08:09 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424804889.28.0.340923156448.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: So... I know a decent amount of configure scripts, although Python's is easily going to be the absolute longest I've ever touched. Maybe these should be made against the 3.6 Mercurial source? I'm not sure if the Python devs would prefer that. Also, should the configure script be based on the Android target triple? ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:26:17 2015 From: report at bugs.python.org (Daniel Holth) Date: Tue, 24 Feb 2015 19:26:17 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424805977.58.0.538966064585.issue23491@psf.upfronthosting.co.za> Daniel Holth added the comment: Spelling raise PackError("Cannot spacify entry point if the source has __main__.py") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:30:51 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 24 Feb 2015 19:30:51 +0000 Subject: [issue23508] Document & unittest the subprocess.getstatusoutput() status value In-Reply-To: <1424768178.86.0.938424229154.issue23508@psf.upfronthosting.co.za> Message-ID: <1424806251.59.0.348952778957.issue23508@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Workaround: To determine the behavior of the interpreter your POSIX program is running under rather than a hard coded patch level version check, write appropriate conditional code to perform a test such as: _returns_new_status = subprocess.getstatusoutput('kill $$')[0] < 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:32:12 2015 From: report at bugs.python.org (Tim Peters) Date: Tue, 24 Feb 2015 19:32:12 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse Message-ID: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> New submission from Tim Peters: Some researchers found an error in the logic of merge_collapse, explained here, and with corrected code shown in section 3.2: http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/ This affects all current versions of Python. However, I marked the priority "low" because, as the article also notes, there's currently no machine in existence with enough memory to hold an array large enough for a contrived input to trigger an overflow of the pending-runs stack. It should be fixed anyway, and their suggested fix looks good to me. ---------- components: Interpreter Core messages: 236533 nosy: tim.peters priority: low severity: normal stage: needs patch status: open title: Bad logic in timsort's merge_collapse type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:33:06 2015 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 24 Feb 2015 19:33:06 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <1424806386.63.0.48265849476.issue23515@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:34:40 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 24 Feb 2015 19:34:40 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424806480.83.0.90699061701.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: Thanks, I'll fix for the next iteration of the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:47:11 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 19:47:11 +0000 Subject: [issue19711] add test for changed portions after reloading a namespace package In-Reply-To: <1385138827.34.0.898717139288.issue19711@psf.upfronthosting.co.za> Message-ID: <1424807231.79.0.652456009849.issue19711@psf.upfronthosting.co.za> Mark Lawrence added the comment: To echo Brett's question, do we still need this patch, Eric? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:49:33 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 19:49:33 +0000 Subject: [issue21099] Switch applicable importlib tests to use PEP 451 API In-Reply-To: <1396128875.13.0.712473033591.issue21099@psf.upfronthosting.co.za> Message-ID: <1424807373.03.0.439394205843.issue21099@psf.upfronthosting.co.za> Mark Lawrence added the comment: To echo Brett's question, should this be closed, Eric? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 20:53:19 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 19:53:19 +0000 Subject: [issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec) In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za> Message-ID: <1424807599.21.0.392384579175.issue18864@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've asked for updates on the two remaining dependencies #19711 and #21099. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 21:00:00 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 20:00:00 +0000 Subject: [issue9985] difflib.SequenceMatcher has slightly buggy and undocumented caching behavior In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za> Message-ID: <1424808000.07.0.478625933198.issue9985@psf.upfronthosting.co.za> Mark Lawrence added the comment: I believe this has been fixed by changesets f02a563ad1bf and ed73c127421c in #21635. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 21:05:21 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Tue, 24 Feb 2015 20:05:21 +0000 Subject: [issue23511] Broken code example in email module documentation In-Reply-To: <1424790902.68.0.738942973553.issue23511@psf.upfronthosting.co.za> Message-ID: <1424808321.38.0.220158734433.issue23511@psf.upfronthosting.co.za> Baptiste Mispelon added the comment: Patch attached. ---------- keywords: +patch Added file: http://bugs.python.org/file38228/issue23511.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 21:13:36 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 20:13:36 +0000 Subject: [issue11315] Fix/add unicode support in Cookie module? In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za> Message-ID: <1424808816.84.0.124591840328.issue11315@psf.upfronthosting.co.za> Mark Lawrence added the comment: The code was changed to do this in r83361 #3788. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 21:26:42 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 20:26:42 +0000 Subject: [issue2142] difflib.unified_diff(...) produces invalid patches In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za> Message-ID: <1424809602.95.0.117338990705.issue2142@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can we have a review on the updated patch please. ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 21:46:15 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 20:46:15 +0000 Subject: [issue10515] csv sniffer does not recognize quotes at the end of line In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za> Message-ID: <1424810775.14.0.182338254043.issue10515@psf.upfronthosting.co.za> Mark Lawrence added the comment: @David could you check Skip's patch out please. It seems identical to your own other than changing the delimiter from the empty string to a comma. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 21:53:07 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 24 Feb 2015 20:53:07 +0000 Subject: [issue23511] Broken code example in email module documentation In-Reply-To: <1424790902.68.0.738942973553.issue23511@psf.upfronthosting.co.za> Message-ID: <1424811187.67.0.380218501451.issue23511@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. ---------- nosy: +berker.peksag, r.david.murray stage: -> commit review versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:05:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 21:05:37 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424792959.07.0.167295152397.issue23509@psf.upfronthosting.co.za> Message-ID: <18038611.3B6GOZtQHu@raxxla> Serhiy Storchaka added the comment: > - in the given patch __add__ uses __iadd__, but __sub__ doesn't use > __isub__, which seems a bit weird. If Counters are positive (common case), then the result of addition is not less than both summands. a + b is a and may be additional elements from b. In the case of substraction a - b can be less than a and may be much less than a. In this case it is cheaper to create empty Counter and copy only those elements from a that are not in b, than copy all a and then remove almost all elements. Relative efficiency depends on input data, and for some input data implementing __sub__ via __isub__ can be more efficient. > - is there place for a non multi-set centric "Stats" object which is like > Counter but with + and - actually behaving without the (in my use cases of > Counter often counter intuitive) "> 0" stuff? (pun intended ;) ) Counter > feels like a sub-class of Stats with the added _keep_positive(self). I'm sure there is such class in third-party modules. Counter wouldn't have much benefit from inheriting "Stats", because it would need to override almost all methods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:05:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 21:05:40 +0000 Subject: [issue23493] optimize sort_keys in json module by using operator.itemgetter() In-Reply-To: <1424691010.23.0.0950197012527.issue23493@psf.upfronthosting.co.za> Message-ID: <17592235.hjUk8I6WDd@raxxla> Serhiy Storchaka added the comment: May be there is a time to optimize creating Python frames (at least for the case when one frame is created and destroyed multiple times). May be frame pool? Or cached one frame per function? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:18:30 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 21:18:30 +0000 Subject: [issue10954] csv.reader/writer to raise exception if mode is binary or newline is not '' In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za> Message-ID: <1424812710.95.0.387382974677.issue10954@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've changed this issue to reflect what I think it should be saying. ---------- nosy: +BreamoreBoy title: No warning for csv.writer API change -> csv.reader/writer to raise exception if mode is binary or newline is not '' type: enhancement -> behavior versions: +Python 3.4, Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:21:12 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 21:21:12 +0000 Subject: [issue12026] Support more of MSI api In-Reply-To: <1304743825.08.0.890355737934.issue12026@psf.upfronthosting.co.za> Message-ID: <1424812872.56.0.629892551308.issue12026@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- components: +Windows nosy: +steve.dower, tim.golden, zach.ware versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:26:05 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 24 Feb 2015 21:26:05 +0000 Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1 In-Reply-To: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za> Message-ID: <1424813165.84.0.348727890861.issue12010@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is this effectively superseded by work being done on #23496? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:32:19 2015 From: report at bugs.python.org (John Nagle) Date: Tue, 24 Feb 2015 21:32:19 +0000 Subject: [issue23476] SSL cert verify fail for "www.verisign.com" In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za> Message-ID: <1424813539.34.0.22523521411.issue23476@psf.upfronthosting.co.za> John Nagle added the comment: I've reported this as an update to OpenSSL bug #2634. (http://rt.openssl.org/Ticket/Display.html?id=2634) Now we have to follow up there. This bug should probably be set to "pending", not "closed". The problem is upstream, but OpenSSL is the Python libraries' choice, not the users'. Python for Windows ships with its own copy of OpenSSL, so when (if) OpenSSL is fixed, the Python Windows distros will need an update. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:45:17 2015 From: report at bugs.python.org (Chris Rebert) Date: Tue, 24 Feb 2015 21:45:17 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <1424814317.02.0.181200226344.issue23515@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:56:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 21:56:26 +0000 Subject: [issue22364] Improve some re error messages using regex for hints In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1424814986.48.0.206514853777.issue22364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch borrows the error message about min > max from regex. ---------- Added file: http://bugs.python.org/file38229/re_errors_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:57:58 2015 From: report at bugs.python.org (Chris Kaynor) Date: Tue, 24 Feb 2015 21:57:58 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <1424815078.78.0.21007487085.issue23515@psf.upfronthosting.co.za> Changes by Chris Kaynor : ---------- nosy: +DragonFireCK _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 22:58:00 2015 From: report at bugs.python.org (Leonardo Tancredi) Date: Tue, 24 Feb 2015 21:58:00 +0000 Subject: [issue23516] requests: parse_url() mishandles special characters when the URL specifies authentication credentials Message-ID: <1424815080.16.0.743473330916.issue23516@psf.upfronthosting.co.za> New submission from Leonardo Tancredi: I was running pip install with the --proxy switch to authenticate to a proxy server with user "user" and password "pass?word", when I noticed it fails. It seems to fail when the password contains some special characters, v.g., ? and #. Here's the exception I saw: Exception: Traceback (most recent call last): File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/basecommand.py", line 232, in main status = self.run(options, args) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/commands/install.py", line 339, in run requirement_set.prepare_files(finder) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/req/req_set.py", line 333, in prepare_files upgrade=self.upgrade, File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/index.py", line 305, in find_requirement page = self._get_page(main_index_url, req) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/index.py", line 783, in _get_page return HTMLPage.get_page(link, req, session=self.session) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/index.py", line 872, in get_page "Cache-Control": "max-age=600", File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/sessions.py", line 473, in get return self.request('GET', url, **kwargs) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/download.py", line 365, in request return super(PipSession, self).request(method, url, *args, **kwargs) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/sessions.py", line 461, in request resp = self.send(prep, **send_kwargs) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/sessions.py", line 573, in send r = adapter.send(request, **kwargs) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/cachecontrol/adapter.py", line 43, in send resp = super(CacheControlAdapter, self).send(request, **kw) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/adapters.py", line 337, in send conn = self.get_connection(request.url, proxies) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/adapters.py", line 245, in get_connection proxy_manager = self.proxy_manager_for(proxy) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/adapters.py", line 155, in proxy_manager_for **proxy_kwargs) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/packages/urllib3/poolmanager.py", line 265, in proxy_from_url return ProxyManager(proxy_url=url, **kw) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/packages/urllib3/poolmanager.py", line 210, in __init__ proxy = parse_url(proxy_url) File "/usr/local/lib/python3.3/site-packages/pip-6.0.8-py3.3.egg/pip/_vendor/requests/packages/urllib3/util/url.py", line 185, in parse_url raise LocationParseError(url) pip._vendor.requests.packages.urllib3.exceptions.LocationParseError: Failed to parse: user:pass AFAICT the problem lies in function parse_url() in url.py because it assumes that there cannot exist neither a ? nor a # between the :// and the next / . This does not hold, because a URL can include a username and a password right there, as in http://user:pass?word at host/path. Here's the offending piece of code: if '://' in url: scheme, url = url.split('://', 1) # Find the earliest Authority Terminator # (http://tools.ietf.org/html/rfc3986#section-3.2) url, path_, delim = split_first(url, ['/', '?', '#']) It's funny that this snippet violates precisely the specification given in that comment (RFC3986 section 3.2), because it clearly states that this string can contain a userinfo field: authority = [ userinfo "@" ] host [ ":" port ] For some reason, urlencoding the password did not help either, the error message did not change. ---------- components: Extension Modules messages: 236550 nosy: leotan priority: normal severity: normal status: open title: requests: parse_url() mishandles special characters when the URL specifies authentication credentials type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 23:04:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Feb 2015 22:04:55 +0000 Subject: [issue22364] Improve some re error messages using regex for hints In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za> Message-ID: <1424815495.55.0.0186805467726.issue22364@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Removed changing TypeError errors and "bad repeat interval" error in updated regex patch. ---------- Added file: http://bugs.python.org/file38230/regex_errors2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 23:38:42 2015 From: report at bugs.python.org (Tommaso Barbugli) Date: Tue, 24 Feb 2015 22:38:42 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly Message-ID: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> New submission from Tommaso Barbugli: Hi, I am porting a library from python 2.7 to 3.4 and I noticed that the behaviour of datetime.utcfromtimestamp is not consistent between the two versions. For example on python 2.7.5 datetime.utcfromtimestamp(1424817268.274) returns a datetime with 274000 microseconds the same code in python 3.4 returns a datetime with 273999 microseconds. ---------- components: Library (Lib) messages: 236552 nosy: tbarbugli priority: normal severity: normal status: open title: datetime.utcfromtimestamp parses timestamps incorrectly type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 24 23:43:21 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 24 Feb 2015 22:43:21 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424817801.17.0.150427128306.issue23517@psf.upfronthosting.co.za> Ethan Furman added the comment: This seems to have changed in 3.3 (versions up to 3.2 return 274000). ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 00:15:44 2015 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 24 Feb 2015 23:15:44 +0000 Subject: [issue10954] csv.reader/writer to raise exception if mode is binary or newline is not '' In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za> Message-ID: <1424819744.3.0.608849565543.issue10954@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- nosy: -skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 00:32:58 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Feb 2015 23:32:58 +0000 Subject: [issue8895] newline vs. newlines in io module In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za> Message-ID: <1424820778.97.0.791017171838.issue8895@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 00:37:14 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 24 Feb 2015 23:37:14 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1424821034.84.0.404430445779.issue15753@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Wasn't the objection that super shouldn't screw up, not the specific type of the exception? ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 00:43:05 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Feb 2015 23:43:05 +0000 Subject: [issue10954] csv.reader/writer to raise exception if mode is binary or newline is not '' In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za> Message-ID: <1424821385.04.0.778505579137.issue10954@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect it may not be practical to check the newline translation mode of a TextIOWrapper or StringIO stream, and I don?t think newline translation is even required in general for text stream classes. Beware that the ?newlines? attribute isn?t going to help; see Issue 8895. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 00:52:42 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 24 Feb 2015 23:52:42 +0000 Subject: [issue23516] requests: parse_url() mishandles special characters when the URL specifies authentication credentials In-Reply-To: <1424815080.16.0.743473330916.issue23516@psf.upfronthosting.co.za> Message-ID: <1424821962.28.0.345285466455.issue23516@psf.upfronthosting.co.za> Martin Panter added the comment: Sounds like this might be in a third-party module, not in Python itself. But see also Issue 23328 and Issue 18140. The RFC you referenced also says this, which suggests the authority cannot contain a literal question mark: ?The authority component . . . is terminated by the next slash ("/"), question mark ("?"), or number sign ("#") character, or by the end of the URI.? Some more definitions from that RFC indicating a literal question mark is not allowed in ?userinfo?: userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" pct-encoded = "%" HEXDIG HEXDIG sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 01:05:34 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 25 Feb 2015 00:05:34 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1424822734.26.0.838493306737.issue2292@psf.upfronthosting.co.za> Guido van Rossum added the comment: The patch no longer applies cleanly. I had to do "hg up -r ac0d6c09457e" to get a checkpoint to which it applies. (But I'm not sure at what point that landed me.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 02:15:40 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 25 Feb 2015 01:15:40 +0000 Subject: [issue23516] requests: parse_url() mishandles special characters when the URL specifies authentication credentials In-Reply-To: <1424815080.16.0.743473330916.issue23516@psf.upfronthosting.co.za> Message-ID: <1424826940.68.0.253890455033.issue23516@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 02:25:08 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 25 Feb 2015 01:25:08 +0000 Subject: [issue23516] requests: parse_url() mishandles special characters when the URL specifies authentication credentials In-Reply-To: <1424815080.16.0.743473330916.issue23516@psf.upfronthosting.co.za> Message-ID: <1424827508.53.0.191628428832.issue23516@psf.upfronthosting.co.za> Demian Brecht added the comment: > Sounds like this might be in a third-party module +1. urllib3.url_parse doesn't make use of the standard library. > userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) This leads me to believe that using something like this might work: from urllib.parse import quote userinfo = '{}:{}'.format(quote(user), quote(password)) That said, there's also another relevant block that should be of note in the RFC: Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used. In any event, this issue should be closed as it's not related to the standard library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 03:28:29 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 25 Feb 2015 02:28:29 +0000 Subject: [issue23486] Enum member lookup is 20x slower than normal class attribute lookup In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za> Message-ID: <1424831309.9.0.829649895093.issue23486@psf.upfronthosting.co.za> Ethan Furman added the comment: This isn't a change to the API or any visible user behavior (besides performance), so I don't see a reason to not add it to 3.4. ---------- nosy: +barry, eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 03:58:19 2015 From: report at bugs.python.org (Zack Weinberg) Date: Wed, 25 Feb 2015 02:58:19 +0000 Subject: [issue23518] Misplaced diagnostic caret for some SyntaxErrors Message-ID: <1424833099.8.0.762005260502.issue23518@psf.upfronthosting.co.za> New submission from Zack Weinberg: I tripped over a couple of SyntaxError cases where the diagnostic caret is misplaced. >>> While x: File "", line 1 While x: ^ SyntaxError: invalid syntax The caret should point to the capital W in 'While'. >>> for x in the range(10): File "", line 1 for x in the range(10): ^ SyntaxError: invalid syntax The caret should point to the 'the'. ---------- messages: 236560 nosy: zwol priority: normal severity: normal status: open title: Misplaced diagnostic caret for some SyntaxErrors _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 05:05:14 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 25 Feb 2015 04:05:14 +0000 Subject: [issue23518] Misplaced diagnostic caret for some SyntaxErrors In-Reply-To: <1424833099.8.0.762005260502.issue23518@psf.upfronthosting.co.za> Message-ID: <1424837114.8.0.0135810029549.issue23518@psf.upfronthosting.co.za> Zachary Ware added the comment: The caret is correct: >>> While = 'some string' >>> While 'some string' >>> the = range(10) >>> the range(0, 10) >>> for x in the: pass ... >>> In both cases, the error is having an expression followed by an expression, and the caret points at the second expression. There's nothing wrong with 'While' and 'the', they're perfectly legitimate names, though rarely used. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 05:09:59 2015 From: report at bugs.python.org (Leonardo Tancredi) Date: Wed, 25 Feb 2015 04:09:59 +0000 Subject: [issue23516] requests: parse_url() mishandles special characters when the URL specifies authentication credentials In-Reply-To: <1424815080.16.0.743473330916.issue23516@psf.upfronthosting.co.za> Message-ID: <1424837399.86.0.454642246709.issue23516@psf.upfronthosting.co.za> Leonardo Tancredi added the comment: OK, firstly you'll have to excuse me, a mere sporadic Python user, for not having a clear idea about how Python development is structured. I can't tell how to label this bug report because I don't know where pip comes from: as far as I knew this is a bug in something called urllib3, which seemed to me that was related to Python itself, or maybe in the way pip is calling it, and I assumed pip was part of the Python project too. I couldn't really tell what it is that you call Extension Modules, or whether this urllib3 thing is part of what you call the "Library (Lib)" component. I didn't want to have to research in depth how this project is developed just to report what seems to be a glaring bug, at least from a user's viewpoint. I could've just dropped this thing but I thought Python would be better served by a bug report, however misdirected. I hope that you can relabel this bug accordingly to its relevant component so that this bug gets attention from the relevant team. Thank you for mentioning issue 23328, which did not come up in a search I did previous to filing my report: it does seem quite related. And that issue is marked as "Library (Lib)" and nobody complained about it so maybe this issue should be marked like that too. Please somebody who knows what's the best way to move this forward relabel it as necessary. Now, I understand the argument for not allowing unencoded passwords, but as I mentioned in the last line of my report, I did also try urlencoding it and got the exact same error message. Should pip not allow the use of authenticated proxies at all? I don't think that would be the best option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 05:18:52 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 25 Feb 2015 04:18:52 +0000 Subject: [issue9938] Documentation for argparse interactive use In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za> Message-ID: <1424837932.97.0.0603523033588.issue9938@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: -ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 05:22:45 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 25 Feb 2015 04:22:45 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1424838165.85.0.203535341234.issue17963@psf.upfronthosting.co.za> Ethan Furman added the comment: Eli, did you ever make any progress with this? Anything you can post so someone else can run with it if you don't have time? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 07:48:52 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 25 Feb 2015 06:48:52 +0000 Subject: [issue23516] requests: parse_url() mishandles special characters when the URL specifies authentication credentials In-Reply-To: <1424837399.86.0.454642246709.issue23516@psf.upfronthosting.co.za> Message-ID: <13C6589A-7399-4F69-91F0-C93EF30EF527@gmail.com> Demian Brecht added the comment: > I can't tell how to label this bug report because I don't know where pip comes from: as far as I knew this is a bug in something called urllib3, which seemed to me that was related to Python itself, or maybe in the way pip is calling it, and I assumed pip was part of the Python project too. What you?re seeing in your stack trace is an issue with packages developed independently of the Python standard library. pip (https://github.com/pypa/pip), requests (https://github.com/kennethreitz/requests) and urllib3 (https://github.com/shazow/urllib3) are all maintained externally and hosted on PyPI (https://pypi.python.org/pypi). Issues here are for bugs, enhancements and such for the Python standard library. Each one of the aforementioned projects (with the caveat of pip in Python 3.4+) maintain their own sets of issues on Github. > Thank you for mentioning issue 23328, which did not come up in a search I did previous to filing my report: it does seem quite related. > And that issue is marked as "Library (Lib)" and nobody complained about it so maybe this issue should be marked like that too. Indeed it does seem related and it?s possible that urllib3 took parts of the code from urllib, which /is/ part of the standard library and is what 23328 was reported against, hence the ?Lib? tag for that one. > Please somebody who knows what's the best way to move this forward relabel it as necessary. I?ll add a few people who may be interested in this issue, but I imagine that the issue would likely be moved to the urllib3 project. Hope that all makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 07:49:15 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 25 Feb 2015 06:49:15 +0000 Subject: [issue23516] requests: parse_url() mishandles special characters when the URL specifies authentication credentials In-Reply-To: <1424815080.16.0.743473330916.issue23516@psf.upfronthosting.co.za> Message-ID: <1424846955.37.0.375288102366.issue23516@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +Marcus.Smith, dstufft, ncoghlan, pmoore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 10:23:36 2015 From: report at bugs.python.org (Dave Sawyer) Date: Wed, 25 Feb 2015 09:23:36 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1424856216.6.0.30527781327.issue6818@psf.upfronthosting.co.za> Dave Sawyer added the comment: I'd be interested in taking up the zip portion at Pycon 2015 this year. I recently had need to delete file(s) from a zipfile. To do it today with the existing API requires you to unpack the zip and repack it. The unpack is slow and you need enough free disk space for the uncompressed files. My strategy is essentially exactly what msg229893 2a said: copy binary blobs to a tempfile, then overwrite the original when complete. I would use a name filter function to decide what to delete and optional parameter for the temp file (falling back to tempfile.tempfile if None). IIRC, this is the same strategy used in the dotNet zip library. ---------- nosy: +Dave Sawyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 10:30:54 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 25 Feb 2015 09:30:54 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424856654.7.0.867914719706.issue23517@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 11:04:23 2015 From: report at bugs.python.org (Cyd Haselton) Date: Wed, 25 Feb 2015 10:04:23 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424858663.07.0.149124444242.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Pulling from Mercurial will require taking a couple of huge steps back, as I've ported git to the environment I am using but not Mercurial. It would also mean getting up to speed *fast* as I know nothing about VCS...including Mercurial. I'm willing to do this (what's another port after all) but it may be a while before I can get everything set up correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 11:04:47 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 25 Feb 2015 10:04:47 +0000 Subject: [issue23508] Document & unittest the subprocess.getstatusoutput() status value In-Reply-To: <1424768178.86.0.938424229154.issue23508@psf.upfronthosting.co.za> Message-ID: <1424858687.01.0.505634514905.issue23508@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 11:54:26 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Feb 2015 10:54:26 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424858663.07.0.149124444242.issue23496@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Take a look at https://docs.python.org/devguide/gitdevs.html "Mercurial for git developers" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 11:57:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 10:57:18 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1424861838.44.0.798095253969.issue6818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it would be better if new method would copy filtered content to other ZIP file. Not alway you want to modifying the original file. The question is what to do with the data before the start of the ZIP file or between files in the ZIP file, or if files in the ZIP file are overlapped. Here is a sample of such file. ---------- Added file: http://bugs.python.org/file38231/tricky.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 12:00:40 2015 From: report at bugs.python.org (Mathieu Pasquet) Date: Wed, 25 Feb 2015 11:00:40 +0000 Subject: [issue23519] using asyncio.iscoroutinefunction() on a functools.partial object Message-ID: <1424862040.11.0.0579325382624.issue23519@psf.upfronthosting.co.za> New submission from Mathieu Pasquet: Using iscoroutinefunction() on an object returned by functools.partial() should return True if the function wrapped was a coroutine function. (a recursive loop like the one in asyncio/events.py get_function_source() may be what needs to be done) ---------- components: asyncio messages: 236569 nosy: gvanrossum, haypo, mathieui, yselivanov priority: normal severity: normal status: open title: using asyncio.iscoroutinefunction() on a functools.partial object type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 12:05:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Feb 2015 11:05:18 +0000 Subject: [issue23519] using asyncio.iscoroutinefunction() on a functools.partial object In-Reply-To: <1424862040.11.0.0579325382624.issue23519@psf.upfronthosting.co.za> Message-ID: <1424862318.41.0.010946728308.issue23519@psf.upfronthosting.co.za> STINNER Victor added the comment: Take a look at asyncio.events._get_function_source() which supports wrapped functions and functools.partial. Can you propose a patch? If iscoroutinefunction() becomes "expensive", we might make checks optional, only run them in debug mode. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 12:38:37 2015 From: report at bugs.python.org (Cyd Haselton) Date: Wed, 25 Feb 2015 11:38:37 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424864317.07.0.54464202254.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Thanks for the suggestion Victor, however I've only ported git to this environment; the most I;ve used it is to run 'git clone' to pull source from a repo. The recommendation from the mobile-sig mailing list is...given my lack of familiarity with VCS..is to attempt to port and work with Mercurial. If doing so starts to take too much bandwidth I'll fall back to git and the article you linked. Side Note: I cannot emphasize enough how little I know about how to use git and most of the other tools I've ported to this environment. My goal was to get as many of the 'standard' Linux utilities running in this environment, then start learning them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 13:54:48 2015 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 25 Feb 2015 12:54:48 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1424868888.63.0.57494868736.issue17963@psf.upfronthosting.co.za> Eli Bendersky added the comment: I don't have time, unfortunately. So other folks can pick this up. I don't remember if I made any progress on this - will post whatever I have if I find something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 13:56:23 2015 From: report at bugs.python.org (Alex Shkop) Date: Wed, 25 Feb 2015 12:56:23 +0000 Subject: [issue22094] oss_audio_device.write(data) produces short writes In-Reply-To: <1406543360.46.0.562125681265.issue22094@psf.upfronthosting.co.za> Message-ID: <1424868983.09.0.0526558278505.issue22094@psf.upfronthosting.co.za> Alex Shkop added the comment: It seems to me that OSS device doesn't accept more than SNDCTL_DSP_GETOSPACE. Looks like this depends on OSS version because OSS docs state that since 4.x one shouldn't use SNDCTL_DSP_GETOSPACE at all [http://manuals.opensound.com/developer/SNDCTL_DSP_GETOSPACE.html]. I have OSS 3.8.2 and I can reproduce the bug. Can someone with OSS >= 4.0 confirm that dsp.write() works as expected? ---------- nosy: +ashkop _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 14:30:03 2015 From: report at bugs.python.org (Alexey) Date: Wed, 25 Feb 2015 13:30:03 +0000 Subject: [issue23520] test_os failed (python-3.4.3) Message-ID: <1424871003.6.0.446487630162.issue23520@psf.upfronthosting.co.za> New submission from Alexey: Just one test failed for python-3.4.3 ....... test_invalid_offset (test.test_os.TestSendfile) ... FAIL ....... ---------- files: test_os_log messages: 236574 nosy: avoevodkin priority: normal severity: normal status: open title: test_os failed (python-3.4.3) versions: Python 3.4 Added file: http://bugs.python.org/file38232/test_os_log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 14:57:07 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Feb 2015 13:57:07 +0000 Subject: [issue23511] Broken code example in email module documentation In-Reply-To: <1424790902.68.0.738942973553.issue23511@psf.upfronthosting.co.za> Message-ID: <1424872627.71.0.897271781931.issue23511@psf.upfronthosting.co.za> R. David Murray added the comment: Looks like the example wasn't updated during the python3 transition. As long as we are changing it, we might as well make it use the file as a context manager. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 15:05:44 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Wed, 25 Feb 2015 14:05:44 +0000 Subject: [issue23511] Broken code example in email module documentation In-Reply-To: <1424790902.68.0.738942973553.issue23511@psf.upfronthosting.co.za> Message-ID: <1424873144.32.0.930188656614.issue23511@psf.upfronthosting.co.za> Baptiste Mispelon added the comment: I wasn't sure if that was going to be out of scope or not. Here's an attached patch that fixes the remaining usages of `open` inside `Doc/includes` to always use a context manager. ---------- Added file: http://bugs.python.org/file38233/issue23511_open_cm.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 15:11:57 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Feb 2015 14:11:57 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424873517.7.0.134066790847.issue23517@psf.upfronthosting.co.za> R. David Murray added the comment: Most likely this was a rounding fix (ie: not a bug), but hopefully Alexander will know for sure. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 15:17:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 14:17:22 +0000 Subject: [issue23520] test_os failed (python-3.4.3) In-Reply-To: <1424871003.6.0.446487630162.issue23520@psf.upfronthosting.co.za> Message-ID: <1424873842.12.0.225942992171.issue23520@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Extension Modules nosy: +giampaolo.rodola, rosslagerwall type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 15:35:11 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Feb 2015 14:35:11 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424874911.57.0.00035245169161.issue23496@psf.upfronthosting.co.za> R. David Murray added the comment: There is a github mirror of the hg repository (https://github.com/python/cpython). Patches produced from it don't automatically get review links in the tracker, but at least they would then be against the most current source (and someone else could regenerate them). That would at least allow you to skip the "port mercurial" step. On the other hand, it sounds like Ryan may be volunteering to update the patches to apply to the head of default for you. (And yes, Ryan, the patches should be against the head of the default branch.) Now, whether or not we will accept the patches is a different discussion, but I'd certainly like to see more Android support in our tree myself. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 15:45:33 2015 From: report at bugs.python.org (Zack Weinberg) Date: Wed, 25 Feb 2015 14:45:33 +0000 Subject: [issue23518] Misplaced diagnostic caret for some SyntaxErrors In-Reply-To: <1424833099.8.0.762005260502.issue23518@psf.upfronthosting.co.za> Message-ID: <1424875533.92.0.414643230939.issue23518@psf.upfronthosting.co.za> Zack Weinberg added the comment: In terms of the formal grammar of the language, you are correct. However, the position of the caret should be chosen based *not* on the formal grammar, but on a heuristic estimation of what the most probable mistake actually is. In both of the cases I listed, the most probable mistake is as I described. Please reconsider. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:00:55 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 15:00:55 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424876455.06.0.347093908911.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Let me dig up the history, but this does not look like correct rounding to me: >>> datetime.utcfromtimestamp(1424817268.274) datetime.datetime(2015, 2, 24, 22, 34, 28, 273999) >>> decimal.Decimal(1424817268.274) Decimal('1424817268.2739999294281005859375') ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:13:28 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 15:13:28 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424877208.25.0.162845303414.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like it was an intentional change. See #14180 (changeset 75590:1e9cc1a03365). I am not sure what the motivation was. Note that this change made utcfromtimestamp(t) different from datetime(1970,1,1) + timedelta(seconds=t). ---------- keywords: +3.2regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:13:42 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 25 Feb 2015 15:13:42 +0000 Subject: [issue23518] Misplaced diagnostic caret for some SyntaxErrors In-Reply-To: <1424833099.8.0.762005260502.issue23518@psf.upfronthosting.co.za> Message-ID: <1424877222.59.0.282086982726.issue23518@psf.upfronthosting.co.za> Zachary Ware added the comment: The problem is, the interpreter can't know what you meant to do, so it can only point out what it can't compile. We did recently add a special case for print without parentheses, but adding special cases for everything is just not feasible. Besides, where should the caret point in each of these cases, why, and how would you explain it to the parser? for x in the range(10): for x in range(10) the: for x in range(10) range(10): for each x in range(10): for x each in range(10): Those are just some of the possibilities for just the for statement, let alone every other statement, or even every place an expression can be used. If you can come up with a good, simple, general patch that covers every case, please do so! I'm quite sure it would be accepted. But until then, I'm afraid this isn't going to happen. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:17:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Feb 2015 15:17:18 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <20150225151705.29694.40659@psf.io> Roundup Robot added the comment: New changeset 325aec842e3e by Benjamin Peterson in branch '2.7': fix merge_collapse to actually maintain the invariant it purports to (closes #23515) https://hg.python.org/cpython/rev/325aec842e3e New changeset 620cb13008b7 by Benjamin Peterson in branch '3.4': fix merge_collapse to actually maintain the invariant it purports to (closes #23515) https://hg.python.org/cpython/rev/620cb13008b7 New changeset be5ddc8b6a88 by Benjamin Peterson in branch 'default': merge 3.4 (#23515) https://hg.python.org/cpython/rev/be5ddc8b6a88 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:24:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:24:15 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1424877855.71.0.98486279877.issue20187@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:24:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:24:44 +0000 Subject: [issue20256] Argument Clinic: compare signed and unsigned ints In-Reply-To: <1389688549.54.0.106907827652.issue20256@psf.upfronthosting.co.za> Message-ID: <1424877884.95.0.966861497823.issue20256@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:24:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:24:55 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1424877895.53.0.387004168276.issue20159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:25:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:25:04 +0000 Subject: [issue20304] Argument Clinic: char convertor should use default values of type bytes In-Reply-To: <1390146665.62.0.375243979235.issue20304@psf.upfronthosting.co.za> Message-ID: <1424877904.18.0.472933879384.issue20304@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:25:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:25:11 +0000 Subject: [issue20303] Argument Clinic: optional groups In-Reply-To: <1390138180.16.0.400473002032.issue20303@psf.upfronthosting.co.za> Message-ID: <1424877911.41.0.976223685439.issue20303@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:25:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:25:20 +0000 Subject: [issue20346] Argument Clinic: missing entry in table mapping legacy convertors to real AC converters In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za> Message-ID: <1424877920.94.0.551995533907.issue20346@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:25:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:25:31 +0000 Subject: [issue20396] Argument Clinic: Touch source file if any output file changed In-Reply-To: <1390744941.56.0.0539875742197.issue20396@psf.upfronthosting.co.za> Message-ID: <1424877931.36.0.732954043687.issue20396@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:25:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:25:41 +0000 Subject: [issue20410] Argument Clinic: add 'self' return converter In-Reply-To: <1390847418.07.0.605398644696.issue20410@psf.upfronthosting.co.za> Message-ID: <1424877941.0.0.201838619557.issue20410@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:25:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:25:49 +0000 Subject: [issue20432] Argument Clinic: when cloning functions with path_t, path_t retains the old name In-Reply-To: <1390973163.52.0.0655010569883.issue20432@psf.upfronthosting.co.za> Message-ID: <1424877949.09.0.415758111035.issue20432@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:26:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:26:01 +0000 Subject: [issue20459] No Argument Clinic documentation on how to specify a return converter In-Reply-To: <1391185302.8.0.888255910236.issue20459@psf.upfronthosting.co.za> Message-ID: <1424877961.79.0.46249097893.issue20459@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:26:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:26:09 +0000 Subject: [issue20461] Argument Clinic included return converters hard code use of ``_return_value`` In-Reply-To: <1391189327.05.0.0632329148594.issue20461@psf.upfronthosting.co.za> Message-ID: <1424877969.08.0.631670276381.issue20461@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:26:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:26:22 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1424877982.04.0.678063940932.issue20260@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:26:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:26:31 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1424877991.39.0.250541040511.issue20168@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:26:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:26:50 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1424878010.8.0.42687411769.issue20172@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:27:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:27:01 +0000 Subject: [issue20171] Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c In-Reply-To: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za> Message-ID: <1424878021.4.0.321094342472.issue20171@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:27:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:27:09 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1424878029.46.0.856952094078.issue20173@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:27:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:27:19 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1424878039.59.0.528980789276.issue20174@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:27:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:27:30 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1424878050.56.0.518113472669.issue20175@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:27:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:27:40 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1424878060.03.0.048939431469.issue20177@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:27:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:27:48 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1424878068.32.0.926875872347.issue20178@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:27:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:27:56 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1424878076.97.0.619368875281.issue20179@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:28:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:28:10 +0000 Subject: [issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za> Message-ID: <1424878090.03.0.0900856213058.issue20181@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:28:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:28:23 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1424878103.94.0.549356763482.issue20182@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:28:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:28:32 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1424878112.89.0.993877951115.issue20323@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic nosy: +steve.dower, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:28:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:28:43 +0000 Subject: [issue20586] Argument Clinic: functions with valid sig but no docstring have no __text_signature__ In-Reply-To: <1392064106.25.0.899710933953.issue20586@psf.upfronthosting.co.za> Message-ID: <1424878123.88.0.486335663665.issue20586@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:28:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:28:52 +0000 Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za> Message-ID: <1424878132.36.0.0186032002646.issue20184@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:29:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:29:05 +0000 Subject: [issue20291] Argument Clinic should understand *args and **kwargs parameters In-Reply-To: <1390010125.91.0.58212727704.issue20291@psf.upfronthosting.co.za> Message-ID: <1424878145.55.0.758882512963.issue20291@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:29:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:29:12 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1424878152.97.0.83737371528.issue20186@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:29:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:29:23 +0000 Subject: [issue20183] Derby #14: Convert 41 sites to Argument Clinic across 5 files In-Reply-To: <1389140289.9.0.366061884326.issue20183@psf.upfronthosting.co.za> Message-ID: <1424878163.31.0.278884333106.issue20183@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:29:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:29:32 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1424878172.15.0.59122136576.issue20180@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:29:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:29:41 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1424878181.25.0.36683887702.issue20185@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:29:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:29:51 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1424878191.22.0.266708859706.issue20341@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:30:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:30:01 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1424878201.12.0.63699899901.issue20148@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:30:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:30:09 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default In-Reply-To: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> Message-ID: <1424878209.6.0.421523862794.issue23501@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:30:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:30:19 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1424878219.39.0.304051996201.issue23500@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:30:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:30:28 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1424878228.55.0.56000379667.issue23492@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:31:37 2015 From: report at bugs.python.org (Cyd Haselton) Date: Wed, 25 Feb 2015 15:31:37 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424878297.33.0.865485936888.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Thanks for that suggestion R. David...that would be ideal given the 2.x requirements of Mercurial would mean i'd need to re-port Python before tackling a port of Mercurial. I'll wait until Ryan chimes in before I start serious work with git, just in case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:32:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:32:44 +0000 Subject: [issue21314] Document '/' in signatures In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za> Message-ID: <1424878364.38.0.750505261352.issue21314@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:33:09 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 15:33:09 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424878389.2.0.760496936019.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Victor's motivation for the change was (msg154811): """ I chose this rounding method because it is the method used by int(float) and int(time.time()) is a common in programs (more than round(time.time()). Rounding towards zero avoids also producing timestamps in the future. """ I recall the earlier discussions of rounding in the datetime module and Mark's explanation that rounding up is fine as long as ordering is preserved. i.e. for x < y round(x) <= round(y). There are cases when producing times in the future are problematic, for example UNIX make really dislikes when file timestamps are in the future, but if this was the main motivation - rounding towards -infinity would be more appropriate. In any case, as long as we have the following in the datetime module documentation, I think this behavior is a bug: """ On the POSIX compliant platforms, utcfromtimestamp(timestamp) is equivalent to the following expression: datetime(1970, 1, 1) + timedelta(seconds=timestamp) """ >>> timestamp = 1424817268.274 >>> datetime.utcfromtimestamp(timestamp) == datetime(1970, 1, 1) + timedelta(seconds=timestamp) False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:33:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:33:37 +0000 Subject: [issue20264] Update patchcheck to looks for files with clinic comments In-Reply-To: <1389755559.69.0.925028805372.issue20264@psf.upfronthosting.co.za> Message-ID: <1424878417.73.0.365112253115.issue20264@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:33:56 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 15:33:56 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424878436.65.0.358680396691.issue23517@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 16:35:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 15:35:05 +0000 Subject: [issue23283] Backport Tools/clinic to 3.4 In-Reply-To: <1421785822.4.0.222715524471.issue23283@psf.upfronthosting.co.za> Message-ID: <1424878505.04.0.0690291259444.issue23283@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:04:24 2015 From: report at bugs.python.org (Tim Peters) Date: Wed, 25 Feb 2015 16:04:24 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <1424880264.74.0.822785738613.issue23515@psf.upfronthosting.co.za> Tim Peters added the comment: @Benjamin, bless you for changing their "n-1 > 0" to "n > 1", and for adding parentheses to make the intended grouping obvious instead of a puzzle, and for swapping the addends on the RHS of the new test. Thank you - perfect :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:06:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Feb 2015 16:06:34 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424880394.96.0.064125212034.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: I started a large change set to support nanoseconds in the C "pytime" API: see the issue #22117. While working on this change, I noticed that the rounding mode of datetime is currently wrong. Extract of a private patch: typedef enum { /* Round towards zero. */ _PyTime_ROUND_DOWN=0, /* Round away from zero. For example, used for timeout to wait "at least" N seconds. */ _PyTime_ROUND_UP=1, /* Round towards minus infinity (-inf). For example, used for the system clock with UNIX epoch (time_t). */ _PyTime_ROUND_FLOOR=2 } _PyTime_round_t; I changed Modules/_datetimemodule.c to use _PyTime_ROUND_FLOOR, instead of _PyTime_ROUND_DOWN. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:14:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Feb 2015 16:14:41 +0000 Subject: [issue23511] Broken code example in email module documentation In-Reply-To: <1424790902.68.0.738942973553.issue23511@psf.upfronthosting.co.za> Message-ID: <20150225161436.10168.97651@psf.io> Roundup Robot added the comment: New changeset 89c6a6c2dd1f by Berker Peksag in branch '3.4': Issue #23511: Port email-simple.py to Python 3. https://hg.python.org/cpython/rev/89c6a6c2dd1f New changeset cb911e1fb3dc by Berker Peksag in branch 'default': Issue #23511: Port email-simple.py to Python 3. https://hg.python.org/cpython/rev/cb911e1fb3dc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:16:17 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 16:16:17 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424880977.57.0.600732543729.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > I noticed that the rounding mode of datetime is currently wrong. What do you mean by "currently"? What versions of python have it wrong? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:16:47 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 25 Feb 2015 16:16:47 +0000 Subject: [issue23511] Broken code example in email module documentation In-Reply-To: <1424790902.68.0.738942973553.issue23511@psf.upfronthosting.co.za> Message-ID: <1424881007.34.0.161600636376.issue23511@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Baptiste. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:22:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 16:22:22 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <1424881342.25.0.701774044914.issue23515@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: How additional test affects performance? May be just increase MAX_MERGE_PENDING? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:23:29 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 25 Feb 2015 16:23:29 +0000 Subject: [issue23519] using asyncio.iscoroutinefunction() on a functools.partial object In-Reply-To: <1424862040.11.0.0579325382624.issue23519@psf.upfronthosting.co.za> Message-ID: <1424881409.8.0.751236137821.issue23519@psf.upfronthosting.co.za> Guido van Rossum added the comment: I recall discussing this before (maybe on the tulip list). I am firmly against. It is a slippery slope -- why inspect a partial but not a lambda? Plus there is no use case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:34:00 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 25 Feb 2015 16:34:00 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1424882040.13.0.33895663499.issue20323@psf.upfronthosting.co.za> Steve Dower added the comment: Not sure how helpful this is, but the following code compiles fine for me (VC 12.0 and 14.0): #include char myStr[]; struct { char* a; } myStruct = { myStr }; int main() { printf("%s", myStruct.a); return 0; } static char myStr[] = "123456789"; Any reason you can't define the forward definition like this? (It only seems to work with myStr[] and not *myStr, for some reason.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:36:21 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 25 Feb 2015 16:36:21 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1424882181.81.0.631118860358.issue20323@psf.upfronthosting.co.za> Larry Hastings added the comment: Perhaps, now that Guido allows us to redirect into a separate file, we should simply abandon the two-pass approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:47:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 16:47:35 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1424882855.96.0.665632889708.issue20323@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You forgot "static" in the declaration Steve. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:48:06 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 25 Feb 2015 16:48:06 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1424882181.81.0.631118860358.issue20323@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: That may be for the best. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:48:46 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 16:48:46 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424882926.33.0.512526657044.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Victor, Would you consider going back to round to nearest? Mark and I put in a lot of effort to get the rounding in the datetime module right. (See for example, #8860.) Sub-microsecond timesources are still rare and users who work with such should avoid FP timestamps in any case. On the other hand, double precision timestamps are adequate for microsecond resolution now and in the next few decades. Timestamps like OP's (sec=1424817268, us=274000) should not change when converted to double and back. IMO, the following behavior is a bug. >>> dt = datetime(2015, 2, 24, 22, 34, 28, 274000) >>> datetime.utcfromtimestamp(dt.timestamp()) datetime.datetime(2015, 2, 25, 3, 34, 28, 273999) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:48:50 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 25 Feb 2015 16:48:50 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1424882855.96.0.665632889708.issue20323@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: (My last comment was aimed at Larry's comment about abandoning two-pass...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:51:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 16:51:45 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1424883105.91.0.501608003274.issue20323@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if add "const" in PyDoc_VAR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 17:59:18 2015 From: report at bugs.python.org (James Rutherford) Date: Wed, 25 Feb 2015 16:59:18 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1424883558.36.0.261032802707.issue14721@psf.upfronthosting.co.za> James Rutherford added the comment: The fix for this still doesn't set Content-Length to zero when body is None, but I don't see any reason why this should be the case. For example, the following snippet would work for any 'empty' body: if 'content-length' not in header_names: self._set_content_length(body if body is not None else '') I'm happy to produce a patch if there's any chance it would be merged. ---------- nosy: +jimr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:00:13 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 25 Feb 2015 17:00:13 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1424883613.26.0.689249384811.issue20323@psf.upfronthosting.co.za> Steve Dower added the comment: You need to leave static out of the forward definition and then add it in the initialization. The variable is not accessible from other object files - I checked. "const char[]" and "static const char[]" should work the same, though I haven't tried it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:05:47 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 17:05:47 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py Message-ID: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: >>> import sys >>> sys.modules['_datetime'] = None >>> from datetime import timedelta >>> timedelta(seconds=1)*0.6112295 Traceback (most recent call last): File "", line 1, in File "/Users/a/Work/cpython/Lib/datetime.py", line 519, in __mul__ return self * a / b File "/Users/a/Work/cpython/Lib/datetime.py", line 516, in __mul__ self._microseconds * other) File "/Users/a/Work/cpython/Lib/datetime.py", line 411, in __new__ raise OverflowError("timedelta # of days is too large: %d" % d) OverflowError: timedelta # of days is too large: 63720670102 C implementation is unaffected: >>> from datetime import timedelta >>> timedelta(seconds=1)*0.6112295 datetime.timedelta(0, 0, 611229) ---------- assignee: belopolsky components: Library (Lib) messages: 236602 nosy: belopolsky priority: normal severity: normal stage: needs patch status: open title: OverflowError from timedelta * float in datetime.py type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:07:20 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 17:07:20 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424884040.63.0.118892582592.issue23521@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +bdkearns, benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:09:36 2015 From: report at bugs.python.org (Tim Peters) Date: Wed, 25 Feb 2015 17:09:36 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <1424884176.96.0.541809488226.issue23515@psf.upfronthosting.co.za> Tim Peters added the comment: Since it's impossible to trigger the error on any current machine anyway (no machine has enough memory), increasing the size of the stack would be absurd. If you read the paper, they note that this is what the Java folks first did (they changed this part of timsort in a way that _did_ make it possible to provoke the stack overflow on current hardware). And they got it wrong, not increasing it enough. Without the _intended_ invariant, it's difficult to figure out how much is enough. It's not worth measuring performance. If there are a total of R runs in the input array, a total of R-1 merges will be performed (with or without the change). As explained in listsort.txt, per-merge overheads don't matter at all unless they're outrageous, because there are at most ceiling(len(array)/32) runs. So the total number of merges is a small fraction of the number of array elements (call that `N`), in an N*log(N) process. Adding a few native C integer comparisons per merge (as the change essentially does) is trivial. It may be possible to contrive inputs which run significantly slower (or faster!) with the change, because the order in which runs are merged may change. But then you'd just be chasing patterns of HW and OS layers-of-caching behavior specific to the box the test is running on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:14:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 17:14:55 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <1424884495.69.0.198710200831.issue23515@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your explanation Tim. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:22:28 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 17:22:28 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424884948.98.0.965076108938.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Attached patch fixes the issue, but produces a slightly different result: >>> timedelta(seconds=1)*0.6112295 datetime.timedelta(0, 0, 611230) Note that C implementation is probably buggy: >>> from datetime import * >>> timedelta(seconds=1)*0.6112295 datetime.timedelta(0, 0, 611229) >>> timedelta(seconds=0.6112295) datetime.timedelta(0, 0, 611230) See msg194311 in #8860. ---------- keywords: +patch Added file: http://bugs.python.org/file38234/issue23521.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:23:22 2015 From: report at bugs.python.org (Aaron Meurer) Date: Wed, 25 Feb 2015 17:23:22 +0000 Subject: [issue18199] Windows: support path longer than 260 bytes using "\\?\" prefix In-Reply-To: <1371050681.12.0.381093438517.issue18199@psf.upfronthosting.co.za> Message-ID: <1424885002.75.0.684029167848.issue18199@psf.upfronthosting.co.za> Changes by Aaron Meurer : ---------- nosy: +Aaron.Meurer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:25:02 2015 From: report at bugs.python.org (Vandana Rao) Date: Wed, 25 Feb 2015 17:25:02 +0000 Subject: [issue13077] Unclear behavior of daemon threads on main thread exit In-Reply-To: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za> Message-ID: <1424885102.7.0.858874231768.issue13077@psf.upfronthosting.co.za> Vandana Rao added the comment: Since the program depends on receiving a raw ^C == 0x03 on stdin, it will never be running under Idle because the Idle process tk gui normally keeps control of keyboard input and the Idle process code intercepts ^C and turns it into KeyboardInterrupt raised in the user process. This is not a bug anymore.It is working fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:30:57 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 17:30:57 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424885457.15.0.579549201727.issue23517@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- keywords: +3.3regression -3.2regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:31:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Feb 2015 17:31:56 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424885516.14.0.74068816873.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: > Would you consider going back to round to nearest? I don't understand "nearest". I prefer to use names of decimal rounding modes: https://docs.python.org/dev/library/decimal.html#rounding-modes In my local patch, I'm using ROUND_FLOOR in _decimal: "Round towards -Infinity." > Mark and I put in a lot of effort to get the rounding in the datetime module right. (See for example, #8860.) I'm unable right now to say which rounding mode should be used in the decimal module. But it's important to use the same rounding mode for all similar operations. For example, time.time() and datetime.datetime.now() should have the same rounding method (bad example, time.time() returns a float, which doesn't round the result). For example, in my local patch, I'm using ROUND_FLOOR for: - datetime.date.fromtimestamp() - datetime.datetime.fromtimestamp() - datetime.datetime.now() - datetime.datetime.utcnow() - os.utime() - time.clock_settime() - time.gmtime() - time.localtime() - time.ctime() Note: the Python implementation of datetime uses time.localtime() and time.gmtime() for fromtimestamp(), so these functions should also have the same rounding method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:33:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Feb 2015 17:33:48 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424885628.25.0.60029512262.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: > What do you mean by "currently"? What versions of python have it wrong? I search for "ROUND" in Modules/_datetimemodule.c: in the Python development branch (default), I found _PyTime_ROUND_DOWN (Round towards zero). Since a bug was reported, I understand that it's not the good rounding method? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:38:00 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 17:38:00 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424885880.63.0.592686060646.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > I don't understand "nearest". Sorry for using loose terms. I was hoping the in the context of "going back", it would be clear. I believe the correct mode is "ROUND_HALF_EVEN". This is the mode used by the builtin round() function: >>> round(0.5) 0 >>> round(1.5) 2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 18:57:09 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 17:57:09 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1424887029.92.0.476172755615.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > For example, in my local patch, I'm using ROUND_FLOOR for: > - datetime.date.fromtimestamp() > - datetime.datetime.fromtimestamp() These should use ROUND_HALF_EVEN > - datetime.datetime.now() > - datetime.datetime.utcnow() These should not involve floating point arithmetics, but when converting from nanoseconds to microseconds, you should round to nearest 1000 ns with 500 ns ties resolved to even number of microseconds. > - os.utime() This takes nanoseconds as an optional argument. Passing floats in times should probably be deprecated. In any case, here you would be rounding floats to nanoseconds and what you do with 0.5 nanoseconds is less important because in most cases they are not even representable as floats. > - time.clock_settime() Is this a new method? I don't see it in 3.5.0a1. > - time.gmtime() This should be fixed >>> time.gmtime(1.999999999).tm_sec 1 is really bad and >>> time.gmtime(-1.999999999)[:6] (1969, 12, 31, 23, 59, 59) is probably even worse. > - time.localtime() > - time.ctime() Same story as in time.gmtime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 19:06:59 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Wed, 25 Feb 2015 18:06:59 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424887619.36.0.0705903680194.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: That's what I was saying; I'll update the patches myself. I highly doubt Cyd wants to re-port Python again. :0 I'll ask on python-dev on which would be preferred: configure.ac edits or macro tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 19:40:46 2015 From: report at bugs.python.org (Jake) Date: Wed, 25 Feb 2015 18:40:46 +0000 Subject: [issue23522] Misleading note in Statistics module documentation Message-ID: <1424889646.1.0.160219400081.issue23522@psf.upfronthosting.co.za> New submission from Jake: In the statistics module documentation, there is a note that states that "The mean is strongly affected by outliers and is not a robust estimator for central location: the mean is not necessarily a typical example of the data points. For more robust, although less efficient, measures of central location, see median() and mode()" https://docs.python.org/3/library/statistics.html While I appreciate the intention, this is quite misleading. The implication is that the mean, median and mode are different ways to estimate one "central location", however, in reality they are very different things (albeit which refer to a similar notion). The sample mean is an unbiased estimator of the true mean but it need not be unbiased as an estimator of the true median or modes and vice versa for the median and mode. To make this clearer I would rephrase to "The mean is strongly affected by outliers and is not necessarily representative of the central tendency of the data. For cases with large outliers or very low sample size, see median() and mode()" Apologies if this is seen as frivolous, but statistics can be hard enough to remain very clear about even when the words are used precisely. ---------- assignee: docs at python components: Documentation messages: 236612 nosy: Journeyman08, docs at python priority: normal severity: normal status: open title: Misleading note in Statistics module documentation type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 19:43:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 18:43:06 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424889786.59.0.455518650105.issue23521@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can use self._to_microseconds(). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 20:14:14 2015 From: report at bugs.python.org (SilentGhost) Date: Wed, 25 Feb 2015 19:14:14 +0000 Subject: [issue23522] Misleading note in Statistics module documentation In-Reply-To: <1424889646.1.0.160219400081.issue23522@psf.upfronthosting.co.za> Message-ID: <1424891654.27.0.192955790053.issue23522@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 20:30:45 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 19:30:45 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424892645.31.0.828581185515.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > You can use self._to_microseconds(). Right. Did that and added a simple test. ---------- Added file: http://bugs.python.org/file38235/issue23521-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 20:53:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Feb 2015 19:53:49 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424894029.97.0.980589231348.issue23521@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. But the bug in C implementation should be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 21:27:12 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 25 Feb 2015 20:27:12 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <1424896032.06.0.375429143827.issue23515@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I sent a note to the lead author Stijn de Gouw and mentioned that the repository has moved from svn to hg.python.org. This change may be moot, but I think it worth our effort to keep our code as clean as possible and to encourage automated code checks, as we have by responding to issues raised by Coverity. Maybe next time, this group will find a bug that does matter now. ---------- nosy: +terry.reedy versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 21:30:26 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 25 Feb 2015 20:30:26 +0000 Subject: [issue20703] RuntimeError caused by lazy imports in pdb In-Reply-To: <1392914840.47.0.865855778793.issue20703@psf.upfronthosting.co.za> Message-ID: <1424896226.35.0.810709383957.issue20703@psf.upfronthosting.co.za> Mark Lawrence added the comment: I can reproduce this on Windows 8.1 with 3.4.3 but cannot do so with 3.5.0a1. ---------- nosy: +BreamoreBoy versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 21:33:02 2015 From: report at bugs.python.org (Tim Peters) Date: Wed, 25 Feb 2015 20:33:02 +0000 Subject: [issue23515] Bad logic in timsort's merge_collapse In-Reply-To: <1424806332.96.0.559675082856.issue23515@psf.upfronthosting.co.za> Message-ID: <1424896382.11.0.277333328542.issue23515@psf.upfronthosting.co.za> Tim Peters added the comment: Thanks, Terry! Absolutely agreed: a logical error is an error, and will bite us eventually, regardless of whether it does so today. I'm very glad the researchers went to all the trouble to analyze this one :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 21:52:40 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 25 Feb 2015 20:52:40 +0000 Subject: [issue20683] Add example to tutorial namespace doc, section 9.2 In-Reply-To: <1392798452.78.0.903259935516.issue20683@psf.upfronthosting.co.za> Message-ID: <1424897560.81.0.280781557423.issue20683@psf.upfronthosting.co.za> Mark Lawrence added the comment: What is wrong with the example given here https://docs.python.org/3/tutorial/classes.html#scopes-and-namespaces-example ? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 22:21:43 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 25 Feb 2015 21:21:43 +0000 Subject: [issue20936] test_strftime: enormous allocation, fails under Clang sanitizer In-Reply-To: <1394901902.95.0.363100076763.issue20936@psf.upfronthosting.co.za> Message-ID: <1424899303.73.0.0307269020901.issue20936@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 22:27:33 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 25 Feb 2015 21:27:33 +0000 Subject: [issue7159] Urllib2 authentication memory. In-Reply-To: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za> Message-ID: <1424899653.45.0.401895632837.issue7159@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Senthil what is your opinion of this? ---------- nosy: +BreamoreBoy type: behavior -> resource usage versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 22:38:14 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 25 Feb 2015 21:38:14 +0000 Subject: [issue21201] Uninformative error message in multiprocessing.Manager() In-Reply-To: <1397236820.61.0.692426224091.issue21201@psf.upfronthosting.co.za> Message-ID: <1424900294.77.0.885401503257.issue21201@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can someone review the patch with a view to commit please. It's a change to one line as explained in msg215934. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 22:44:14 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 25 Feb 2015 21:44:14 +0000 Subject: [issue20780] Shadowed (duplicate name but different body) test in test_statistics In-Reply-To: <1393411397.34.0.693108095146.issue20780@psf.upfronthosting.co.za> Message-ID: <1424900654.49.0.0230265991842.issue20780@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Steven would you like to formally review the patch please. At a very quick glance it looks okay to me. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 22:45:52 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 21:45:52 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424900752.01.0.0421189480583.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > the bug in C implementation should be fixed. In the past (see #8860) we were not able to reach a consensus on which behavior is correct and which has a bug: >>> timedelta(seconds=1)*0.6112295 datetime.timedelta(0, 0, 611229) >>> timedelta(seconds=0.6112295) datetime.timedelta(0, 0, 611230) It all boils down to the the fact that >>> round(0.6112295*10**6) 611230 but >>> round(0.6112295, 6) * 10**6 611229.0 In my view, timedelta(seconds=1) is 10**6 microseconds and timedelta(seconds=1) * 0.6112295 is 611229.5 microseconds which is correctly rounded to 611230 in timedelta(seconds=0.6112295), but timedelta(seconds=1)*0.6112295 returning 611229 is incorrect. If I understand Mark's argument correctly (see msg107097), he views timedeltas as fractional number of seconds rather than integer number of microseconds and in his view timedelta(seconds=0.6112295) is timedelta(seconds=0.6112295) is 0.611229499999999981 seconds because >>> Decimal(0.6112295) Decimal('0.61122949999999998116351207499974407255649566650390625') Thus timedelta(seconds=0.6112295), 0.6112295 should be rounded down to 6 decimal places and result in 611229 microseconds. Neither of us thought resolving this was important enough to hold other fixes. In the same spirit, I suggest that we apply my current patch that fixes a crash and pass the rounding curiosity down to the future generations. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 22:46:40 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 25 Feb 2015 21:46:40 +0000 Subject: [issue20780] Shadowed (duplicate name but different body) test in test_statistics In-Reply-To: <1393411397.34.0.693108095146.issue20780@psf.upfronthosting.co.za> Message-ID: <1424900800.56.0.306527860461.issue20780@psf.upfronthosting.co.za> Benjamin Peterson added the comment: The duplicate tests have been renamed already. ---------- nosy: +benjamin.peterson resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 22:55:50 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 25 Feb 2015 21:55:50 +0000 Subject: [issue21293] Remove "capsule hack" from object.c? In-Reply-To: <1397778953.55.0.677894894827.issue21293@psf.upfronthosting.co.za> Message-ID: <1424901350.71.0.0234709131329.issue21293@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've taken a bit of a liberty and picked the names of the last three guys who've worked on this file as I assume they're best qualified to comment. ---------- nosy: +BreamoreBoy, haypo, ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 23:17:32 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 25 Feb 2015 22:17:32 +0000 Subject: [issue23516] pip: urllib3 does not encode userinfo section of requests: parse_url() mishandles special characters when the URL specifies authentication credentials In-Reply-To: <1424815080.16.0.743473330916.issue23516@psf.upfronthosting.co.za> Message-ID: <1424902652.52.0.381069125536.issue23516@psf.upfronthosting.co.za> Demian Brecht added the comment: FWIW, setting up a local authenticated (ncsa_auth) squid proxy, this breaks using pip 0.6.8: pip --proxy http://special:my?password at localhost:3128 install While the percent-encoded version is successful: pip --proxy http://special:my%3Fpassword at localhost:3128 install It's odd that you would encounter the same error with an encoded password. It might be helpful if you could supply an example of the full proxy URL you're experiencing the problem with when using an encoded password. It seems to me that it is functioning as expected based on the RFC, but could definitely use some better detection and error reporting around malformed URLs (as Senthil mentions in #23328). I'm setting the status of this issue to pending (assuming it will be closed as a fix for this would be done outside of the standard library) until someone with more expertise with pip takes a look. ---------- components: +Demos and Tools -Extension Modules status: open -> pending title: requests: parse_url() mishandles special characters when the URL specifies authentication credentials -> pip: urllib3 does not encode userinfo section of requests: parse_url() mishandles special characters when the URL specifies authentication credentials _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 25 23:52:04 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 22:52:04 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424904724.95.0.735953056215.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I eliminated floating point arithmetics from the calculation completely and it now matches C. ---------- Added file: http://bugs.python.org/file38236/issue23521-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 00:18:17 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 25 Feb 2015 23:18:17 +0000 Subject: [issue23516] pip: urllib3 does not encode userinfo section of URL with authentication credentials In-Reply-To: <1424815080.16.0.743473330916.issue23516@psf.upfronthosting.co.za> Message-ID: <1424906297.47.0.114384367456.issue23516@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- status: pending -> open title: pip: urllib3 does not encode userinfo section of requests: parse_url() mishandles special characters when the URL specifies authentication credentials -> pip: urllib3 does not encode userinfo section of URL with authentication credentials _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 00:18:53 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Feb 2015 23:18:53 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424906333.45.0.357350404859.issue23521@psf.upfronthosting.co.za> Brian Kearns added the comment: Maybe we should also use divide_and_round for __truediv__ to match the C implementation calling divide_nearest there as well? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 00:29:55 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 23:29:55 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424906995.54.0.774410294275.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Maybe we should also use divide_and_round for __truediv__ You mean in timedelta / float case, right? You are probably right, but can you provide a test case in which it matters? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 00:34:36 2015 From: report at bugs.python.org (Brian Kearns) Date: Wed, 25 Feb 2015 23:34:36 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424907276.76.0.833332442861.issue23521@psf.upfronthosting.co.za> Brian Kearns added the comment: td = timedelta(seconds=1) print(td / (1/0.6112295)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 00:55:07 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 23:55:07 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424908507.61.0.658506594862.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: >>> td = timedelta(seconds=1) >>> print(td / (1/0.6112295)) 0:00:00.611229 What is wrong with this answer? It is the same as in >>> print(td * 0.6112295) 0:00:00.611229 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 00:56:48 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 25 Feb 2015 23:56:48 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424908608.54.0.453155555188.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I've got it: >>> import sys >>> sys.modules['_datetime'] = None >>> from datetime import * >>> td = timedelta(seconds=1) >>> print(td / (1/0.6112295)) 0:00:00.611230 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 01:00:20 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 26 Feb 2015 00:00:20 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424908820.08.0.678719248224.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Fixed truediv in issue23521-4.patch. ---------- Added file: http://bugs.python.org/file38237/issue23521-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 01:14:43 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 26 Feb 2015 00:14:43 +0000 Subject: [issue20703] RuntimeError caused by lazy imports in pdb In-Reply-To: <1392914840.47.0.865855778793.issue20703@psf.upfronthosting.co.za> Message-ID: <1424909683.72.0.0298213142265.issue20703@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Is this worth fixing? Delve into the innards and you get weird behaviors. If you really need to iterate sys.modules (the example clearly doesn't, but that doesn't mean no one would), you could just copy the parts you need beforehand to get a consistent view, e.g. for name, mod in tuple(sys.modules.items()): Lazy module imports aren't always a bad thing if the module in question isn't needed for the common functionality, only specific subsets that may never be used. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 01:21:16 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 26 Feb 2015 00:21:16 +0000 Subject: [issue20936] test_strftime: enormous allocation, fails under Clang sanitizer In-Reply-To: <1394901902.95.0.363100076763.issue20936@psf.upfronthosting.co.za> Message-ID: <1424910076.54.0.500152432658.issue20936@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Can someone provide instructions for compiling python with AddressSanitizer? My naive attempt to run ./configure CC="clang -fsanitize=address" did not work. ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 01:23:35 2015 From: report at bugs.python.org (=?utf-8?b?5aSP54aZ5Li0?=) Date: Thu, 26 Feb 2015 00:23:35 +0000 Subject: [issue23523] cmath.atanh has wrong output Message-ID: <1424910215.48.0.703419414911.issue23523@psf.upfronthosting.co.za> New submission from ???: When I was using cmath.atanh, I found that this function generates wrong output. For example: >>> import cmath >>> cmath.atanh(-1.89) (-0.5888951591901462+1.5707963267948966j) However, the correct output should be: (-0.5888951591901462-1.5707963267948966j) Clearly, the sign of the imaginary part is wrong. ---------- components: Library (Lib) messages: 236636 nosy: ??? priority: normal severity: normal status: open title: cmath.atanh has wrong output type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 01:31:05 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 26 Feb 2015 00:31:05 +0000 Subject: [issue23523] cmath.atanh has wrong output In-Reply-To: <1424910215.48.0.703419414911.issue23523@psf.upfronthosting.co.za> Message-ID: <1424910665.91.0.871574430494.issue23523@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, mark.dickinson, rhettinger, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 01:39:47 2015 From: report at bugs.python.org (Jeffrey Walton) Date: Thu, 26 Feb 2015 00:39:47 +0000 Subject: [issue20936] test_strftime: enormous allocation, fails under Clang sanitizer In-Reply-To: <1424910076.54.0.500152432658.issue20936@psf.upfronthosting.co.za> Message-ID: Jeffrey Walton added the comment: On Wed, Feb 25, 2015 at 7:21 PM, Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > Can someone provide instructions for compiling python with AddressSanitizer? My naive attempt to run ./configure CC="clang -fsanitize=address" did not work. > This may help: "Dynamic Analysis with Clang", https://docs.python.org/devguide/clang.html. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 01:56:41 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 26 Feb 2015 00:56:41 +0000 Subject: [issue6549] ttk.Style -- minor issues with element_names and configure In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za> Message-ID: <1424912201.11.0.127175410763.issue6549@psf.upfronthosting.co.za> Ethan Furman added the comment: Redid patch against current branch, fixing the typos I had in them. Any reason not to move forward? ---------- nosy: +serhiy.storchaka Added file: http://bugs.python.org/file38238/issue6549.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 02:14:58 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 26 Feb 2015 01:14:58 +0000 Subject: [issue23254] Document how to close the TCPServer listening socket In-Reply-To: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za> Message-ID: <1424913298.08.0.637430242801.issue23254@psf.upfronthosting.co.za> Demian Brecht added the comment: Left a couple small nitpicks in Rietveld. Otherwise LGTM. ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 02:33:52 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 26 Feb 2015 01:33:52 +0000 Subject: [issue23387] test_urllib2 fails with HTTP Error 502: Bad Gateway In-Reply-To: <1422961904.97.0.978548371135.issue23387@psf.upfronthosting.co.za> Message-ID: <1424914432.67.0.498731360377.issue23387@psf.upfronthosting.co.za> Demian Brecht added the comment: LGTM ---------- nosy: +demian.brecht stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 02:42:50 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 26 Feb 2015 01:42:50 +0000 Subject: [issue20408] memoryview() constructor documentation error In-Reply-To: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za> Message-ID: <1424914970.12.0.340311414641.issue20408@psf.upfronthosting.co.za> Mark Lawrence added the comment: I think it's plain daft having "object" as a keyword argument. Is it too late to do anything about this, or could we go through a deprecation period, or what? ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 03:19:06 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 26 Feb 2015 02:19:06 +0000 Subject: [issue21889] https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions doesn't explain exception In-Reply-To: <1404165638.91.0.279596288902.issue21889@psf.upfronthosting.co.za> Message-ID: <1424917145.99.0.112346506205.issue21889@psf.upfronthosting.co.za> Mark Lawrence added the comment: What is "exception multiprocessing.BufferTooShort" at the bottom of the referenced section? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 03:31:57 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 26 Feb 2015 02:31:57 +0000 Subject: [issue23382] Maybe can not shutdown ThreadPoolExecutor when call the method of shutdown In-Reply-To: <1422951603.17.0.63584283635.issue23382@psf.upfronthosting.co.za> Message-ID: <1424917917.19.0.17335728328.issue23382@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Miles could you provide the code changes as a unified diff file, and if needed any changes to the test code as well, thanks. ---------- components: +Library (Lib) -2to3 (2.x to 3.x conversion tool) nosy: +BreamoreBoy type: -> behavior versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 05:55:26 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 26 Feb 2015 04:55:26 +0000 Subject: [issue18382] multiprocessing's overlapped PipeConnection issues on Windows 8 In-Reply-To: <1373114737.55.0.0779572840335.issue18382@psf.upfronthosting.co.za> Message-ID: <1424926526.83.0.891164556851.issue18382@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks Davin. I got onto a Windows 8 machine and confirmed the behaviour changed there, so the version check in my patch is correct. Anyone opposed to the extra logic and version check? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 06:01:46 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 26 Feb 2015 05:01:46 +0000 Subject: [issue23451] Deprecation warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423697646.35.0.470486317043.issue23451@psf.upfronthosting.co.za> Message-ID: <1424926906.85.0.804142643089.issue23451@psf.upfronthosting.co.za> Steve Dower added the comment: Anyone got a chance to double-check my patch for me? I think it's fine, unless someone really wants me to turn all the "#ifdef CMSG_LEN" checks into "#ifdef HAVE_CMSG" (which I *think* would require autoconf updates, which I am totally unqualified to do...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 06:17:04 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 26 Feb 2015 05:17:04 +0000 Subject: [issue23523] cmath.atanh has wrong output In-Reply-To: <1424910215.48.0.703419414911.issue23523@psf.upfronthosting.co.za> Message-ID: <1424927824.16.0.282525345091.issue23523@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Both are correct, since atanh requires a branch cut. ---------- nosy: +benjamin.peterson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 06:35:49 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 26 Feb 2015 05:35:49 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424928949.32.0.196501046538.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Martin, I'll try to review your GzipFile patch. But maybe it would make sense to open a separate issue for this? I think the LZMAFile patch has not yet been reviewed or committed, and we probably want a patch for BZ2File too. The review page is already pretty cluttered right now, so I think it would make sense to use this issue for the low-level compressor/decompressor API and handle the *File API separately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 06:54:17 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 26 Feb 2015 05:54:17 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule Message-ID: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> New submission from Steve Dower: (Now that VS 2015 CTP 6 is public, here's the second half of #23314.) In posixmodule.c is a big section with the following comment: /* Microsoft CRT in VS2005 and higher will verify that a filehandle is * valid and raise an assertion if it isn't. * Normally, an invalid fd is likely to be a C program error and therefore * an assertion can be useful, but it does contradict the POSIX standard * which for write(2) states: * "Otherwise, -1 shall be returned and errno set to indicate the error." * "[EBADF] The fildes argument is not a valid file descriptor open for * writing." ... * The structures below must be updated for each version of visual studio * according to the file internal.h in the CRT source, until MS comes * up with a less hacky way to do this. * (all of this is to avoid globally modifying the CRT behaviour using * _set_invalid_parameter_handler() and _CrtSetReportMode()) */ We now have the less hacky way to avoid globally modifying the IPH, which is a new _set_thread_local_invalid_parameter_handler() function. (#23314 has hopefully already dealt with _CrtSetReportMode().) The attached patch adds new macros within posixmodule.c to handle VS 2015 builds and use the new function. I have left the old code there as a transitional measure while people migrate to the new compiler, but also have no plans to remove it. The new macros _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH should surround any code that may trigger the invalid parameter handler. The _Py_VERIFY_FD macro calls the _PyVerify_fd function when necessary - when the IPH can be suppressed, this should be a no-op, and when the IPH cannot be suppressed it must be a useful/safe check. The _PyVerify_fd function remains defined in all cases, but when it's possible to safely call into the CRT to validate the handle we now do that instead of the old approach. The only visible change should be that in debug builds you will see assertion dialogs if an invalid FD is encountered, which can be safely ignored. The test suite disables these dialogs already, so buildbots should be unaffected. Prior discussions (#3545 and #4804) have decided that it's important to leave these dialogs enabled for debug builds, and there is no way (and won't be any way) to disable these on a per-thread basis. ---------- assignee: steve.dower components: Windows keywords: patch messages: 236648 nosy: haypo, steve.dower, tim.golden, zach.ware priority: high severity: normal stage: patch review status: open title: Use _set_thread_local_invalid_parameter_handler in posixmodule type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 06:55:50 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 26 Feb 2015 05:55:50 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1424930150.92.0.815328570295.issue23524@psf.upfronthosting.co.za> Changes by Steve Dower : Added file: http://bugs.python.org/file38239/23524_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 07:03:25 2015 From: report at bugs.python.org (Andrew Barnert) Date: Thu, 26 Feb 2015 06:03:25 +0000 Subject: [issue23525] isbuiltin, isroutine, etc. Message-ID: <1424930605.81.0.317229186778.issue23525@psf.upfronthosting.co.za> New submission from Andrew Barnert: The documentation and implementation for `inspect.isbuiltin` and related functions do not match. While #4968 attempted to clarify things to make the documentation match the behavior, the actual committed changes are still wrong. `isbuiltin` says "Return true if the object is a built-in function or a bound built-in method", but it returns false for bound built-in special methods (e.g., `[].__add__`). That's because it's implemented as `isinstance(types.BuiltinFunctionType)`, but bound special methods are a different type (`method-wrapper`). Terry Reedy's suggested fix from #4968 ("... or a bound built-in non-special method") would fix this, but the committed change didn't. The docstring has a further problem; it says that anything that passes will have a `__self__` with "instance to which a method is bound, or None", but for functions, the `__self__` is usually the module the `PyMethodDef` comes from, not `None`. (For example, `sum.__self__` is the`'builtins` module.) `isroutine` says "Return true if the object is a user-defined or built-in function or method." (The docstring instead says "? any kind of function or method.") But it returns false for built-in bound special methods (`[].__add__`). That's because it's implemented as `isbuiltin` or `isfunction` or `ismethod` or `ismethoddescriptor`; while `isbuiltin` picks up functions and bound non-special methods, and `ismethoddescriptor` picks up unbound special and non-special methods, nothing picks up bound special methods. A doc-only fix for this, along with Terry's suggested fix for `isbuiltin`, would be "Return true if the object is a user-defined function or method, or a built-in function, unbound method, or bound non-special method." That sounds horrible, but that's because it actually is a horrible test in the first place. A better fix would be to make `isbuiltin` handle both kinds of bound method. Then `isroutine` is correct as written, and both are documented correctly. (Note that there is no type in `types` corresponding to `method-wrapper`, so either `types` or `inspect` would have to add something like `BuiltinSpecialMethodType = type([].__add__)`.) It would be even better to fix this at the source and clean up the types of builtin functions and methods, but that boat sailed with 3.0, so... ---------- assignee: docs at python components: Documentation messages: 236649 nosy: abarnert, docs at python priority: normal severity: normal status: open title: isbuiltin, isroutine, etc. versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 07:13:36 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 26 Feb 2015 06:13:36 +0000 Subject: [issue23510] multiprocessing bug SyncManager and 'with' In-Reply-To: <1424784474.12.0.228863603483.issue23510@psf.upfronthosting.co.za> Message-ID: <1424931216.43.0.393202238261.issue23510@psf.upfronthosting.co.za> Davin Potts added the comment: I have a working patch that addresses this behavior and tests to go along with it but am still working on updating the docs. Updating the docs in 2.7 in a way to as closely match the docs in 3.4/3.5 as possible seems reasonable. It remains unclear why __enter__ and __exit__ were added in 2.7 yet never advertised in the docs -- attempting to dig into that further. My intention is to complete the patch (with mods to the docs) this weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 08:20:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 07:20:18 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424935218.95.0.630023444387.issue23521@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added comments on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 08:35:36 2015 From: report at bugs.python.org (Alex Shkop) Date: Thu, 26 Feb 2015 07:35:36 +0000 Subject: [issue23526] Silence resource warnings in test_httplib Message-ID: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za> New submission from Alex Shkop: Three resource warnings are present in test_httplib. Patch closes HTTPSConnection in test_networked_noverification, test_networked_trusted_by_default_cert, test_networked_good_cert. ---------- components: Tests files: test_httplib_warnings.patch keywords: patch messages: 236652 nosy: ashkop priority: normal severity: normal status: open title: Silence resource warnings in test_httplib versions: Python 3.5 Added file: http://bugs.python.org/file38240/test_httplib_warnings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 08:44:20 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 26 Feb 2015 07:44:20 +0000 Subject: [issue20408] memoryview() constructor documentation error In-Reply-To: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za> Message-ID: <1424936660.09.0.081407403617.issue20408@psf.upfronthosting.co.za> Demian Brecht added the comment: > Oddly, memoryview accepts keyword arguments (for its one required value), and the name of the argument is "object", not "obj". Positional parameters can also be treated as named arguments. > I think it's plain daft having "object" as a keyword argument. True, it's not best practice to override builtins with parameter names. In this case because memoryview is implemented in C, it doesn't suffer the same consequences as a Python implementation can. However at the very least, I do agree that it does seem a little odd from a user's standpoint. Also, the docs currently use "obj" rather than "object": https://docs.python.org/3/library/stdtypes.html#memoryview. I've attached a patch that just changes the name of the parameter. Scanning through Github (primarily numpy and scipy), I wasn't able to find anyone making use of the parameter name. As this does break backwards compatibility and is more of a cosmetic enhancement than a bug, it should only go into 3.5+. The other option here, other than to just leave it as is, is to simply use Py_ParseTuple rather than PyArg_ParseTupleAndKeywords, but I'm not sure what the general consensus is on that (it seems to me that the preferred approach is the latter). ---------- components: +Interpreter Core keywords: +patch nosy: +demian.brecht stage: needs patch -> patch review versions: -Python 3.4 Added file: http://bugs.python.org/file38241/issue20408.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 09:17:08 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 26 Feb 2015 08:17:08 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1424938628.74.0.453500273419.issue23509@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 09:20:06 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 26 Feb 2015 08:20:06 +0000 Subject: [issue9985] difflib.SequenceMatcher has slightly buggy and undocumented caching behavior In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za> Message-ID: <1424938806.48.0.784312177608.issue9985@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 09:50:57 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 26 Feb 2015 08:50:57 +0000 Subject: [issue23507] Tuple creation is too slow In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> Message-ID: <1424940657.21.0.432229796803.issue23507@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I had done something like this for zip() long ago and had gotten a nice speed boost. I remember looking at whether it should be applied elsewhere but don't remember why I decided against it. ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 09:53:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 08:53:28 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1424940808.32.0.890154108706.issue23509@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Applied optimizations: 1) Used cached get() method instead of indexing. This optimization already was used in update() and subtract(). 2) _keep_positive() is optimized for the case when most counts are not positive (common case for substraction and intersection). 3) __add__ and __or__ are defined via inplace operations which are faster (due to fast copying and _keep_positive()). 4) Inlined and simplified the code for __pos__ and __neg__. May be following optimization can be made by implementing _keep_positive() in C. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 09:58:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 08:58:26 +0000 Subject: [issue23507] Tuple creation is too slow In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> Message-ID: <1424941106.39.0.308979597145.issue23507@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note the check for Py_REFCNT() == 1. Whithout it the code would be incorrect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 10:44:57 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Feb 2015 09:44:57 +0000 Subject: [issue23526] Silence resource warnings in test_httplib In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za> Message-ID: <1424943897.85.0.594800754632.issue23526@psf.upfronthosting.co.za> Martin Panter added the comment: +1 from me. These three fixes are practically the same as the ones I snuck into my patch for a Issue 23377. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 11:01:36 2015 From: report at bugs.python.org (Alex Shkop) Date: Thu, 26 Feb 2015 10:01:36 +0000 Subject: [issue23527] test_smtpnet uses incorrect port for STARTTLS Message-ID: <1424944896.48.0.616589540337.issue23527@psf.upfronthosting.co.za> New submission from Alex Shkop: test_smtpnet uses port 25 for STARTTLS, whereas gmail exposes STARTTLS SMTP over port 587. ---------- components: Tests files: test_smtpnet_starttls_port.patch keywords: patch messages: 236658 nosy: ashkop priority: normal severity: normal status: open title: test_smtpnet uses incorrect port for STARTTLS versions: Python 3.5 Added file: http://bugs.python.org/file38242/test_smtpnet_starttls_port.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 11:22:07 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Feb 2015 10:22:07 +0000 Subject: [issue23528] Limit decompressed data when reading from GzipFile Message-ID: <1424946126.98.0.486244279604.issue23528@psf.upfronthosting.co.za> New submission from Martin Panter: This is a patch I originally posted at Issue 15955, but am moving it to a separate issue so there is less confusion. GzipFile.read() etc is susceptible to decompression bombing. My patch tests and fixes that, making use of the existing ?max_length? parameter in the ?zlib? module. The rest of Issue 15955 is about enhancing the bzip and LZMA modules to support limited decompression, but since the zlib module can already limit the decompressed data, I think this gzip patch should be considered as a bug fix rather than enhancement, e.g. the fix for Issue 16043 (gzip decoding for XML RPC module) assumed GzipFile.read() is limited. ---------- components: Library (Lib) files: gzip-bomb.patch keywords: patch messages: 236659 nosy: nikratio, vadmium priority: normal severity: normal status: open title: Limit decompressed data when reading from GzipFile type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38243/gzip-bomb.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 11:23:24 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Feb 2015 10:23:24 +0000 Subject: [issue23528] Limit decompressed data when reading from GzipFile In-Reply-To: <1424946126.98.0.486244279604.issue23528@psf.upfronthosting.co.za> Message-ID: <1424946204.74.0.355197546169.issue23528@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- type: behavior -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 11:37:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 26 Feb 2015 10:37:39 +0000 Subject: [issue23519] using asyncio.iscoroutinefunction() on a functools.partial object In-Reply-To: <1424862040.11.0.0579325382624.issue23519@psf.upfronthosting.co.za> Message-ID: <1424947059.82.0.112497039947.issue23519@psf.upfronthosting.co.za> STINNER Victor added the comment: > Plus there is no use case. Mathieu: can you maybe give some examples? How are you using functools.partial with coroutines? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 11:44:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 10:44:08 +0000 Subject: [issue23507] Tuple creation is too slow In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> Message-ID: <1424947448.93.0.227650765845.issue23507@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed bugs found by Victor. Thank you Victor. Yes, zip() already uses similar approach. ---------- Added file: http://bugs.python.org/file38244/reuse_argtuples_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 12:03:06 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 26 Feb 2015 11:03:06 +0000 Subject: [issue20703] RuntimeError caused by lazy imports in pdb In-Reply-To: <1392914840.47.0.865855778793.issue20703@psf.upfronthosting.co.za> Message-ID: <1424948586.8.0.089699828911.issue20703@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I can reproduce this on Windows 8.1 with 3.4.3 but cannot do so with 3.5.0a1. I can still reproduce this on linux on today's tip: '3.5.0a1+ (default:7185a35fb293, Feb 26 2015, 11:27:11) \n[GCC 4.9.2 20150204 (prerelease)]'. Maybe you tried reproducing it with the interactive interpreter. When this code is run from the interactive interpreter and not as a script as suggested in the initial post, then readline is already imported by the interpreter at startup and the RuntimeError is not raised. Also interestingly, the bdb module takes lot of steps to ensure that linecache and reprlib are lazyly imported, but pdb and bdb cannot do anything interesting without these modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 12:06:26 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Feb 2015 11:06:26 +0000 Subject: [issue23529] Limit decompressed data when reading from LZMAFile and BZ2File Message-ID: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za> New submission from Martin Panter: This is a follow-on from Issue 15955, which has added low-level support for limiting the amount of data from the LZMA and bzip decompressors. The high-level LZMAFile and BZ2File reader APIs need to make use of the new low level max_length parameter. I am starting off with a patch for LZMAFile, based on a patch I posted to Issue 15955. I split out a _RawReader class that does the actual decompress() calls, and then wrapped that in a BufferedReader. The LZMAFile then just delegates the read methods to the BufferedReader. This avoids needing any special code to implement buffering, readline(), etc. This involved some changes in the API though: * LZMAFile now uses BufferedReader.peek(). The current implementation seems appropriate, but I am not comfortable with the current specification in the documentation, which says it is allowed to not return any useful data. See Issue 5811. * read() now accepts size=None, because BufferedReader does. I had to change a test case for this. * BufferedReader.seek() raises a different exception for invalid ?whence? Once the LZMAFile patch sees a bit of review and looks like it might be acceptable, I plan to change the BZ2File class in a similar manner. ---------- components: Library (Lib) files: LZMAFile.v2.patch keywords: patch messages: 236663 nosy: nikratio, vadmium priority: normal severity: normal status: open title: Limit decompressed data when reading from LZMAFile and BZ2File type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38245/LZMAFile.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 12:11:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 11:11:39 +0000 Subject: [issue23528] Limit decompressed data when reading from GzipFile In-Reply-To: <1424946126.98.0.486244279604.issue23528@psf.upfronthosting.co.za> Message-ID: <1424949099.58.0.46394595813.issue23528@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 12:11:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 11:11:48 +0000 Subject: [issue23529] Limit decompressed data when reading from LZMAFile and BZ2File In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za> Message-ID: <1424949108.82.0.671363990588.issue23529@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 12:12:33 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Feb 2015 11:12:33 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424949153.2.0.328098613992.issue15955@psf.upfronthosting.co.za> Martin Panter added the comment: Yes I think that is a good idea: * Moved gzip-bomb.patch to Issue 23528 * Opened Issue 23529 with a new version of the LZMAFile patch, and plan to post a BZ2File patch there as well when it is ready ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 13:09:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Feb 2015 12:09:58 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <20150226120954.10186.39201@psf.io> Roundup Robot added the comment: New changeset 10dab1b596d4 by Antoine Pitrou in branch 'default': Issue #15955: Add an option to limit the output size in bz2.decompress(). https://hg.python.org/cpython/rev/10dab1b596d4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 13:12:10 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Feb 2015 12:12:10 +0000 Subject: [issue15955] bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1424952730.4.0.92421182373.issue15955@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you, Nikolaus, and thank you Martin for the reviews. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed title: gzip, bz2, lzma: add option to limit output size -> bz2, lzma: add option to limit output size _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 13:12:20 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Feb 2015 12:12:20 +0000 Subject: [issue23528] Limit decompressed data when reading from GzipFile In-Reply-To: <1424946126.98.0.486244279604.issue23528@psf.upfronthosting.co.za> Message-ID: <1424952740.95.0.354611004532.issue23528@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 13:45:07 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 26 Feb 2015 12:45:07 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424954707.29.0.328331321545.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Thanks Ryan. Should I create a branch off the master at github and patch there or just clone the master and patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 14:00:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 13:00:33 +0000 Subject: [issue1539925] warnings in interactive sessions Message-ID: <1424955633.52.0.97309616601.issue1539925@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 14:26:20 2015 From: report at bugs.python.org (Mathieu Pasquet) Date: Thu, 26 Feb 2015 13:26:20 +0000 Subject: [issue23519] using asyncio.iscoroutinefunction() on a functools.partial object In-Reply-To: <1424862040.11.0.0579325382624.issue23519@psf.upfronthosting.co.za> Message-ID: <1424957180.08.0.246914563809.issue23519@psf.upfronthosting.co.za> Mathieu Pasquet added the comment: Using functools.partial with coroutines would be mostly out of convenience, in order to avoid having factories in that return parametrized coroutine functions. I guess in such cases it might be better to create a two-lines wrapper around partial() to make it return a coroutine rather than change the stdlib for that. In the attached file is an example of such use, where EventNotifier is a Protocol which receives external events and triggers event handlers based on that, and where the add_event_handler function checks if the handler is a coroutine function. In which case it uses asyncio.async to schedule the handler call; otherwise it uses loop.call_soon. You can close this, I guess. ---------- Added file: http://bugs.python.org/file38246/example_partial.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 14:56:18 2015 From: report at bugs.python.org (Daniel Holth) Date: Thu, 26 Feb 2015 13:56:18 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424806480.83.0.90699061701.issue23491@psf.upfronthosting.co.za> Message-ID: <1424958975.4034075.232763833.57CB3952@webmail.messagingengine.com> Daniel Holth added the comment: Create and open executable file respecting the Unix user's umask: os.fdopen(os.open(filename, os.O_CREAT|os.O_RDWR), "rw") On Tue, Feb 24, 2015, at 02:34 PM, Paul Moore wrote: > > Paul Moore added the comment: > > Thanks, I'll fix for the next iteration of the patch. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 15:18:30 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 14:18:30 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424960310.04.0.312865697026.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: I don't follow (and I don't really want to do things this low level without a compelling reason...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 15:30:54 2015 From: report at bugs.python.org (Julian Taylor) Date: Thu, 26 Feb 2015 14:30:54 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity Message-ID: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> New submission from Julian Taylor: multiprocessing.cpu_count and os.cpu_count which are often used to determine how many processes one can run in parallel do not respect the cpuset which may limit the process to only a subset of online cpus leading to heavy oversubscription in e.g. containerized environments: $ taskset -c 0 python3.4 -c 'import multiprocessing; print(multiprocessing.cpu_count())' 32 $ taskset -c 0 python3.4 -c 'import os; print(os.cpu_count())' 32 While the correct result here should be 1. This requires programs to have to use less portable methods like forking to gnu nproc or having to read the /proc filesystem. Having a keyword argument to switch between online and available cpus would be fine too. ---------- components: Library (Lib) messages: 236671 nosy: jtaylor priority: normal severity: normal status: open versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 15:40:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 14:40:30 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1424961630.96.0.354469123969.issue23530@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 15:41:15 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 14:41:15 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424961675.39.0.53585742167.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: Following on from that, the code to make an archive executable is currently os.chmod(new_archive, os.stat(new_archive).st_mode | stat.S_IEXEC) Should I use "... | stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH"? If so, do I need to protect that with an "if not Windows" test? (I've tested the existing code and it does nothing on Windows, so I omitted the test at the moment). Is there any *other* way I should be making a file executable on Unix? (Side note: Maybe there should be an os.make_executable(pathname) or similar that does the right thing in a cross-platform way?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 16:18:11 2015 From: report at bugs.python.org (Jim Jewett) Date: Thu, 26 Feb 2015 15:18:11 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424963891.54.0.396739046209.issue23491@psf.upfronthosting.co.za> Jim Jewett added the comment: I think that instead of application/zip, you want application/zipped-python (or whatever the precise term was). This was one reason to register the MIME type. That said, application/zip is probably not harmful; the worst it should do it hand the archive to a zip program. What is pxzw for, other than amusing mispronunciations? ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 16:21:08 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 26 Feb 2015 15:21:08 +0000 Subject: [issue20703] RuntimeError caused by lazy imports in pdb In-Reply-To: <1392914840.47.0.865855778793.issue20703@psf.upfronthosting.co.za> Message-ID: <1424964068.2.0.955321882379.issue20703@psf.upfronthosting.co.za> Mark Lawrence added the comment: My tests were done with a script from the command line, not an interactive prompt. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 16:29:10 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 26 Feb 2015 15:29:10 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424964550.84.0.757709804314.issue23491@psf.upfronthosting.co.za> Steve Dower added the comment: The .px* extensions are for testing builds without messing up your actual file associations. I ported them forward from the old installer, but most people will never see them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 16:30:58 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 15:30:58 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424964658.3.0.681336550118.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: If I understand Steve's comments, the mime type is used by Windows, so application/zip lets Windows know that this filetype is fundamentally a zip file (and so it'll offer to open it with your zip program if you right click, stuff like that). pxzw - the "w" on the end marks it as a GUI script, to be run by pythonw.exe. The x is a "test mode" thing for development builds of Python. You wouldn't see it in a production build (the production filetypes are pyz and pyzw). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 16:31:07 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 26 Feb 2015 15:31:07 +0000 Subject: [issue20703] RuntimeError caused by lazy imports in pdb In-Reply-To: <1392914840.47.0.865855778793.issue20703@psf.upfronthosting.co.za> Message-ID: <1424964667.85.0.354615166816.issue20703@psf.upfronthosting.co.za> Eric Snow added the comment: I haven't looked to closely but I'm guessing that pdb.set_trace() causes something to get imported (i.e. there's an import statement in a function body somewhere). Consequently sys.modules is updated (by that "distant" import statement) while you are iterating over it here. In that case the behavior you are seeing is correct, even if not obvious or even desirable. It will happen any time you are looping over sys.modules and call a function/method which has a function-scoped import statement for a module that hasn't been imported yet (or calls another function that does so, etc.). ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 16:37:44 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 26 Feb 2015 15:37:44 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424965064.44.0.313188058125.issue23491@psf.upfronthosting.co.za> Steve Dower added the comment: There's also a PerceivedType property which we could set to make sure that archivers correctly light up. I think that'll get you the built-in Extract command. Most tools appear on every file and will try and read it to see what commands make sense, which will work fine for a zip file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 16:40:52 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 26 Feb 2015 15:40:52 +0000 Subject: [issue23526] Silence resource warnings in test_httplib In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za> Message-ID: <1424965252.5.0.808249753564.issue23526@psf.upfronthosting.co.za> Demian Brecht added the comment: LGTM ---------- nosy: +demian.brecht stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 16:41:09 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 26 Feb 2015 15:41:09 +0000 Subject: [issue23526] Silence resource warnings in test_httplib In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za> Message-ID: <1424965269.28.0.431748364928.issue23526@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 16:57:08 2015 From: report at bugs.python.org (Daniel Holth) Date: Thu, 26 Feb 2015 15:57:08 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424961675.39.0.53585742167.issue23491@psf.upfronthosting.co.za> Message-ID: <1424966226.4058937.232822773.08BFF1DF@webmail.messagingengine.com> Daniel Holth added the comment: On Thu, Feb 26, 2015, at 09:41 AM, Paul Moore wrote: > > Paul Moore added the comment: > > Following on from that, the code to make an archive executable is > currently > > os.chmod(new_archive, os.stat(new_archive).st_mode | stat.S_IEXEC) > > Should I use "... | stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH"? If so, > do I need to protect that with an "if not Windows" test? (I've tested the > existing code and it does nothing on Windows, so I omitted the test at > the moment). Is there any *other* way I should be making a file > executable on Unix? > > (Side note: Maybe there should be an os.make_executable(pathname) or > similar that does the right thing in a cross-platform way?) The chmod + umask analog that will work not just on a newly created file is umask = os.umask(0) # must change umask to get umask os.umask(umask) # restore previous umask os.chmod(new_archive, os.stat(new_archive).st_mode | ((stat.stat.S_IXUSR|stat.S_IXGRP|stat.S_IXOTH) & ~umask)) If I understand the man page correctly, "chmod +x filename" does exactly the above. Depending on the umask the command may or may not create a world / group / user executable file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 17:16:54 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 26 Feb 2015 16:16:54 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424967414.51.0.349174610603.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I addressed review comments and fixed the case of negative divisor. There may be a better solution than calling the function recursively, but I wanted an easy to understand code. ---------- Added file: http://bugs.python.org/file38247/issue23521-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 17:19:18 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 16:19:18 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424967558.5.0.865891769855.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: OK, thanks. I don't propose to go there with the initial implementation. If it's a problem in practice, someone can raise a bug and we'll fix it then. (I've never seen actual Python code in the wild that does all of that...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 17:29:18 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 26 Feb 2015 16:29:18 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1424968158.82.0.836318179238.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: ...or, should I fork the 3.4 branch? If so, which one...3.4 or origin/3.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 17:30:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 26 Feb 2015 16:30:55 +0000 Subject: [issue23526] Silence resource warnings in test_httplib In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za> Message-ID: <1424968255.52.0.453135418575.issue23526@psf.upfronthosting.co.za> STINNER Victor added the comment: I was going to commit the fix, but currently the 3.4 is not merged into default. I will wait until 3.4 is merged into default to apply the fix. I attach my pending commit. (Python 3.4 is also afffected.) ---------- nosy: +haypo versions: +Python 3.4 Added file: http://bugs.python.org/file38248/httplib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 17:38:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 26 Feb 2015 16:38:49 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424968158.82.0.836318179238.issue23496@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I don't think that Android support should be added to a stable branche (2.7 or 3.4), only in the development branch. You may maintain your own 2.7 or 3.4 fork if you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 17:41:19 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 26 Feb 2015 16:41:19 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1424968879.04.0.759428044341.issue14721@psf.upfronthosting.co.za> Demian Brecht added the comment: > I'm happy to produce a patch if there's any chance it would be merged. If the patch adheres to the RFC, then I see no reason why it shouldn't be merged. What makes this a little more tricky than the snippet that you included in your post though (which would include the Content-Length header for all HTTP methods) is the following from RFC 7230: A user agent SHOULD send a Content-Length in a request message when no Transfer-Encoding is sent and the request method defines a meaning for an enclosed payload body. For example, a Content-Length header field is normally sent in a POST request even when the value is 0 (indicating an empty payload body). A user agent SHOULD NOT send a Content-Length header field when the request message does not contain a payload body and the method semantics do not anticipate such a body. Currently, there is nothing in the http package that defines whether or not a given HTTP method expects a body (as far as I'm aware at any rate), although this would be a simple addition. I'd imagine that the result might look like this: _METHODS_EXPECTING_BODIES = {'OPTIONS', 'POST', 'PUT', 'PATCH'} if method.upper() in _METHODS_EXPECTING_BODIES and \ 'content-length' not in header_names: self._set_content_length(body) I'd prefer to have the conversion from None to empty string done in the body of _set_content_length in order to ensure consistency should the call be made from elsewhere. ---------- nosy: +demian.brecht versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 17:51:07 2015 From: report at bugs.python.org (Thomas Bartelmess) Date: Thu, 26 Feb 2015 16:51:07 +0000 Subject: [issue14855] IPv6 support for logging.handlers In-Reply-To: <1337420973.71.0.891474201343.issue14855@psf.upfronthosting.co.za> Message-ID: <1424969467.66.0.60865124457.issue14855@psf.upfronthosting.co.za> Thomas Bartelmess added the comment: The datagram handler seems still not useable with IPv6 in Python 3.4. Is this patch still under consideration ? ---------- nosy: +Thomas Bartelmess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 17:57:18 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 16:57:18 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424969838.33.0.624861528257.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: OK, here is an updated patch based on the python-dev discussions ---------- Added file: http://bugs.python.org/file38249/pep-441.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 17:59:58 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 16:59:58 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424969998.77.0.262909402611.issue23491@psf.upfronthosting.co.za> Changes by Paul Moore : Removed file: http://bugs.python.org/file38249/pep-441.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 18:00:28 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 17:00:28 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424970028.54.0.0239842703738.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: Sorry - typo. Try again... ---------- Added file: http://bugs.python.org/file38250/pep-441.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 18:23:10 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 26 Feb 2015 17:23:10 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1424971390.54.0.817315908285.issue23530@psf.upfronthosting.co.za> Davin Potts added the comment: Detecting the number of processors available to a process is a distinct concept from reporting the number of processors present on a system. cpu_count is currently focused on the latter. Functionality to report the number of effectively-available processors is indeed valuable information to have in certain situations but it is also something very OS-dependent (I mean the support for it is not present in all OSes, let alone the complication of how to access such information differing across OSes). I think a strong case can be made that cpu_count's current functionality should not change -- the information it provides is very important to have access to. Cool tools like psutil (https://pypi.python.org/pypi/psutil) help cover a great range of genuine needs when making use of processor affinity. ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 18:41:19 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 26 Feb 2015 17:41:19 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424972479.41.0.0762578314345.issue23491@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 18:45:18 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Feb 2015 17:45:18 +0000 Subject: [issue23507] Tuple creation is too slow In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> Message-ID: <1424972718.33.0.0608225164982.issue23507@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Maybe we want a facility to create on-stack static-size tuples? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 18:45:35 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Feb 2015 17:45:35 +0000 Subject: [issue23507] Tuple creation is too slow In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> Message-ID: <1424972735.66.0.34576495523.issue23507@psf.upfronthosting.co.za> Antoine Pitrou added the comment: How many functions can benefit from this approach, though? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 18:52:33 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 26 Feb 2015 17:52:33 +0000 Subject: [issue23519] using asyncio.iscoroutinefunction() on a functools.partial object In-Reply-To: <1424862040.11.0.0579325382624.issue23519@psf.upfronthosting.co.za> Message-ID: <1424973153.21.0.261179141944.issue23519@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yeah, your "add event handler" routine shouldn't be so picky to insist that iscoroutinefunction() returns True. It should just call the thing and verify that it has returned a coroutine object (asyncio.iscoroutine()). ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 18:55:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 17:55:13 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424973313.04.0.811037497182.issue23491@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Did you noticed my comments to previous patch Paul? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 18:59:17 2015 From: report at bugs.python.org (Julian Taylor) Date: Thu, 26 Feb 2015 17:59:17 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1424973557.45.0.36531952328.issue23530@psf.upfronthosting.co.za> Julian Taylor added the comment: I do agree that its probably safer to not change the default return value. But adding a option (or new function) would still be good, the number of available cpus is more often the number you actually want in practice. To the very least the documentation should be improved to clearly state that this number does not guarantee that this amount of cpus are actually available to run on and you should use psutils instead. Code for getting this information for the major operating systems linux, bsd and windows is available in gnu coreutils. I can possibly work on a patch if it would get accepted but I can only actually test it linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 19:05:21 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Feb 2015 18:05:21 +0000 Subject: [issue23528] Limit decompressed data when reading from GzipFile In-Reply-To: <1424946126.98.0.486244279604.issue23528@psf.upfronthosting.co.za> Message-ID: <1424973921.75.0.902852731941.issue23528@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 19:05:34 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Feb 2015 18:05:34 +0000 Subject: [issue23529] Limit decompressed data when reading from LZMAFile and BZ2File In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za> Message-ID: <1424973934.08.0.457956089108.issue23529@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 19:21:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 18:21:06 +0000 Subject: [issue23507] Tuple creation is too slow In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za> Message-ID: <1424974866.64.0.671805876328.issue23507@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Maybe we want a facility to create on-stack static-size tuples? There is no guarantee that called function doesn't save the reference to args. > How many functions can benefit from this approach, though? >From hand-writing caching? Any function, that repeatedly call other functions many times. In additional to sorted()/list.sort() with the key argument, filter() and map(), these are min() and max() with the key argument, some iterators from itertools (groupby(), dropwhile(), takewhile(), accumulate(), filterfalse()). May be some functions that are thin wrappers around special method (e.g. round()). But it is more interesting to investigate why PyTuple_New() is so slow in comparison with hand-written caching. It it can be speeded up, then mauch more code can benefit from this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 19:38:29 2015 From: report at bugs.python.org (Brian Kearns) Date: Thu, 26 Feb 2015 18:38:29 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424975909.59.0.247879274774.issue23521@psf.upfronthosting.co.za> Brian Kearns added the comment: You saw the demo python implementation of divmod_near in Objects/longobject.c? Maybe it's worth using a common implementation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 19:57:20 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 18:57:20 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424977040.91.0.629307388948.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: Serhiy - I just got a notification from the review tool - I'd not used it before and didn't know to check it. But I've read them now and corrected a number of places based on your comments and added a few replies to the review. Thanks for the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 20:21:59 2015 From: report at bugs.python.org (Ben Hoyt) Date: Thu, 26 Feb 2015 19:21:59 +0000 Subject: [issue13617] Reject embedded null characters in wchar* strings In-Reply-To: <1324094022.4.0.746327138354.issue13617@psf.upfronthosting.co.za> Message-ID: <1424978519.31.0.514395329645.issue13617@psf.upfronthosting.co.za> Ben Hoyt added the comment: Note that this (or a very similar issue) also affects os.listdir() on Windows: os.listdir(bytes_path_with_nul) raises ValueError as expected, but os.listdir(unicode_path_with_nul) does not. Test case: >>> import os >>> os.mkdir('foo') >>> os.listdir(b'foo\x00zzz') Traceback (most recent call last): File "", line 1, in ValueError: listdir: embedded null character in path >>> os.listdir('foo\x00zzz') [] However, this is not the case on Linux, as there both calls raise an appropriate ValueError. This needs to be fixed in posixmodule.c's path_converter() function. I'm in the middle of implementing PEP 471 (os.scandir), so don't want to create a proper patch right now, but the fix is to add these lines in posixmodule.c path_converter() after the if (length > 32767) {...} block: if ((size_t)length != wcslen(wide)) { FORMAT_EXCEPTION(PyExc_ValueError, "embedded null character in %s"); Py_DECREF(unicode); return 0; } We should also add test to test_os.py like the following: def test_listdir_nul_in_path(self): self.assertRaises(ValueError, os.listdir, 'y\x00z') self.assertRaises(ValueError, os.listdir, b'y\x00z') ---------- nosy: +benhoyt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 20:55:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 19:55:02 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424980502.76.0.833762029789.issue23491@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Emails from Rietveld often can be found in the spam folder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 20:58:35 2015 From: report at bugs.python.org (johnkw) Date: Thu, 26 Feb 2015 19:58:35 +0000 Subject: [issue23531] SSL operations cause entire process to hang Message-ID: <1424980715.38.0.880892658959.issue23531@psf.upfronthosting.co.za> New submission from johnkw: SSL operations cause entire process to hang. At a minimum this includes the SSL read that goes on after a socket is connected. It may apply to many other (or all) SSL socket operations. ---------- components: Library (Lib) files: sslbug.py messages: 236701 nosy: johnkw priority: normal severity: normal status: open title: SSL operations cause entire process to hang type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file38251/sslbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 21:04:19 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 26 Feb 2015 20:04:19 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1424981059.59.0.179971342578.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: New changelist for updated patch (before merging changes). ---------- Added file: http://bugs.python.org/file38252/starunpack33.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 21:22:01 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 26 Feb 2015 20:22:01 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1424982121.91.0.0325106228282.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Finished merge. ---------- Added file: http://bugs.python.org/file38253/starunpack34.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 21:25:43 2015 From: report at bugs.python.org (SilentGhost) Date: Thu, 26 Feb 2015 20:25:43 +0000 Subject: [issue23531] SSL operations cause entire process to hang In-Reply-To: <1424980715.38.0.880892658959.issue23531@psf.upfronthosting.co.za> Message-ID: <1424982343.14.0.466622756902.issue23531@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 21:40:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 20:40:59 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424983259.49.0.827940352275.issue23491@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Paul, don't click on Reply below the comment on the main page, it never works. Instead click the link above the comment, then click on the comment to unfold it, click on the Reply below the comment, enter your reply, press Send, and after replying all comments click "Publish+Mail Comments" and then press "Pubblish All My Drafts". Your replies by email are not archived and are received only by these who already is added comments on Rietveld or added to the nosy list on Roundup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 21:53:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Feb 2015 20:53:51 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424984031.29.0.135997095703.issue23491@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As for zipimport, it doesn't support namespace packages when no 'directory' entry exists (issue14905). The zipfile module CLI now adds entries for directories (issue22219). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 22:07:12 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 26 Feb 2015 21:07:12 +0000 Subject: [issue1539925] warnings in interactive sessions Message-ID: <1424984832.81.0.569561084263.issue1539925@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 22:10:02 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 26 Feb 2015 21:10:02 +0000 Subject: [issue23528] Limit decompressed data when reading from GzipFile In-Reply-To: <1424946126.98.0.486244279604.issue23528@psf.upfronthosting.co.za> Message-ID: <1424985002.7.0.82215651227.issue23528@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Especially now that this is only going to go into 3.5, I think it makes more sense to handle GzipFile, LZMAFile and BZ2File all in one go. Looking at the code, otherwise there's going to be a lot of duplication. How about introducing a base class 'CompressedFile' that defines most of the logic that's currently in LZMAFile (including the max_size patch from issue 23529), and having {LZMA,BZ2,Gzip}File all inherit from that base? BZ2File and LZMAFile would probably only need to define their own constructor to instantiate the proper compressor/decompressor object. GzipFile would need to additionally overwrite read() and write() in order to handle the CRC and gzip header. But I think both methods could still be written to call super().read/write(). Did I miss something? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 22:32:07 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 21:32:07 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1424986327.3.0.821791558735.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: Serihy, thanks for the explanation. I was aware that my replies weren't getting archived, good to know how to avoid that in future. I've worked out what you mean over the directory entries now. It was easy enough to fix - I just removed the is_file check before writing entries to the zipfile. Test added so it's checked in future as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 23:11:36 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 26 Feb 2015 22:11:36 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424988696.48.0.972792713234.issue23465@psf.upfronthosting.co.za> Paul Moore added the comment: The PEP has now been accepted, and as far as I am aware this patch is complete. If anyone has any review comments, please speak up, otherwise I believe this is ready to be committed, if some kind soul is willing :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 23:16:12 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 26 Feb 2015 22:16:12 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424988972.37.0.616850004113.issue23465@psf.upfronthosting.co.za> Steve Dower added the comment: I'll get it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 23:26:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Feb 2015 22:26:12 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <20150226222609.4016.18772@psf.io> Roundup Robot added the comment: New changeset 2eb99070a38f by Steve Dower in branch 'default': Issue #23465: Implement PEP 486 - Make the Python Launcher aware of virtual environments (patch by Paul Moore) https://hg.python.org/cpython/rev/2eb99070a38f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 23:30:51 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 26 Feb 2015 22:30:51 +0000 Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of virtual environments In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za> Message-ID: <1424989851.14.0.868060138892.issue23465@psf.upfronthosting.co.za> Steve Dower added the comment: It's in, and we are of course free to modify this further if virtualenv starts including pyvenv.cfg files or some other way to resolve the version number without launching it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 23:34:50 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 26 Feb 2015 22:34:50 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424990090.12.0.486821143437.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > You saw the demo python implementation of divmod_near in Objects/longobject.c? I was looking for it, but could not find. Thanks for the pointer. (See also #8817.) In issue23521-6.patch, I've used a slightly optimized variant of divmod_near code and beefed up the tests some more because the code is somewhat non-obvious. ---------- Added file: http://bugs.python.org/file38254/issue23521-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 23:54:23 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 26 Feb 2015 22:54:23 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <1424991263.12.0.834712332461.issue21800@psf.upfronthosting.co.za> Mark Lawrence added the comment: The patch contains changes to code and tests have been added so can we have a formal review please. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 26 23:55:54 2015 From: report at bugs.python.org (Rick Otten) Date: Thu, 26 Feb 2015 22:55:54 +0000 Subject: [issue23532] regex "|" behavior differs from documentation Message-ID: <1424991354.19.0.598419279567.issue23532@psf.upfronthosting.co.za> Changes by Rick Otten : ---------- components: Regular Expressions nosy: Rick Otten, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: regex "|" behavior differs from documentation type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 00:00:05 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 26 Feb 2015 23:00:05 +0000 Subject: [issue21865] Improve invalid category exception for warnings.filterwarnings In-Reply-To: <1403654797.31.0.372707276339.issue21865@psf.upfronthosting.co.za> Message-ID: <1424991605.66.0.948310232852.issue21865@psf.upfronthosting.co.za> Mark Lawrence added the comment: Just a gentle reminder if this and #16845 are to get into 3.5. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 00:00:23 2015 From: report at bugs.python.org (Rick Otten) Date: Thu, 26 Feb 2015 23:00:23 +0000 Subject: [issue23532] regex "|" behavior differs from documentation Message-ID: <1424991623.26.0.907615110662.issue23532@psf.upfronthosting.co.za> New submission from Rick Otten: The documentation states that "|" parsing goes from left to right. This doesn't seem to be true when spaces are involved. (or \s). Example: In [40]: mystring Out[40]: 'rwo incorporated' In [41]: re.sub('incorporated| inc|llc|corporation|corp| co', '', mystring) Out[41]: 'rwoorporated' In this case " inc" was processed before incorporated. If I take the space out: In [42]: re.sub('incorporated|inc|llc|corporation|corp| co', '', mystring) Out[42]: 'rwo ' incorporated is processed first. If I put a space with each, then " incorporated" is processed first: In [43]: re.sub(' incorporated| inc|llc|corporation|corp| co', '', mystring) Out[43]: 'rwo' And If use \s instead of a space, it is processed first: In [44]: re.sub('incorporated|\sinc|llc|corporation|corp| co', '', mystring) Out[44]: 'rwoorporated' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 00:13:00 2015 From: report at bugs.python.org (Mark Shannon) Date: Thu, 26 Feb 2015 23:13:00 +0000 Subject: [issue23532] regex "|" behavior differs from documentation In-Reply-To: <1424991623.26.0.907615110662.issue23532@psf.upfronthosting.co.za> Message-ID: <1424992380.89.0.148668234379.issue23532@psf.upfronthosting.co.za> Mark Shannon added the comment: This looks like the expected behaviour to me. re.sub matches the leftmost occurence and the regular expression is greedy so (x|xy) will always match xy if it can. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 00:27:06 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 26 Feb 2015 23:27:06 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1424993226.75.0.327154390569.issue23521@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: We can further optimize _divide_and_round by changing r*=2 to r<<=1 and q % 2 == 1 to (q & 1), but this will obfuscate the algorithm and limit arguments to ints. (As written, _divide_and_round will work with any numeric types.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 01:07:32 2015 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 27 Feb 2015 00:07:32 +0000 Subject: [issue23532] regex "|" behavior differs from documentation In-Reply-To: <1424991623.26.0.907615110662.issue23532@psf.upfronthosting.co.za> Message-ID: <1424995652.89.0.447353118129.issue23532@psf.upfronthosting.co.za> Matthew Barnett added the comment: @Mark is correct, it's not a bug. In the first example: It tries to match each alternative at position 0. Failure. It tries to match each alternative at position 1. Failure. It tries to match each alternative at position 2. Failure. It tries to match each alternative at position 3. Success. ' inc' matches. In the second example: It tries to match each alternative at position 0. Failure. It tries to match each alternative at position 1. Failure. It tries to match each alternative at position 2. Failure. It tries to match each alternative at position 3. Failure. It tries to match each alternative at position 4. Success. 'incorporated' matches. ('inc' is a later alternative; it's considered only if the earlier alternatives have failed to match at that position.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 01:26:03 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Feb 2015 00:26:03 +0000 Subject: [issue23531] SSL operations cause entire process to hang In-Reply-To: <1424980715.38.0.880892658959.issue23531@psf.upfronthosting.co.za> Message-ID: <1424996763.55.0.788473456446.issue23531@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can you post a standalone example that doesn't use requests and that doesn't rely on a local HTTP server? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 01:36:49 2015 From: report at bugs.python.org (Rick Otten) Date: Fri, 27 Feb 2015 00:36:49 +0000 Subject: [issue23532] regex "|" behavior differs from documentation In-Reply-To: <1424991623.26.0.907615110662.issue23532@psf.upfronthosting.co.za> Message-ID: <1424997409.44.0.506210201553.issue23532@psf.upfronthosting.co.za> Rick Otten added the comment: Can the documentation be updated to make this more clear? I see now where the clause "As the target string is scanned, ..." is describing what you have listed here. I and a coworker both read the description several times and missed that. I thought it first tried "incorporated" against the whole string, then tried " inc" against the whole string, etc... When actually it was trying each, "incorporated" and " inc" and the others against the first position of the string. And then again for the second position. Since I want to force the order against the whole string before trying the next one for my particular use case, I'll do a series of re.subs instead of trying to do them all in one. It makes sense now and is easy to fix. Thanks for looking at it and explaining what is happening more clearly. It was really not obvious. I tried at least 100 variations and wasn't seeing the pattern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 01:42:04 2015 From: report at bugs.python.org (vinod sharma) Date: Fri, 27 Feb 2015 00:42:04 +0000 Subject: [issue23533] MacOSX Python child process running urlopen crashed when tkMessageBox is imported Message-ID: <1424997724.04.0.676051015042.issue23533@psf.upfronthosting.co.za> New submission from vinod sharma: I've have an application which uses tkMessageBox module, multiprocessing module and urllib2 module. For some unknown reason, python child process is crashing silently while fetching a url. This only happens when tkMessageBox module is imported. Sample code to reproduce the problem is attached. My operating system is MacOS 10.10 ---------- components: Tkinter files: crashreproduce.py messages: 236721 nosy: vinod sharma priority: normal severity: normal status: open title: MacOSX Python child process running urlopen crashed when tkMessageBox is imported type: crash versions: Python 2.7 Added file: http://bugs.python.org/file38255/crashreproduce.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 02:30:55 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 27 Feb 2015 01:30:55 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425000655.8.0.306905799124.issue23496@psf.upfronthosting.co.za> Ethan Furman added the comment: Once this android Python is built, can it: - be copied from/to other android devices? - run without KBOX? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 03:01:42 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Feb 2015 02:01:42 +0000 Subject: [issue22435] socketserver.TCPSocket leaks socket to garbage collector if server_bind() fails In-Reply-To: <1410999922.66.0.432841070426.issue22435@psf.upfronthosting.co.za> Message-ID: <1425002502.77.0.750538075151.issue22435@psf.upfronthosting.co.za> Martin Panter added the comment: This is fixed in 3.4.3. I think it can be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 03:03:31 2015 From: report at bugs.python.org (Maxime Belanger) Date: Fri, 27 Feb 2015 02:03:31 +0000 Subject: [issue19884] Importing readline produces erroneous output In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za> Message-ID: <1425002611.06.0.0463038852188.issue19884@psf.upfronthosting.co.za> Maxime Belanger added the comment: I think the version check (`readline._READLINE_VERSION < 0x0600`) is incorrect, as the test still fails for me on Mac OS X 10.9 with readline version 6.2 (0x602). Upgrading to 6.3 (0x603) fixes it, though. ---------- nosy: +Maxime Belanger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 03:18:20 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 27 Feb 2015 02:18:20 +0000 Subject: [issue23532] add example of 'first match wins' to regex "|" documentation? In-Reply-To: <1424991623.26.0.907615110662.issue23532@psf.upfronthosting.co.za> Message-ID: <1425003500.08.0.416003648334.issue23532@psf.upfronthosting.co.za> R. David Murray added the comment: The thing is, what you describe is fundamental to how regular expressions work. I'm not sure it makes sense to add a specific mention of it to the '|' docs, since it applies to all regexes. ---------- assignee: -> docs at python components: +Documentation -Regular Expressions nosy: +docs at python, r.david.murray title: regex "|" behavior differs from documentation -> add example of 'first match wins' to regex "|" documentation? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 03:23:26 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 27 Feb 2015 02:23:26 +0000 Subject: [issue23533] MacOSX Python child process running urlopen crashed when tkMessageBox is imported In-Reply-To: <1424997724.04.0.676051015042.issue23533@psf.upfronthosting.co.za> Message-ID: <1425003806.32.0.943782872538.issue23533@psf.upfronthosting.co.za> R. David Murray added the comment: When you say 'crash silently', what exactly do you mean? How are you running the program? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 03:45:14 2015 From: report at bugs.python.org (bazwal) Date: Fri, 27 Feb 2015 02:45:14 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1425005114.71.0.966179874792.issue23262@psf.upfronthosting.co.za> bazwal added the comment: I arrived at an almost identical solution to the one given by Oleg. It works for me with FF 28, 35 & 36 - but presumably there are earlier versions where it does not, otherise why have the -remote option at all? The gist of the Mozilla bug report is that the option has existed for a very long time, but there are now other command-line options that do exactly the same thing. So the only question seems to be whether Python should still support those older versions of FF that actually require it (if any exist). On the xdg-open issue: the $BROWSER env var has priority over the default list of browsers to try, so that might explain why xdg-open is not being used on some systems (that is how I originally became aware of this problem). ---------- nosy: +bazwal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 03:50:39 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 27 Feb 2015 02:50:39 +0000 Subject: [issue22435] socketserver.TCPSocket leaks socket to garbage collector if server_bind() fails In-Reply-To: <1410999922.66.0.432841070426.issue22435@psf.upfronthosting.co.za> Message-ID: <1425005439.88.0.278982419066.issue22435@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 04:05:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 27 Feb 2015 03:05:04 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1425006304.03.0.793346650621.issue23262@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 07:46:40 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 27 Feb 2015 06:46:40 +0000 Subject: [issue19075] Add sorting algorithm visualization to turtledemo In-Reply-To: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za> Message-ID: <1425019600.27.0.763151474954.issue19075@psf.upfronthosting.co.za> Ethan Furman added the comment: Code spiffied: added randomization routine that can be used after a sort to test a different sort method (or the same one). Larry, can this extra demo go into 3.4.4, or only 3.5? ---------- nosy: +larry Added file: http://bugs.python.org/file38256/issue19075.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 07:57:30 2015 From: report at bugs.python.org (Maxime Belanger) Date: Fri, 27 Feb 2015 06:57:30 +0000 Subject: [issue23534] `test_longdouble` fails on Mac when using system libffi (version 3.1) Message-ID: <1425020250.66.0.941803975171.issue23534@psf.upfronthosting.co.za> New submission from Maxime Belanger: Greetings, We're compiling a custom version of Python 2.7.9 for the Mac (building on OS X 10.9 with Xcode 6.1), and we're instructing Python to use a vanilla copy of `libffi` (that we've also compiled ourselves) using the `--with-system-ffi` flag. We're running the regression test suite for sanity purposes and we've noticed this error in `test_ctypes`'s `test_longdouble` method: ====================================================================== FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) ---------------------------------------------------------------------- Traceback (most recent call last): File "../Python.framework/Versions/2.7/lib/python2.7/ctypes/test/test_callbacks.py", line 88, in test_longdouble self.check_type(c_longdouble, 3.14) File "../Python.framework/Versions/2.7/lib/python2.7/ctypes/test/test_callbacks.py", line 24, in check_type self.assertEqual(result, arg) AssertionError: 0.0 != 3.14 I'm reasonably convinced this is caused by the version of `libffi` we're using. It seems that if the `--with-system-ffi` flag isn't set, an internal version of `libffi` is used instead. However, given that version 3.1 is said to be the version Python 2.7.9 is "tracking", this feels like a bug to me. Also, it seems that trying to hit this code path in production code could trigger a crash. ---------- components: Tests, ctypes messages: 236729 nosy: Maxime Belanger priority: normal severity: normal status: open title: `test_longdouble` fails on Mac when using system libffi (version 3.1) type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 08:09:19 2015 From: report at bugs.python.org (SilentGhost) Date: Fri, 27 Feb 2015 07:09:19 +0000 Subject: [issue23534] `test_longdouble` fails on Mac when using system libffi (version 3.1) In-Reply-To: <1425020250.66.0.941803975171.issue23534@psf.upfronthosting.co.za> Message-ID: <1425020959.24.0.818513933088.issue23534@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Macintosh nosy: +amaury.forgeotdarc, belopolsky, hynek, meador.inge, ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 08:24:47 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 27 Feb 2015 07:24:47 +0000 Subject: [issue23534] `test_longdouble` fails on Mac when using system libffi (version 3.1) In-Reply-To: <1425020250.66.0.941803975171.issue23534@psf.upfronthosting.co.za> Message-ID: <1425021887.03.0.457850326466.issue23534@psf.upfronthosting.co.za> Ned Deily added the comment: Is there a reason you can't use the Python-supplied version of libffi? That's what the standard builds for python.org installers do. I believe it is the case that there are OS X-specific changes in the Python local version that do not exist in the upstream and/or system versions but I've not familiar with the differences myself; it's not been a high priority issue to test with them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 08:33:13 2015 From: report at bugs.python.org (David Bolen) Date: Fri, 27 Feb 2015 07:33:13 +0000 Subject: [issue23314] Disabling CRT asserts in debug build In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> Message-ID: <1425022393.08.0.395991237214.issue23314@psf.upfronthosting.co.za> Changes by David Bolen : ---------- nosy: +db3l _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 09:19:28 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 27 Feb 2015 08:19:28 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1425025168.25.0.500453618871.issue14721@psf.upfronthosting.co.za> Ned Deily added the comment: James, Demian: this issue has been closed for almost three years and the changes released long ago: comments made here will likely be ignored. Please open a new issue if you want them to be acted on. ---------- nosy: +ned.deily versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 09:48:06 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 27 Feb 2015 08:48:06 +0000 Subject: [issue23533] MacOSX Python child process running urlopen crashed when tkMessageBox is imported In-Reply-To: <1424997724.04.0.676051015042.issue23533@psf.upfronthosting.co.za> Message-ID: <1425026886.56.0.887969434936.issue23533@psf.upfronthosting.co.za> Ned Deily added the comment: I was able to reproduce this and from the system crash report it appears that this is a duplicate of Issue20585. The workaround noted there should work for you here: define a "no_proxy" environment variable to prevent Python from attempting to call the System Configuration framework for default proxy settings. For example, if you don't need a network proxy, you could do: no_proxy='*' python2.7 crashreproduce.py ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> urllib2 unrelease KQUEUE on Mac OSX 10.9+ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 09:55:56 2015 From: report at bugs.python.org (Alex Shkop) Date: Fri, 27 Feb 2015 08:55:56 +0000 Subject: [issue22832] Tweak parameter names for fcntl module In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za> Message-ID: <1425027356.85.0.600286905295.issue22832@psf.upfronthosting.co.za> Alex Shkop added the comment: Created a patch. It renames arguments in clinic declarations and in documents. For lockf I've chosen Linux naming, because it really calls fcntl which has an argument called cmd, not function. ---------- keywords: +patch nosy: +ashkop Added file: http://bugs.python.org/file38257/issue22832.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 09:59:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Feb 2015 08:59:04 +0000 Subject: [issue19884] Importing readline produces erroneous output In-Reply-To: <1425002611.06.0.0463038852188.issue19884@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Mac OS X uses libedit, not libreadline. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 10:39:51 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 27 Feb 2015 09:39:51 +0000 Subject: [issue20703] RuntimeError caused by lazy imports in pdb In-Reply-To: <1392914840.47.0.865855778793.issue20703@psf.upfronthosting.co.za> Message-ID: <1425029991.76.0.0564393640954.issue20703@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > In that case the behavior you are seeing is correct, even if not obvious or even desirable. It will happen any time you are looping over sys.modules and call a function/method which has a function-scoped import statement for a module that hasn't been imported yet (or calls another function that does so, etc.). I do not agree. Suppose there is some piece of code that loops over sys.modules without doing any lazy import (and thus without raising the RuntimeError "dictionary changed size during iteration"). Now, if you insert a pdb.set_trace() in that code, you will get the RuntimeError and this is not correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 12:22:56 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 27 Feb 2015 11:22:56 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1425036176.85.0.819594354466.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: Updated patch including (I hope!) all review comments so far. ---------- Added file: http://bugs.python.org/file38258/pep-441.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 12:44:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Feb 2015 11:44:52 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1425037492.95.0.840171502726.issue23262@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: --new-window and --new-tab are Firefox and SeaMonkey2.x only. [1] So this will break the support of IceApe on Debian Etch (iceape v.1.0.13 [2]). [1] https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options [2] http://archive.debian.net/etch/devel/iceape ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 12:45:40 2015 From: report at bugs.python.org (Ben Hoyt) Date: Fri, 27 Feb 2015 11:45:40 +0000 Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning function In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za> Message-ID: <1425037540.31.0.406770255678.issue22524@psf.upfronthosting.co.za> Ben Hoyt added the comment: Okay, here's the next version of the patch. I've updated scandir-2.patch with a number of modifications and several fixes to the C code. This includes Victor's scandir-6.patch test suite (with minor mods) and my original documentation. Note that I haven't looked at either the documentation or the tests too closely, but I'm uploading the patch in any case so Victor (or others) can start reviewing the C code. ---------- Added file: http://bugs.python.org/file38259/scandir-7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 13:20:32 2015 From: report at bugs.python.org (Eugene Bright) Date: Fri, 27 Feb 2015 12:20:32 +0000 Subject: [issue23535] os.path.join() wrong concatenation of "C:" on Windows Message-ID: <1425039632.15.0.00321481955838.issue23535@psf.upfronthosting.co.za> New submission from Eugene Bright: Hello! I found strange os.path.join() behavior on Windows. It works fine in common case. >>> os.path.join("C", "filename") 'C\\filename' But if first argument is "C:" there are no backslashes added at all! >>> os.path.join("C:", "filename") 'C:filename' But I expect two inserted backslashes... >>> sys.version '3.4.1 |Anaconda 2.1.0 (64-bit)| (default, Sep 24 2014, 18:32:42) [MSC v.1600 64 bit (AMD64)]' Is there a bug? Thanks! ---------- messages: 236739 nosy: Eugene Bright priority: normal severity: normal status: open title: os.path.join() wrong concatenation of "C:" on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 13:21:45 2015 From: report at bugs.python.org (Eugene Bright) Date: Fri, 27 Feb 2015 12:21:45 +0000 Subject: [issue23535] os.path.join() wrong concatenation of "C:" on Windows In-Reply-To: <1425039632.15.0.00321481955838.issue23535@psf.upfronthosting.co.za> Message-ID: <1425039705.3.0.622703593871.issue23535@psf.upfronthosting.co.za> Changes by Eugene Bright : ---------- type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 13:36:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Feb 2015 12:36:44 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1425040604.38.0.784988165076.issue23491@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is not well known old way how to make executable Python files on Windows. Add line "@python -x %0 %*" at the start of your Python script and rename the script to *.bat. The "-x" option makes Python to skip first line that is not Python, and @ forbids echoing executed command in bat-file. Could zipapp support this feature? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 13:49:29 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Fri, 27 Feb 2015 12:49:29 +0000 Subject: [issue23536] Add explicit information on config file format not supporting filters Message-ID: <1425041368.98.0.00469006830804.issue23536@psf.upfronthosting.co.za> New submission from Piotr Dobrogost: It would be helpful to make it clear in section "Configuration file format" that it's not possible to configure filters through configuration file as opposed to dictionary passed to dictConfig() method. I found this clearly stated in Pyramid docs at http://docs.pylonsproject.org/docs/pyramid/en/latest/narr/logging.html ? "For more advanced filtering, the logging module provides a logging.Filter object; however it cannot be used directly from the configuration file." ---------- assignee: docs at python components: Documentation messages: 236741 nosy: docs at python, piotr.dobrogost, vinay.sajip priority: normal severity: normal status: open title: Add explicit information on config file format not supporting filters type: enhancement versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 14:01:51 2015 From: report at bugs.python.org (Ben Hoyt) Date: Fri, 27 Feb 2015 13:01:51 +0000 Subject: [issue23535] os.path.join() wrong concatenation of "C:" on Windows In-Reply-To: <1425039632.15.0.00321481955838.issue23535@psf.upfronthosting.co.za> Message-ID: <1425042111.38.0.277100500728.issue23535@psf.upfronthosting.co.za> Ben Hoyt added the comment: Sorry, but this is operating as designed and documented. See the docs here: https://docs.python.org/3.4/library/os.path.html#os.path.join "On Windows ... since there is a current directory for each drive, os.path.join("c:", "foo") represents a path relative to the current directory on drive C: (c:foo), not c:\foo. So I think this issue should be closed as not a bug. ---------- nosy: +benhoyt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 14:07:54 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 27 Feb 2015 13:07:54 +0000 Subject: [issue19075] Add sorting algorithm visualization to turtledemo In-Reply-To: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za> Message-ID: <1425042474.44.0.165411702187.issue19075@psf.upfronthosting.co.za> Larry Hastings added the comment: This can wait for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 14:22:31 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 27 Feb 2015 13:22:31 +0000 Subject: [issue23535] os.path.join() wrong concatenation of "C:" on Windows In-Reply-To: <1425039632.15.0.00321481955838.issue23535@psf.upfronthosting.co.za> Message-ID: <1425043351.53.0.338296089476.issue23535@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree this isn't a bug, due to per-drive current directories on Windows. ---------- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 14:33:23 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 27 Feb 2015 13:33:23 +0000 Subject: [issue23491] PEP 441 - Improving Python Zip Application Support In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za> Message-ID: <1425044003.82.0.0774563301554.issue23491@psf.upfronthosting.co.za> Paul Moore added the comment: I'm -1 on this. The whole point of having a .pyz extension is so that you don't need to use an extension that's for files containing text to hold binary data. If you want to do this, use zipapp and specify no interpreter line, then add the @python line yourself. Or just use a zip utility. Or build your own command line app. With the ability to supply an open file to create_archive, it's a 3-liner: with open(dest_filename, 'wb') as f: f.write(b'@python -x %0 %*\n') zipapp.create_archive(source_dir, f) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 14:35:16 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 27 Feb 2015 13:35:16 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425044116.32.0.205015933493.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Ethan, The binary produced runs in the KBOX environment. It can be copied between devices provided the target device has the KBOX environment installed. Victor et al, I read https://docs.python.org/devguide/devcycle.html#indevbranch a couple of times and, unless I;m missing something the dev branch only contains the 3.5 release. This may be an obvious question but if I fork the 3.4 branch would Android-related patches be eligible for that branch? I'm hesitant to clone the dev branch as I;ve worked hard to get the latest stable version (3.4.2?) working on my device; I'm more interested in a) making my efforts available to others and b) learning the Python language than c) constantly working at making the latest and greatest Android-friendly ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 14:39:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Feb 2015 13:39:42 +0000 Subject: [issue23529] Limit decompressed data when reading from LZMAFile and BZ2File In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za> Message-ID: <1425044382.89.0.81126331591.issue23529@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > LZMAFile now uses BufferedReader.peek(). The current implementation seems appropriate, but I am not comfortable with the current specification in the documentation, which says it is allowed to not return any useful data. What do you mean with "useful data"? peek() should always return at least one byte (except on EOF or on non-blocking streams, of course). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:02:58 2015 From: report at bugs.python.org (mirabilos) Date: Fri, 27 Feb 2015 14:02:58 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1425045778.14.0.447067064059.issue23332@psf.upfronthosting.co.za> mirabilos added the comment: Hm, RFCs are just RFCs and not standards, they can recommend whatever they want, and they can (and do) contradict each other. I?ve seen things (mostly related to eMail and PIM synchronisation) that require ?Z? for UTC proper. Additionally, +00:00 can be UTC, but it can also be British Winter Time, or DST of UTC-1. ?Z? is clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:10:07 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 27 Feb 2015 14:10:07 +0000 Subject: [issue22832] Tweak parameter names for fcntl module In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za> Message-ID: <1425046207.72.0.779981936956.issue22832@psf.upfronthosting.co.za> Brett Cannon added the comment: The patch LGTM. Serhiy, you have anything to add? ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:17:52 2015 From: report at bugs.python.org (Mirko Vogt) Date: Fri, 27 Feb 2015 14:17:52 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1425046672.63.0.335207919468.issue23332@psf.upfronthosting.co.za> Mirko Vogt added the comment: The proper response to that comment probably is: It's called ISO8601 and not RFC8601. And unfortunately ISO stands for "International Standard". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:19:39 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 27 Feb 2015 14:19:39 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1425046779.9.0.880907733206.issue23332@psf.upfronthosting.co.za> Mark Lawrence added the comment: I'm a British citizen and I've never once heard the term "British Winter Time", so where does it come from? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:35:26 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 27 Feb 2015 14:35:26 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1425047726.1.0.163238404534.issue23332@psf.upfronthosting.co.za> R. David Murray added the comment: mirabilos was referring to Alexander's reference to RFCs that advise against using 'Z'. RFC are standards once they become formally accepted as such, and often they become de-facto standards before formal acceptance. Given that the method is supposedly conforming to a specific standard, it ought to do so...but in addition to the ISO standard there are other de-jure and de-facto standards and deviations to contend with. Concrete examples are required for decision, I think, if the base standard is ambiguous. It may be that a new method or a flag controlling the behavior needs to be introduced in order to satisfy specific wide-spread use cases, but those use cases need to be enough motivation to support such an enhancement. By my reading, so far there have been no such concrete wide spread use cases brought forward to motivate any change other than deprecating utcnow. ('now' must return naive datetimes to preserve backward compatibility. If you don't want to use naive datetimes, make sure you don't...the datetime module was originally directly supported only naive datetimes (timezone is recent), so some care is needed.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:47:26 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 27 Feb 2015 14:47:26 +0000 Subject: [issue21919] Changing cls.__bases__ must ensure proper metaclass inheritance In-Reply-To: <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za> Message-ID: <1425048446.6.0.0247638310696.issue21919@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Eldar sorry that this issue slipped our net. ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:51:07 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 27 Feb 2015 14:51:07 +0000 Subject: [issue23471] 404 Not Found when downloading Python 3.4.3rc1 Documentation In-Reply-To: <1424075429.03.0.707318894375.issue23471@psf.upfronthosting.co.za> Message-ID: <1425048667.79.0.195616900673.issue23471@psf.upfronthosting.co.za> Larry Hastings added the comment: This is part of the release process. 3.4.3 was fine last I checked, so perhaps some wonderful automated process broke it for me. 3.5, I think I simply didn't upload the docs properly. Anyway, this is my responsibility as RM for 3.4 and 3.5, so in the future if I slip up again please assign the bug to me. ---------- assignee: docs at python -> larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:53:31 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 27 Feb 2015 14:53:31 +0000 Subject: [issue21944] Allow copying of CodecInfo objects In-Reply-To: <1404906729.25.0.633895333058.issue21944@psf.upfronthosting.co.za> Message-ID: <1425048811.0.0.323155456446.issue21944@psf.upfronthosting.co.za> Mark Lawrence added the comment: The change to codecs.py seems simple enough but would we usually use plain asserts in test code? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:55:17 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 27 Feb 2015 14:55:17 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425048917.18.0.0920245097878.issue23496@psf.upfronthosting.co.za> Stefan Krah added the comment: > c) constantly working at making the latest and greatest Android-friendly But that is precisely what "Android support", should it be added, means: It does take constant work (and build slaves) to support a platform. Unrelatedly, regarding the localeconv changes: I cannot find any bugreport for localeconv at https://code.google.com/p/android/issues/list . Before we add workarounds to Python, it would be nice to have at least a record that the Android developers actually *did* refuse to add a simple struct lconv (trivial for en_US!). How about opening an Android issue? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:56:04 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 14:56:04 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425048964.05.0.0755383394577.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: Turns out the old code no longer compiles without this change, as the internal variable we were previously using is no longer exported from the CRT. Can I get a review please? ---------- nosy: +larry, serhiy.storchaka priority: high -> critical type: crash -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 15:58:51 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 27 Feb 2015 14:58:51 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425049131.13.0.11706339093.issue23524@psf.upfronthosting.co.za> Larry Hastings added the comment: I turned in my Windows developer badge in 2007. Can I recuse myself, pretty-please? How about Tim Golden or Zach Ware? Who I notice are conveniently already added to the nosy list! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:00:39 2015 From: report at bugs.python.org (Tim Golden) Date: Fri, 27 Feb 2015 15:00:39 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1425049131.13.0.11706339093.issue23524@psf.upfronthosting.co.za> Message-ID: <54F08693.3050104@timgolden.me.uk> Tim Golden added the comment: The problem is that this isn't an area I'm particularly familiar with (either in Python nor in Windows) so I need time to ramp up my awareness of what Steve's proposing plus then assessing the change. I'll try... but I rather hope Zach gets there first! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:07:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Feb 2015 15:07:08 +0000 Subject: [issue22832] Tweak parameter names for fcntl module In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za> Message-ID: <1425049628.77.0.0196247358942.issue22832@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I found a lot of not related issues in the documentation. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:11:01 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 27 Feb 2015 15:11:01 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425049861.74.0.748568639841.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Given Stephan's comments regarding Android support I'm beginning to think that I may have bitten off more than I can chew. Is there an option between 'constant work' and 'zero contribution'? I am not by any means an Android developer so the following is possibly riddled with miconceptions and errata, but, regarding locale support, I think there's a difference between 'regular' and 'native' development. Native development involves using the NDK to port various bits of C-written utilities and libraries to Android...like python... and it is where the locale is broken, because of Android's limited libc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:19:10 2015 From: report at bugs.python.org (lilydjwg) Date: Fri, 27 Feb 2015 15:19:10 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1425050350.68.0.515625635574.issue23262@psf.upfronthosting.co.za> Changes by lilydjwg : ---------- nosy: +lilydjwg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:22:45 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 27 Feb 2015 15:22:45 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1425050565.3.0.408260003318.issue23332@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > RFCs are just RFCs and not standards RFCs have a standards track which includes steps such as "Proposed Standard", "Draft Standard", and "Internet Standard". Once they become Internet Standards, they get an additional designation as STD. For example, RFC 822 (which is relevant here) is an Internet Standard and also known as STD 11. RFC 3339 ("Date and Time on the Internet: Timestamps") is a Proposed Standard, but widely used and implemented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:24:00 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 27 Feb 2015 15:24:00 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425050640.0.0.599405106209.issue23496@psf.upfronthosting.co.za> R. David Murray added the comment: Most of us fall toward the lower end of "constant work" and "zero contribution", honestly, since the majority of us are doing it in spare time and not getting paid for it. What is needed is a long-term commitment to fix bugs if they show up when new changes are made to CPython. Which is where a buildbot is fairly critical...and I have no idea how complicated it will be to set up a buildbot for your environment. I think it should be possible, though, since buildbot and twisted are written in python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:25:21 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 27 Feb 2015 15:25:21 +0000 Subject: [issue23534] `test_longdouble` fails on Mac when using system libffi (version 3.1) In-Reply-To: <1425020250.66.0.941803975171.issue23534@psf.upfronthosting.co.za> Message-ID: <1425050721.09.0.0375229294683.issue23534@psf.upfronthosting.co.za> Ronald Oussoren added the comment: On OSX the internal copy of libffi that's used is based on the one in PyObjC, which in turn is based on the version of libffi on opensource.apple.com (IIRC with some small patches that fix minor issues found by the PyObjC testsuite). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:29:33 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 15:29:33 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425050973.06.0.813299412896.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: Larry - this may hold up the next release, so just keeping you in the loop. You don't have to review (though there are many changes in shared code, so you may not be useless :) ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:31:02 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 27 Feb 2015 15:31:02 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425051062.45.0.768690177426.issue23496@psf.upfronthosting.co.za> Stefan Krah added the comment: But NDK bugs are reported to the same bug tracker, aren't they? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:34:03 2015 From: report at bugs.python.org (Alex Shkop) Date: Fri, 27 Feb 2015 15:34:03 +0000 Subject: [issue22832] Tweak parameter names for fcntl module In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za> Message-ID: <1425051243.47.0.479130616145.issue22832@psf.upfronthosting.co.za> Alex Shkop added the comment: Looks like default value for mutate_flag in ioctl() should be False. Docstring says: "If the argument is a mutable buffer and the mutable_flag argument is not passed or is false, the behavior is as if a string had been passed." Should I change the default value or the docstring? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:37:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Feb 2015 15:37:54 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425051474.29.0.618506075606.issue23524@psf.upfronthosting.co.za> STINNER Victor added the comment: > there is no way (and won't be any way) to disable these on a per-thread basis. I don't understand. Is _set_thread_local_invalid_parameter_handler() process-wide, or dos it only affect the current thread? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:41:45 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 15:41:45 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425051705.11.0.188721433465.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: Just the current thread. When set, it overrides the global setting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:42:57 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 15:42:57 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425051777.07.0.862286555864.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: Ah, but the bit you quoted is referring to the assert dialogs, which only exist in debug builds. The invalid parameter handler will normally kill the process even in release builds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:52:19 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 27 Feb 2015 15:52:19 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <54F08693.3050104@timgolden.me.uk> Message-ID: Zachary Ware added the comment: Tim Golden added the comment: > The problem is that this isn't an area I'm particularly familiar with > (either in Python nor in Windows) so I need time to ramp up my awareness > of what Steve's proposing plus then assessing the change. I'll try... > but I rather hope Zach gets there first! Same here, Tim ;) I've looked through the patch, and didn't see anything that scares me. However, I can't claim to have a deep enough understanding of the issue or the code to confidently say it's good and the right solution. Also, I haven't had a chance to build or test it, only read through it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 16:58:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Feb 2015 15:58:01 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425052681.98.0.0441399990377.issue23524@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand the issue, can you please elaborate? Can you please give an example of code which raise the bug, explain the behaviour on VS < 2015 and the behaviour on VS > 2015? I don't understand why changes are restricted to posixmodule.c. Much more code manipulates file descriptors. If Microsoft chose to kill a process when you pass an invalid file descriptor, why should Python behave differently? Is it only for Python unit test? If the problem only occurs with unit tests, why not only changing the behaviour with test.support.SuppressCrashReporter? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:05:04 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 27 Feb 2015 16:05:04 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425053104.24.0.652962646593.issue23496@psf.upfronthosting.co.za> Stefan Krah added the comment: BTW, PEP 11 now demands a stable buildbot for official platform support (IMO a very sane policy). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:08:53 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 16:08:53 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425053333.61.0.628238148599.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: #4804 has most of the prior discussion, but here's some code that will cause the process to terminate: import os os.close(3) The instant termination rather than OSError is why _PyVerify_fd exists at all, and that's only there because when the behaviour was disabled globally users complained (#3545 and #4804). You are correct that _PyVerify_fd is used in more places where it should be updated (specifically _io/fileio.c and fileutils.c). It only makes sense where it's protecting a call into a CRT function though, so not all of these places should be changed. I'll make updates. This is why I beg for reviews - I know that I'll miss things :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:12:12 2015 From: report at bugs.python.org (Alex Shkop) Date: Fri, 27 Feb 2015 16:12:12 +0000 Subject: [issue22832] Tweak parameter names for fcntl module In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za> Message-ID: <1425053532.13.0.0764312257485.issue22832@psf.upfronthosting.co.za> Alex Shkop added the comment: Docs say that mutate_flag is true by default since Python 2.5. Looks like I should fix the docstring. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:12:47 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 27 Feb 2015 16:12:47 +0000 Subject: [issue18382] multiprocessing's overlapped PipeConnection issues on Windows 8 In-Reply-To: <1373114737.55.0.0779572840335.issue18382@psf.upfronthosting.co.za> Message-ID: <1425053567.5.0.911342740303.issue18382@psf.upfronthosting.co.za> Davin Potts added the comment: Steve: FWIW, it looks like a good solution to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:14:29 2015 From: report at bugs.python.org (Martin Richard) Date: Fri, 27 Feb 2015 16:14:29 +0000 Subject: [issue23537] BaseSubprocessTransport includes two unused methods Message-ID: <1425053669.13.0.0502434719545.issue23537@psf.upfronthosting.co.za> New submission from Martin Richard: base_subprocess.BaseSuprocessTransport implements _make_write_subprocess_pipe_proto and _make_read_subprocess_pipe_proto. Both are private and both raise NotImplementedError. However, when I grep in tulip sources for those methods, they are never called nor overridden by subclasses of BaseSuprocessTransport. Shouldn't they be removed? ---------- components: asyncio messages: 236777 nosy: gvanrossum, haypo, martius, yselivanov priority: normal severity: normal status: open title: BaseSubprocessTransport includes two unused methods _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:19:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Feb 2015 16:19:44 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425053984.1.0.869865883011.issue23524@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be include this in Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:25:57 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 27 Feb 2015 16:25:57 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425054357.58.0.636505257094.issue23496@psf.upfronthosting.co.za> Ethan Furman added the comment: Cyd, if you want to be a CPython/Android resource that's great. If you don't have time for it, I completely understand. What I'm hoping for is to take your initial efforts and build from there, as there are others who can take what you've started and run with it. Make no mistake, your taking the time to share what you've done is greatly appreciated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:26:45 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 16:26:45 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425054405.92.0.570093165441.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: I considered that, but then we'll be disabling the handler for calls into external modules (assuming whatever pyd layer exists is doing its job correctly), which is exactly where the error is most relevant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:31:04 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 27 Feb 2015 16:31:04 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1425054664.11.0.072822929537.issue23530@psf.upfronthosting.co.za> Davin Potts added the comment: Adding an option does sound like a better possibility. Still, when I start looking through the examples that psutil provides, it reminds me how this is but one small piece of a much larger picture which psutil has done a nice, focused job of working to address. If the patch you create were to depend upon gnu coreutils, I do not think it can be accepted for licensing reasons. Interestingly psutil does not appear to depend upon that library. Regarding the docs, what text would you propose instead of what's currently there for describing cpu_count? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:33:57 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 27 Feb 2015 16:33:57 +0000 Subject: [issue23138] cookiejar parses cookie value as int with empty name-value pair and Expires In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za> Message-ID: <1425054837.0.0.717184179798.issue23138@psf.upfronthosting.co.za> Demian Brecht added the comment: Attached is a fix that ignores the entire invalid cookie as defined in RFC 6265, Section 5.2. I'm also attaching patches for maintenance branches as it's a valid bug (NAME=VALUE pairs are required across all RFCs), although it would break backwards compatibility if the user was expecting invalid behaviour. ---------- keywords: +easy, patch stage: -> patch review Added file: http://bugs.python.org/file38260/issue23138_tip.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:34:24 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 27 Feb 2015 16:34:24 +0000 Subject: [issue23138] cookiejar parses cookie value as int with empty name-value pair and Expires In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za> Message-ID: <1425054864.54.0.996583677961.issue23138@psf.upfronthosting.co.za> Changes by Demian Brecht : Added file: http://bugs.python.org/file38261/issue23138_34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:34:41 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 27 Feb 2015 16:34:41 +0000 Subject: [issue23138] cookiejar parses cookie value as int with empty name-value pair and Expires In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za> Message-ID: <1425054881.13.0.139839693242.issue23138@psf.upfronthosting.co.za> Changes by Demian Brecht : Added file: http://bugs.python.org/file38262/issue23138_27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:40:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Feb 2015 16:40:59 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425055259.64.0.158597420464.issue23524@psf.upfronthosting.co.za> STINNER Victor added the comment: > I considered that, but then we'll be disabling the handler for calls into external modules (assuming whatever pyd layer exists is doing its job correctly), which is exactly where the error is most relevant. Hum ok. So I try to rephrase the issue. When Python is compiled in debug mode, the Windows C runtime (CRT) kills the process when a fault is detected. A fault can be an invalid memory access, a C assertion ("assert(...);") which failed, etc. The problem is that the Python test suite explicitly call functions with invalid parameters to check that Python "handles correctly" errors. The problem is that unit tests expect that Python raises an exception, while the CRT kills the process by default. You propose to modify the behaviour of the CRT of the current thread in the os module to raise a regular exception, instead of killing the process. I agree with your suggestion :-) We already use _PyVerify_fd() to raises an OSError(EBADF) exception, instead of killing the process when functions like os.close() are called with an invalid file descriptor. We cannot disable globally CRT checks because users want them (#3545 and #4804) to validate their own C libraries. So CRT checks should only be disabled temporary when a Python function of the stdlib is called. We expect that calling a third party function kills the process if it is called with an invalid parameter. It's the purpose of the debug build. (I didn't review the patch yet.) Note: "kill the process" probably means that Windows opens a popup to ask to debug the application when a debugger is installed, instead of killing silently the application. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:41:55 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 27 Feb 2015 16:41:55 +0000 Subject: [issue22890] StringIO.StringIO pickled in 2.7 is not unpickleable on 3.x In-Reply-To: <1416210085.6.0.932097721403.issue22890@psf.upfronthosting.co.za> Message-ID: <1425055315.06.0.414800243403.issue22890@psf.upfronthosting.co.za> Mark Lawrence added the comment: Seems fine on Windows 8.1 c:\Users\Mark\Documents\MyPython>c:\cpython\PCbuild\amd64\python.exe Python 3.5.0a1+ (default:344d57c521b9+, Feb 27 2015, 13:39:56) [MSC v.1800 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, io >>> pickle.dumps(io.StringIO('abc'), 2) b'\x80\x02c_io\nStringIO\nq\x00)\x81q\x01(X\x03\x00\x00\x00abcq\x02X\x01\x00\x00\x00\nq\x03K\x00Ntq\x04b.' >>> pickle.loads(b'\x80\x02c_io\nStringIO\nq\x00)\x81q\x01(X\x03\x00\x00\x00abcq\x02X\x01\x00\x00\x00\nq\x03K\x00Ntq\x04b.') <_io.StringIO object at 0x0000004C6E604288> >>> ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:44:37 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 16:44:37 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425055477.75.0.16825240064.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: That's a pretty good summation, though it misses two points. 1. _PyVerify_fd no longer compiles. 2. The process will terminate in both release builds and debug builds. (In debug builds you also get a dialog letting you attach a debugger, unless those are suppressed as in #23314 and the test suite.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:47:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Feb 2015 16:47:52 +0000 Subject: [issue23526] Silence resource warnings in test_httplib In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za> Message-ID: <20150227164747.87123.92581@psf.io> Roundup Robot added the comment: New changeset 056d71d7bb28 by Victor Stinner in branch '3.4': Issue #23526: Fix ResourceWarning in test_httplib. Patch written by Alex Shkop. https://hg.python.org/cpython/rev/056d71d7bb28 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:48:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Feb 2015 16:48:29 +0000 Subject: [issue23526] Silence resource warnings in test_httplib In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za> Message-ID: <1425055708.99.0.147913842431.issue23526@psf.upfronthosting.co.za> STINNER Victor added the comment: I applied your patch. Thanks Alex Shkop! (FYI I also added your name to Misc/ACKS.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:51:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Feb 2015 16:51:09 +0000 Subject: [issue23537] BaseSubprocessTransport includes two unused methods In-Reply-To: <1425053669.13.0.0502434719545.issue23537@psf.upfronthosting.co.za> Message-ID: <20150227165104.16430.20870@psf.io> Roundup Robot added the comment: New changeset 0b390b5a6729 by Victor Stinner in branch '3.4': Issue #23537: Remove 2 unused private methods of asyncio.BaseSubprocessTransport https://hg.python.org/cpython/rev/0b390b5a6729 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 17:52:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Feb 2015 16:52:20 +0000 Subject: [issue23537] BaseSubprocessTransport includes two unused methods In-Reply-To: <1425053669.13.0.0502434719545.issue23537@psf.upfronthosting.co.za> Message-ID: <1425055940.85.0.970182048777.issue23537@psf.upfronthosting.co.za> STINNER Victor added the comment: Yeah, they are completly useless. Thanks for the report Martin. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:05:47 2015 From: report at bugs.python.org (Andy Maier) Date: Fri, 27 Feb 2015 17:05:47 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1425056747.77.0.632690211773.issue1322@psf.upfronthosting.co.za> Changes by Andy Maier : ---------- nosy: +andymaier _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:05:55 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 27 Feb 2015 17:05:55 +0000 Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za> Message-ID: <1425056755.43.0.635374643458.issue22853@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Davin I believe that you're interested in multiprocessing issues. ---------- nosy: +BreamoreBoy, davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:07:17 2015 From: report at bugs.python.org (johnkw) Date: Fri, 27 Feb 2015 17:07:17 +0000 Subject: [issue23531] SSL operations cause entire process to hang In-Reply-To: <1424980715.38.0.880892658959.issue23531@psf.upfronthosting.co.za> Message-ID: <1425056837.21.0.217740474151.issue23531@psf.upfronthosting.co.za> johnkw added the comment: Not sure what you mean. That is a standalone example. It creates the local "HTTP server", which is merely a dummy listen socket. The whole point is just to have something that does a slow I/O operation, and simply not responding is sufficient for that to reproduce the bug. Also, I would add that on further investigation this occurs on cygwin, but not on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:08:25 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 27 Feb 2015 17:08:25 +0000 Subject: [issue23471] 404 Not Found when downloading Python 3.4.3rc1 Documentation In-Reply-To: <1424075429.03.0.707318894375.issue23471@psf.upfronthosting.co.za> Message-ID: <1425056905.56.0.172018561331.issue23471@psf.upfronthosting.co.za> Larry Hastings added the comment: I think I've got them all working now. Please reopen if you discover new breakage. (Or old breakage I guess if I didn't actually fix it...!) ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:09:19 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Feb 2015 17:09:19 +0000 Subject: [issue23531] SSL operations cause entire process to hang In-Reply-To: <1424980715.38.0.880892658959.issue23531@psf.upfronthosting.co.za> Message-ID: <1425056959.08.0.789537524423.issue23531@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It creates the local "HTTP server", which is merely a dummy listen socket Sorry, I hadn't noticed. Still, the example shouldn't rely on the third party "requests" library. > Also, I would add that on further investigation this occurs on cygwin, but not on Linux. Cygwin is not a supported platform at all. Can you reproduce with an official Windows build? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:12:33 2015 From: report at bugs.python.org (Andy Maier) Date: Fri, 27 Feb 2015 17:12:33 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1425057153.46.0.284717664556.issue1322@psf.upfronthosting.co.za> Andy Maier added the comment: Do we really think that a package on pypi solves the problem better? The discussion only shows that it is more likely we end up with multiple different packages on pypi, instead of one that is commonly agreed. I agree it is tough to get to an agreed upon approach, but having this in the Python base at least ensures that it is the one approach everybody uses. The /etc/os-release format seems to be used more often now, so I'm wondering why we cannot come up with a reasonable approach that is backwards compatible, supports /etc/os-release, and (if still needed), also /etc/lsb-release and the lsb_release script. Again: If we ever want to end up with just one package on pypi, that very discussion needs to happen. It seems to me that if the approach should be compatible, then we cannot use the new generic files (lsb* and os-release) first. The currently implemented approach needs to be used first. Then the new generic files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:13:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Feb 2015 17:13:52 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za> Message-ID: <20150227171340.15304.34334@psf.io> Roundup Robot added the comment: New changeset 38c503c2c066 by Brett Cannon in branch 'default': Issue #22834: Drop a redundant comment and use errno instead of an https://hg.python.org/cpython/rev/38c503c2c066 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:14:11 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 27 Feb 2015 17:14:11 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za> Message-ID: <1425057251.01.0.475175145058.issue22834@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for catches the mistakes, guys! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:17:20 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Fri, 27 Feb 2015 17:17:20 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425057440.34.0.982625665338.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: I'll try to do as much as I can to get this through. Once I reinstall the NDK (I accidently wiped my hard drive with a bad dd command recently), I'll test this on my old Android phone that still runs 2.3 and would be very happy if someone else can test it something newer (my laptop doesn't seem to like the Android emulator). I'll also try to do this against the development branch or tip or head or whatever it's called. I'd be very happy if someone could contribute a build slave, because I can't. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:19:01 2015 From: report at bugs.python.org (Alex Shkop) Date: Fri, 27 Feb 2015 17:19:01 +0000 Subject: [issue23526] Silence resource warnings in test_httplib In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za> Message-ID: <1425057541.01.0.121486526914.issue23526@psf.upfronthosting.co.za> Alex Shkop added the comment: Thanks, great to hear. I'm glad to help) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:20:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Feb 2015 17:20:16 +0000 Subject: [issue22890] StringIO.StringIO pickled in 2.7 is not unpickleable on 3.x In-Reply-To: <1416210085.6.0.932097721403.issue22890@psf.upfronthosting.co.za> Message-ID: <1425057616.62.0.198515825544.issue22890@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The issue is about StringIO.StringIO, not io.StringIO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:27:05 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 27 Feb 2015 17:27:05 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425058025.92.0.0869716269796.issue23496@psf.upfronthosting.co.za> Ethan Furman added the comment: I will work on the build slave (note: it will definitely be /work/ so if anyone has the resource and know-how to just do it, I will not be offended ;) . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:28:35 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 27 Feb 2015 17:28:35 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425058115.73.0.00313728369579.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Stefan, I wouldn't know if they're reported to the same bug tracker...it's possible they aren't. Additionally it's possible that the lack of locale support in libc isn't considered a bug. Ethan, Given Victor's recommendation of using the dev branch and the fact that my mods were made to a stable download (3.4.2), what would be the recommended way to go about getting my efforts into github so that they can be built upon? Should I start working with the fork I've already made of cpython (with 3.4.2 as the default branch) or is there a different method I should use? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:28:47 2015 From: report at bugs.python.org (Link Mauve) Date: Fri, 27 Feb 2015 17:28:47 +0000 Subject: [issue23538] New Windows installer in 3.5.0a1 breaks compatibility with Wine Message-ID: <1425058127.83.0.0230104914567.issue23538@psf.upfronthosting.co.za> New submission from Link Mauve: The previous msi installer was working fine with `wine msiexec /i python*.msi`, but the new exe-based one fails with an unreadable error in latest wine. ---------- components: Windows messages: 236802 nosy: Link Mauve, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: New Windows installer in 3.5.0a1 breaks compatibility with Wine type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:30:43 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 27 Feb 2015 17:30:43 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None Message-ID: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> New submission from Demian Brecht: #14721 solved setting the Content-Length header for 0-length bodies. However, it doesn't account for cases where body is None (reported by James Rutherford here: http://bugs.python.org/issue14721#msg236600). One method of solving this might be something like this: _METHODS_EXPECTING_BODIES = {'OPTIONS', 'POST', 'PUT', 'PATCH'} if method.upper() in _METHODS_EXPECTING_BODIES and \ 'content-length' not in header_names: self._set_content_length(body) (_set_content_length would have to be updated in order to allow for None) This ensures that Content-Length will not be set for methods not expecting a body. RFC 7230, Section 3.3.2: A user agent SHOULD NOT send a Content-Length header field when the request message does not contain a payload body and the method semantics do not anticipate such a body. ---------- components: Library (Lib) messages: 236803 nosy: demian.brecht priority: normal severity: normal stage: needs patch status: open title: Content-length not set for HTTP methods expecting body when body is None type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:31:57 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 27 Feb 2015 17:31:57 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1425058317.67.0.700036376305.issue14721@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the heads up Ned. James: I've created #23539 in the event that you'd like to contribute a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:40:44 2015 From: report at bugs.python.org (Julian Taylor) Date: Fri, 27 Feb 2015 17:40:44 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1425058844.55.0.923611260591.issue23530@psf.upfronthosting.co.za> Julian Taylor added the comment: certainly for anything that needs good control over affinity psutils is the best choice, but I'm not arguing to implement full process control in python. I only want python to provide the number of cores one can work on to make best use of the available resources. If you code search python files for cpu_count you find on github 18000 uses, randomly sampling a few every single one was to determine the number of cpus to start worker jobs to get best performance. Every one of these will oversubscribe a host that restricts the cpus a process can use. This is an issue especially for the increasingly popular use of containers instead of full virtual machines. as a documentation update I would like to have a note saying that this number is the number of (online) cpus in the system may not be the number of of cpus the process can actually use. Maybe with a link to len(psutils.Process.get_affinity()) as a reference on how to obtain that number. there would be no dependence on coreutils, I just mentioned it as you can look up the OS api you need to use to get the number there (e.g. sched_getaffinity). It is trivial API use and should not be a licensing issue, one could also look at the code from psutil which most likely looks very similar. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:54:36 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 17:54:36 +0000 Subject: [issue23538] New Windows installer in 3.5.0a1 breaks compatibility with Wine In-Reply-To: <1425058127.83.0.0230104914567.issue23538@psf.upfronthosting.co.za> Message-ID: <1425059676.57.0.798861851078.issue23538@psf.upfronthosting.co.za> Steve Dower added the comment: The latest wine may not be up to date enough, since the new installer (and new Python) depend on MSVC 14.0, which is still only in preview. Of course, there could be other issues, but without any more information it's very difficult to act on them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 18:59:08 2015 From: report at bugs.python.org (Matthias Klose) Date: Fri, 27 Feb 2015 17:59:08 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1425059948.06.0.0441074845605.issue22079@psf.upfronthosting.co.za> Matthias Klose added the comment: reopening, this breaks some stuff in several places ... https://bugs.launchpad.net/ubuntu/+source/terminator/+bug/1426294 ---------- nosy: +doko resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:11:10 2015 From: report at bugs.python.org (Martin Richard) Date: Fri, 27 Feb 2015 18:11:10 +0000 Subject: [issue23540] Proposal for asyncio: SubprocessTransport.detach() to detach a process from a transport Message-ID: <1425060670.32.0.0609117457316.issue23540@psf.upfronthosting.co.za> New submission from Martin Richard: I would like to add a detach() method to base_suprocess.BaseSuprocessTransport, which would release the underlying Popen object to the user, pretty much like socket.detach() detaches a socket object and returns the fd. The rationale is the following: the lifetime of a subprocess started using a loop is bound to that loop, or require to clause the loop without terminating the process which leads to resource leaks (the stdin/stdout pipes can't be closed). It may be useful in some cases. For instance, I create a fork of a process running a loop which started one or more subprocesses. In the child processus, I'd like to close the pipes and free the transport objects by calling: proc = transport.detach() transport.close() proc.stdin.close() proc.stdout.close() proc.stderr.close() The process is still running, in the parent process, everything looks like before the fork, the child can forget about the parent loop without fearing resource leaks. It is somewhat related to http://bugs.python.org/issue21998 (Support fork). I propose a patch which adds BaseSubprocessTransport.detach(), a specialized version for _UnixSubprocessTransport taking care of removing the callbacks from the ChildWatcher and a detach method for the pipes transports for unix and proactor. ---------- components: asyncio files: add-detach-to-subprocess_transport.patch keywords: patch messages: 236808 nosy: gvanrossum, haypo, martius, yselivanov priority: normal severity: normal status: open title: Proposal for asyncio: SubprocessTransport.detach() to detach a process from a transport type: enhancement versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38263/add-detach-to-subprocess_transport.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:15:00 2015 From: report at bugs.python.org (Link Mauve) Date: Fri, 27 Feb 2015 18:15:00 +0000 Subject: [issue23538] New Windows installer in 3.5.0a1 breaks compatibility with Wine In-Reply-To: <1425058127.83.0.0230104914567.issue23538@psf.upfronthosting.co.za> Message-ID: <1425060900.29.0.28708225523.issue23538@psf.upfronthosting.co.za> Link Mauve added the comment: Maybe you could continue to distribute the msi? I?ve also heard it?s used by Windows admins to install something on many computers at once. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:25:12 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 27 Feb 2015 18:25:12 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425061512.53.0.368144166297.issue23496@psf.upfronthosting.co.za> Ethan Furman added the comment: I'm afraid I know next to nothing about git, so cannot help there. I would think that it wouldn't be too hard for someone (such as Ryan or myself) to forward port a set of 3.4.2 patches to 3.5 -- so whatever is easiest for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:33:51 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 18:33:51 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425062031.58.0.200756586914.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: New patch, which should cover all the other uses of _PyVerify_fd outside of posixmodule. I've moved _PyVerify_fd into fileutils (but left _PyVerify_fd_dup2 in posixmodule, as it's basically deprecated at this point). _Py_VERIFY_FD is now in fileutils.h, and is used everywhere it makes sense. I also fixed up some error handling for _Py_fstat that was using errno on Windows rather than GetLastError() - I can split this into a separate issue if it's in the way. _Py_BEGIN/END_SUPPRESS_IPH are now in pymacro.h as they need to be after PyAPI_DATA is defined - the silent invalid parameter handler is now defined in PC/invalid_parameter_handler.c but setting and restoring it need to be in macros. Builds are fine on VS 2015 CTP 6 (with this code enabled) and VS 2013 (with the old code enabled), and I'm getting set up to test a Linux build with the patch. ---------- Added file: http://bugs.python.org/file38264/23524_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:35:22 2015 From: report at bugs.python.org (James Rutherford) Date: Fri, 27 Feb 2015 18:35:22 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425062122.94.0.591500042609.issue23539@psf.upfronthosting.co.za> James Rutherford added the comment: Thanks for setting up the new issue, I'll cook up a patch. I'm assuming this affects all Python 3.X versions but I've specifically encountered it on Python 2.7. ---------- nosy: +jimr versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:44:17 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 18:44:17 +0000 Subject: [issue23538] New Windows installer in 3.5.0a1 breaks compatibility with Wine In-Reply-To: <1425058127.83.0.0230104914567.issue23538@psf.upfronthosting.co.za> Message-ID: <1425062657.19.0.162083532528.issue23538@psf.upfronthosting.co.za> Steve Dower added the comment: The new installer can also be used for that, and it's actually documented now (at least in the CHM - doesn't seem to have made it onto the website yet). I personally install it onto many computers at once fairly often, so I'm going to make sure that works. The old single MSI installer is completely gone though and won't be coming back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:52:18 2015 From: report at bugs.python.org (Link Mauve) Date: Fri, 27 Feb 2015 18:52:18 +0000 Subject: [issue23538] New Windows installer in 3.5.0a1 breaks compatibility with Wine In-Reply-To: <1425058127.83.0.0230104914567.issue23538@psf.upfronthosting.co.za> Message-ID: <1425063138.17.0.0985360370011.issue23538@psf.upfronthosting.co.za> Link Mauve added the comment: I just tried it with wine-git, it doesn?t go further either by running the exe directly, or by running msiexec.exe /i on it. Is there anything else required to run it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:52:50 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 27 Feb 2015 18:52:50 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425062122.94.0.591500042609.issue23539@psf.upfronthosting.co.za> Message-ID: <27835319-7265-4854-8BF8-2A29E1F06CD5@gmail.com> Demian Brecht added the comment: > I'm assuming this affects all Python 3.X versions but I've specifically encountered it on Python 2.7. Unless there are any core dev objections, I think it's applicable to 2.7, 3.4 and 3.5 as other minor 3.x versions are in security mode (https://docs.python.org/devguide/devcycle.html#security-branches). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:57:20 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 18:57:20 +0000 Subject: [issue23538] New Windows installer in 3.5.0a1 breaks compatibility with Wine In-Reply-To: <1425058127.83.0.0230104914567.issue23538@psf.upfronthosting.co.za> Message-ID: <1425063440.46.0.632034921686.issue23538@psf.upfronthosting.co.za> Steve Dower added the comment: You should just run it directly - it isn't an MSI. As I said, wine is probably not compatible with the new CRT version yet, but without at least an error message, it's impossible to tell. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 19:58:38 2015 From: report at bugs.python.org (James Rutherford) Date: Fri, 27 Feb 2015 18:58:38 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425063518.7.0.104603184717.issue23539@psf.upfronthosting.co.za> James Rutherford added the comment: OK, thanks. ---------- versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 20:05:17 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 19:05:17 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1425063917.0.0.400143916395.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: Builds fine on Ubuntu (sample size = 1, but it's about the best I can manage myself :) ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 20:10:28 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 27 Feb 2015 19:10:28 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425064228.36.0.24602040897.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: How does this sound? * I'll clone the fork of the 3.4 branch I made in github, build and patch. * Ryan will (as best as he can) grab said patches, regenerate them for the bug tracker or forward port them to 3.5 (in github? to Mercurial) * I'll figure out the upgrade/maintain/patch workflow as best I can so i can set it up on my build device and help out with porting later versions of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 20:13:53 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 27 Feb 2015 19:13:53 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425064433.23.0.176168684956.issue23496@psf.upfronthosting.co.za> Ethan Furman added the comment: Sounds great! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 20:18:42 2015 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 27 Feb 2015 19:18:42 +0000 Subject: [issue23532] add example of 'first match wins' to regex "|" documentation? In-Reply-To: <1424991623.26.0.907615110662.issue23532@psf.upfronthosting.co.za> Message-ID: <1425064722.75.0.0691048508257.issue23532@psf.upfronthosting.co.za> Matthew Barnett added the comment: Not quite all. POSIX regexes will always look for the longest match, so the order of the alternatives doesn't matter, i.e. x|xy would give the same result as xy|x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 20:24:27 2015 From: report at bugs.python.org (James Rutherford) Date: Fri, 27 Feb 2015 19:24:27 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425065067.95.0.199328478814.issue23539@psf.upfronthosting.co.za> James Rutherford added the comment: OK, I've got a patch but it's failing on 'test_send_file'[1], which is sending a body on a GET request. According to the IETF memo[2]: Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations to reject the request. So I don't know whether to remove the method constraint so this test passes, or to "fix" this test to use a different method. My feeling is that stripping out Content-Length for GET requests could cause problems for some code that for whatever reason uses this, so we should remove that constraint (it was only "SHOULD NOT" after all) and go back to the original proposal of just setting the content length for bodies that are None as well as empty strings. [1] https://hg.python.org/cpython/file/325aec842e3e/Lib/test/test_httplib.py#l297 [2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#section-7.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 20:32:19 2015 From: report at bugs.python.org (Link Mauve) Date: Fri, 27 Feb 2015 19:32:19 +0000 Subject: [issue23538] New Windows installer in 3.5.0a1 breaks compatibility with Wine In-Reply-To: <1425058127.83.0.0230104914567.issue23538@psf.upfronthosting.co.za> Message-ID: <1425065539.14.0.909695431096.issue23538@psf.upfronthosting.co.za> Link Mauve added the comment: The installer runs, but the first screen doesn?t display any of its buttons (I can still click on them). After trying to start the actual installation, I get ?0x80070005 - Access Denied? (despite having the permissions on my wine folder, of course). Whether I select system-wide or local installation doesn?t change anything. I attached the logs wine outputs on stderr, not that they seem very useful. ---------- Added file: http://bugs.python.org/file38265/wine.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 20:55:30 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Feb 2015 19:55:30 +0000 Subject: [issue19075] Add sorting algorithm visualization to turtledemo In-Reply-To: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za> Message-ID: <1425066930.77.0.346120086608.issue19075@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Have you tested it both standalone and within the turtledemo app? ---------- stage: -> patch review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 20:57:15 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 27 Feb 2015 19:57:15 +0000 Subject: [issue19075] Add sorting algorithm visualization to turtledemo In-Reply-To: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za> Message-ID: <1425067035.22.0.0472201186289.issue19075@psf.upfronthosting.co.za> Ethan Furman added the comment: Yup. Also updated the turtledemo docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:05:55 2015 From: report at bugs.python.org (bazwal) Date: Fri, 27 Feb 2015 20:05:55 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1425067555.79.0.21274664923.issue23262@psf.upfronthosting.co.za> bazwal added the comment: > this will break the support of IceApe on Debian Etch Is Python committed to supporting obsolete Debian releases? The latest oldstable Debian release (6.0 Squeeze) has iceape-2.0.11 [1], which does seem to support the -new-window and -new-tab options (I haven't actually tested this, though - I just looked at the source code [2]). The iceweasel/iceape products are just rebranded versions of Firefox and Seamonkey. The webbrowser module currently supports them via the generic Mozilla class - so Python should only be concerned about which versions of the common Mozilla codebase it needs to continue support for. [1] https://packages.debian.org/search?suite=squeeze&searchon=names&keywords=iceape [2] http://anonscm.debian.org/cgit/pkg-mozilla/iceape.git/tree/mozilla/browser/components/nsBrowserContentHandler.js?h=squeeze#n419 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:08:49 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 27 Feb 2015 20:08:49 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1425058844.55.0.923611260591.issue23530@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Well, we already expose CPU affinity: >>> import os >>> os.sched_getaffinity(0) {0} IMO the current implementation is sufficient (and talking about overcommitting for CPU is a bit moot if you're using virtual machine anyways). The current documentation says: Return the number of CPUs in the system. Returns None if undetermined. Which to me is clear enough, although if you want to add an explicit note that this doesn't take cpu affinity into account that wouldn't hurt. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:11:35 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 27 Feb 2015 20:11:35 +0000 Subject: [issue23494] adding timedelta to datetime object is not timezone aware In-Reply-To: <1424461574.53.0.989762969133.issue23494@psf.upfronthosting.co.za> Message-ID: <1425067895.76.0.953892220144.issue23494@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:13:42 2015 From: report at bugs.python.org (Julian Taylor) Date: Fri, 27 Feb 2015 20:13:42 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1425068022.71.0.0560990897379.issue23530@psf.upfronthosting.co.za> Julian Taylor added the comment: oh thats great so python already has what I want. Then just an small documentation update would be good, I'll have a go at a patch later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:18:35 2015 From: report at bugs.python.org (Ceridwen) Date: Fri, 27 Feb 2015 20:18:35 +0000 Subject: [issue23541] Re module's match() fails to halt on a particular input Message-ID: <1425068315.25.0.0642664750871.issue23541@psf.upfronthosting.co.za> New submission from Ceridwen: Attached is a three-line script whose third line, a call to match() for a compiled regex, fails to halt on Python 2.7 and on 3.4 (after changing ur in front of the regex string to r to accommodate the change in Unicode handling). I found it by stepping through the debugger so I suspect the problem is in the C backend, not the Python. ---------- components: Regular Expressions files: mwe.py messages: 236829 nosy: ceridwen, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Re module's match() fails to halt on a particular input type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file38266/mwe.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:23:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Feb 2015 20:23:51 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1425068631.29.0.385832174391.issue22079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This restriction was added because bad thing could happen when statically allocated class inherits dynamically allocated class. I don't remember the number of the issue where such example was exposed, may be Alex remember it. Likely pygobject creates classes in not safe manner. It would be more correct to create pygobject classes with PyType_FromSpec(), but current code worked for it for years. May be it is not so easy to change pygobject. So may be we should revert changes in 2.7 or convert the error to the deprecation warning. Is there similar issue with 3.4? There may be difference due to the difference of the lifetime of types in 2.x and 3.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:28:56 2015 From: report at bugs.python.org (James Rutherford) Date: Fri, 27 Feb 2015 20:28:56 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425068936.71.0.920378022888.issue23539@psf.upfronthosting.co.za> James Rutherford added the comment: Patch attached for the 2.7 branch, including updated tests. All tests pass. Let me know if this looks like a sensible approach and I'll produce something comparable for 3.X. The logic now is as it was before, except that we set a content length of zero if the body is None and the method is one of OPTIONS, PATCH, PUT, or POST. ---------- keywords: +patch Added file: http://bugs.python.org/file38267/issue23539-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:30:41 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 27 Feb 2015 20:30:41 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425065067.95.0.199328478814.issue23539@psf.upfronthosting.co.za> Message-ID: <4E1E3203-409E-4CD8-B1A9-D1AC76005249@gmail.com> Demian Brecht added the comment: My concern about this is around the combination of the following two passages: draft-ietf-httpbis-p2-semantics-14, Section 7.3: > Bodies on GET requests have no defined semantics. Note that sending > a body on a GET request might cause some existing implementations to > reject the request. RFC 7230, Section 3.3.2: > The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field. My concern around the above is the possibility that servers may have implementations that reject requests with methods that are not expecting bodies solely on the existence of the Content-Length header rather than the value (which may be 0). Without a good amount of research around whether or not this would be an actual problem in practice, I wouldn?t be comfortable adding Content-Length header to every request. > My feeling is that stripping out Content-Length for GET requests could cause problems for some code that for whatever reason uses this That?s definitely a valid concern. What if the logic was tweaked a little: expecting_len = method.upper() in _METHODS_EXPECTING_BODIES or \ body is not None if expecting_len and 'content-length' not in header_names: self._set_content_length(body) That way, if someone is intentionally sending a body in a GET request, the value of Content-Length would still be automatically added, but would still be set to 0 for all other cases where bodies are expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:39:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Feb 2015 20:39:30 +0000 Subject: [issue23541] Re module's match() fails to halt on a particular input In-Reply-To: <1425068315.25.0.0642664750871.issue23541@psf.upfronthosting.co.za> Message-ID: <1425069570.72.0.554541216021.issue23541@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Minimal example for your case is re.match(r'(\w+\s*)+\s+\d+', 'Compiling Regular Patterns to Sequential Machines') It doesn't halt, it just needs too long time to finish. Your should rewrite the regular expression to avoid catastrophic backtracking (http://www.regular-expressions.info/catastrophic.html). For example rewrite the start of your expression as re.match(r'\w[\w\s]*\s\d+', 'Compiling Regular Patterns to Sequential Machines') ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:42:46 2015 From: report at bugs.python.org (Eugene Bright) Date: Fri, 27 Feb 2015 20:42:46 +0000 Subject: [issue23535] os.path.join() wrong concatenation of "C:" on Windows In-Reply-To: <1425039632.15.0.00321481955838.issue23535@psf.upfronthosting.co.za> Message-ID: <1425069766.93.0.608613906438.issue23535@psf.upfronthosting.co.za> Eugene Bright added the comment: Sorry for disturbing. I'll read docs more careful next time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:43:48 2015 From: report at bugs.python.org (Shakeel Mohamed) Date: Fri, 27 Feb 2015 20:43:48 +0000 Subject: [issue23542] Update PEP 476 for using urllib2.build_opener() Message-ID: <1425069828.0.0.476725699175.issue23542@psf.upfronthosting.co.za> New submission from Shakeel Mohamed: In the "Opting Out" section of PEP 476, there's a workaround for disabling SSL cert verification. I think it would be worth updating the section to include the following workaround when using urllib2.build_opener(), like so: unverified_ssl_handler = urllib2.HTTPSHandler(context=ssl._create_unverified_context()) opener = urllib2.build_opener(unverified_ssl_handler) ---------- assignee: docs at python components: Documentation messages: 236835 nosy: Shakeel Mohamed, docs at python priority: normal severity: normal status: open title: Update PEP 476 for using urllib2.build_opener() versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:48:13 2015 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 27 Feb 2015 20:48:13 +0000 Subject: [issue23523] cmath.atanh has wrong output In-Reply-To: <1424910215.48.0.703419414911.issue23523@psf.upfronthosting.co.za> Message-ID: <1425070093.14.0.765931645822.issue23523@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Both are correct Well, strictly speaking only the output with positive imaginary part is correct here: the recommendations of C99 Annex G (which Python's cmath module follows) use the sign of the zero imaginary part to determine which 'side' of the branch cut the input lies on. In this case, -1.89 is interpreted as complex(-1.89, 0.0), so the imaginary part is a positive zero, and the sign of the imaginary part of the result matches that for complex(-1.89, small_and_positive). So all four of the following are correct: >>> cmath.atanh(complex(-1.89, 0.0)) (-0.5888951591901462+1.5707963267948966j) >>> cmath.atanh(complex(-1.89, -0.0)) (-0.5888951591901462-1.5707963267948966j) >>> cmath.atanh(complex(1.89, 0.0)) (0.5888951591901462+1.5707963267948966j) >>> cmath.atanh(complex(1.89, -0.0)) (0.5888951591901462-1.5707963267948966j) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 21:50:39 2015 From: report at bugs.python.org (Carlo Beccarini) Date: Fri, 27 Feb 2015 20:50:39 +0000 Subject: [issue23512] The list of built-in http://text-processing.com/demo/sentiments is not alphabetical on https://docs.python.org/2/library/functions.html In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za> Message-ID: <1425070239.82.0.725946601009.issue23512@psf.upfronthosting.co.za> Carlo Beccarini added the comment: Well, these built-in are considered as non essential. ---------- nosy: +Paradisee title: List of builtins is not alphabetical on https://docs.python.org/2/library/functions.html -> The list of built-in http://text-processing.com/demo/sentiments is not alphabetical on https://docs.python.org/2/library/functions.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:01:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Feb 2015 21:01:33 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1425070893.97.0.317833160743.issue23262@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May it is time to drop support of SeaMonkey 1.x and systems released 8 years ago. But then we should drop the support of browsers "netsape", "mozilla", "firebird". And this should be documented somewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:01:52 2015 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 27 Feb 2015 21:01:52 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1425070912.79.0.00529237024579.issue23488@psf.upfronthosting.co.za> Mark Dickinson added the comment: > see my old issue #17884 ... and you can also re-read my explanations in that issue about why simply using uint32_t and int32_t doesn't work! We need something like PY_UINT32_T (and co) for portability. The only part of #17884 that's still valid is that it may well make sense to insist that exact-width 32-bit and 64-bit signed and unsigned integer types are available when building Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:11:37 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 27 Feb 2015 21:11:37 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425068936.71.0.920378022888.issue23539@psf.upfronthosting.co.za> Message-ID: <1743B1D9-8CC0-42BE-BF49-4512E20D39EA@gmail.com> Demian Brecht added the comment: > The logic now is as it was before, except that we set a content length of zero if the body is None and the method is one of OPTIONS, PATCH, PUT, or POST. I see we definitely have similar thinking on the modifications required for this, but I don?t think I?m in favour of the approach in the patch. Consider the case where you have a GET request without a body. Now, instead of simply circumventing the _set_content_length method altogether as would have been done previously, the code path will now go into _set_content_length, have a TypeError exception raised on (str(len([None])) and then an AttributeError exception raised on os.fstat([None].fileno()). That seems to be quite a bit of additional overhead when it could be avoided altogether by an earlier check as I have in my example. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:13:19 2015 From: report at bugs.python.org (Rosa Maria) Date: Fri, 27 Feb 2015 21:13:19 +0000 Subject: [issue23543] encoding error trying to save string to file Message-ID: <1425071599.87.0.548743835483.issue23543@psf.upfronthosting.co.za> New submission from Rosa Maria: I made a program to read which files are in a windows folder, and saves in a file in order to print it, but when it tries to write in a file the following error appears: UnicodeEncodeError: 'charmap' codec can't encode character '\u2010' in position 8: character maps to I extpected that being Python-3 an utf8 native, I do'n have this problems. I send the Python script and some examples of files to read. One of the failures example is the file named: 'LKC.6558?100?HD?P?101_C.xlsx\n' which appears in windows as: 'LKC 6558 100 HD P 101_C.xlsx\n' ---------- components: Unicode files: Redear_Carpetotas.py messages: 236841 nosy: Gravitania, ezio.melotti, haypo priority: normal severity: normal status: open title: encoding error trying to save string to file type: crash versions: Python 3.4 Added file: http://bugs.python.org/file38268/Redear_Carpetotas.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:25:35 2015 From: report at bugs.python.org (Andrew Harrington) Date: Fri, 27 Feb 2015 21:25:35 +0000 Subject: [issue23544] Idle stacker viewer crash OSX Message-ID: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za> New submission from Andrew Harrington: 1. In idle 3.4.3, OSX 10.10, active state Tk 8.5.17, starting data: Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 23 2015, 02:52:03) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin 2. start debugger, open very simple demo file, attached: 3. run, so debugger starts, step into main() 4. In debug menu, select Stack Viewer 5. hangs (apple swirling color wheel forever). Same error is repeatable. ---------- components: IDLE files: goodScope.py messages: 236842 nosy: Andrew.Harrington priority: normal severity: normal status: open title: Idle stacker viewer crash OSX type: crash versions: Python 3.4 Added file: http://bugs.python.org/file38269/goodScope.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:31:07 2015 From: report at bugs.python.org (SilentGhost) Date: Fri, 27 Feb 2015 21:31:07 +0000 Subject: [issue23544] Idle stacker viewer crash OSX In-Reply-To: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za> Message-ID: <1425072667.31.0.0868973543572.issue23544@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Macintosh nosy: +kbk, ned.deily, roger.serwy, ronaldoussoren, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:31:54 2015 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 27 Feb 2015 21:31:54 +0000 Subject: [issue23541] Re module's match() fails to halt on a particular input In-Reply-To: <1425068315.25.0.0642664750871.issue23541@psf.upfronthosting.co.za> Message-ID: <1425072714.92.0.317321544351.issue23541@psf.upfronthosting.co.za> Matthew Barnett added the comment: The problem is with the "(\w+\s*)+". \s* can match an empty string, so when matching a word it's like "(\w+)+". If you have n letters, there are 2**n ways it could match, and if what follows never matches, it'll try all of them. It _will_ finish, eventually... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:36:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Feb 2015 21:36:06 +0000 Subject: [issue23543] encoding error trying to save string to file In-Reply-To: <1425071599.87.0.548743835483.issue23543@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Please provide the full traceback. The error can come from a lot of functions. Which function fails? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:37:39 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Feb 2015 21:37:39 +0000 Subject: [issue23512] The list of built-in http://text-processing.com/demo/sentiments is not alphabetical on https://docs.python.org/2/library/functions.html In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za> Message-ID: <1425073059.62.0.0375650639262.issue23512@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The table was deliberately created as it is and I think it should be left as is. Those four functions appear 'out of order' in a separate section "3. Non-essential Built-in Functions". ---------- nosy: +terry.reedy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:40:55 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Feb 2015 21:40:55 +0000 Subject: [issue23520] test_os failed (python-3.4.3, Linux SuSE) In-Reply-To: <1424871003.6.0.446487630162.issue23520@psf.upfronthosting.co.za> Message-ID: <1425073255.39.0.502625413357.issue23520@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: test_os failed (python-3.4.3) -> test_os failed (python-3.4.3, Linux SuSE) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:43:18 2015 From: report at bugs.python.org (Edward D'Souza) Date: Fri, 27 Feb 2015 21:43:18 +0000 Subject: [issue23512] The list of built-in http://text-processing.com/demo/sentiments is not alphabetical on https://docs.python.org/2/library/functions.html In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za> Message-ID: <1425073398.37.0.111607041167.issue23512@psf.upfronthosting.co.za> Edward D'Souza added the comment: Doesn't make sense to me. The page says "They are listed here in alphabetical order.", which isn't true. Furthermore, not putting them in order screws up people who assume it is in alphabetical order and try to search for a function with their eyes. If they are so special, put them in a separate table. This inconsistency is simply disrespectful to the reader, IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:47:40 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Feb 2015 21:47:40 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425073660.16.0.160942093155.issue23539@psf.upfronthosting.co.za> Martin Panter added the comment: I like Demian?s ?expecting_len? technique slightly better because it would avoid calling None.fileno() and len(None), as Demian just said. Also, I think OPTIONS should be removed from the list of methods that enforce a Content-Length. I wouldn?t normally expect any payload for OPTIONS, since RFC 7231 explicitly says it does not define a use for a payload, but requires a Content-Type if a payload is sent. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:55:25 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 27 Feb 2015 21:55:25 +0000 Subject: [issue23544] IDLE hangs with debug on and stack viewer In-Reply-To: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za> Message-ID: <1425074125.14.0.0243514614488.issue23544@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the detailed report. The problem is more general as it is reproducible on Linux X11-based IDLEs as well. ---------- components: -Macintosh nosy: -ronaldoussoren title: Idle stacker viewer crash OSX -> IDLE hangs with debug on and stack viewer versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 22:56:09 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 27 Feb 2015 21:56:09 +0000 Subject: [issue23544] IDLE hangs with debug on and stack viewer In-Reply-To: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za> Message-ID: <1425074169.8.0.0213014861576.issue23544@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 23:02:16 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 27 Feb 2015 22:02:16 +0000 Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create tz aware datetime In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za> Message-ID: <1425074536.6.0.661268159615.issue22791@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I like Akira's documentation patch. Will apply unless hear objections from documentation folks. ---------- assignee: -> belopolsky components: +Documentation -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 23:09:59 2015 From: report at bugs.python.org (James Rutherford) Date: Fri, 27 Feb 2015 22:09:59 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425074999.52.0.0168811265087.issue23539@psf.upfronthosting.co.za> James Rutherford added the comment: The first patch should actually be modified so the condition reads (update attached): if body is None and method_expects_body: thelen = 0 elif body is not None: ... Demian, I believe this is equivalent to your 'expecting_len' proposal, I've just put the logic inside _set_content_length. My approach was to leave as much existing logic as possible in place to avoid the introduction of new bugs (first patch wasn't entirely successful in this!). As for OPTION, If the OPTIONS request includes a message-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. >From http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#section-7.2 ---------- Added file: http://bugs.python.org/file38270/issue23539-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 23:29:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Feb 2015 22:29:44 +0000 Subject: [issue23545] Turn on extra warnings on GCC Message-ID: <1425076183.98.0.20319163057.issue23545@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: What if make GCC emit extra warnings? Adding following options: -Wall -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers will make GCC emit all warnings except few types that would produce too many warnings. With these options the compilation is almost clean on 32-bit Linux. ---------- components: Build messages: 236851 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Turn on extra warnings on GCC type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 23:42:56 2015 From: report at bugs.python.org (Carlo Beccarini) Date: Fri, 27 Feb 2015 22:42:56 +0000 Subject: [issue23512] The list of built-in http://text-processing.com/demo/sentiments is not alphabetical on https://docs.python.org/2/library/functions.html In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za> Message-ID: <1425076976.87.0.692821146706.issue23512@psf.upfronthosting.co.za> Carlo Beccarini added the comment: Maybe we could put them in another table below the current one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 27 23:49:04 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 27 Feb 2015 22:49:04 +0000 Subject: [issue23544] IDLE hangs when selecting Stack View with debug active In-Reply-To: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za> Message-ID: <1425077344.51.0.944257309725.issue23544@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Verified on Windows whenever the debugger is active, meaning that a program is running. (Debug On just means that it will become active when code is run.) No stepping is needed; debugger can be pointing to the inital docstring line. For me also, Idle stops and has to be externally closed, as opposed to totally disappearing by itself. The doc for Stack Viewer says "Show the stack traceback of the last exception". Example: >>> 1/0 Traceback (most recent call last): File "", line 1, in 1/0 ZeroDivisionError: division by zero >>> Selecting Stack Viewer pops up a viewer box. This still works after [DEBUG ON] >>> turns the debugger on but inactive. Entering anything at the prompt disables viewing the 'last' exception, contrary to my understanding of the short doc. So I might add '(if no other code has been run)' to the doc. Selecting Stack Viewer while a program is running (sleeping in this next example) >>> import time; time.sleep(10); 1/0 brings up a box after the exception is printed. So 'last exception' can actually be 'next exception'. But in this case, the user process is left 'running' and no '>>> ' prompt appears, and one must Shell -> Restart to do anything further. This is not good behavior. When one selects Debug -> Debugger while user code is running, Idle brings up a message box "Don't debug now: You can only toggle the debugger when idle". I think Debug -> Stack Viewer should be similarly disabled, though perhaps graying out the menu entry might be better. It could also be grayed out when there the 'last exception' cannot be viewed because other code has been run. Stack Viewer should definitely be ignored when the debugger is active, and I see no need to let people select it *before* an exception occurs and the prompt is displayed. The next menu entry, Auto-open Stack Viewer, takes care of opening upon future exceptions. ---------- stage: -> needs patch title: IDLE hangs with debug on and stack viewer -> IDLE hangs when selecting Stack View with debug active _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 00:12:23 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 27 Feb 2015 23:12:23 +0000 Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za> Message-ID: <1425078743.88.0.904805317241.issue22853@psf.upfronthosting.co.za> Davin Potts added the comment: Confirmed that the issue can be reproduced under 2.7.9 on OS X 10.10. It is not possible to reproduce the issue with default (3.5) -- taking a look at what's different there, notably the import of is_exiting has moved to the top of the queues module and is no longer only imported at the time Queue._feed is invoked, which is just as Florian advocates doing for 2.7. I should take a closer look to understand what else has changed. @Mark: Cool -- thanks. ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 00:19:13 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 27 Feb 2015 23:19:13 +0000 Subject: [issue23538] New Windows installer in 3.5.0a1 breaks compatibility with Wine In-Reply-To: <1425058127.83.0.0230104914567.issue23538@psf.upfronthosting.co.za> Message-ID: <1425079153.28.0.681930810788.issue23538@psf.upfronthosting.co.za> Steve Dower added the comment: Yeah, I don't get anything helpful out of that, except that it seems wine hasn't implemented some of the APIs that it needs to run the installer. You may get a more helpful response from one of their devs, but I'm well out of my depth sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 00:19:16 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Feb 2015 23:19:16 +0000 Subject: [issue23543] encoding error trying to save string to file In-Reply-To: <1425071599.87.0.548743835483.issue23543@psf.upfronthosting.co.za> Message-ID: <1425079156.35.0.150826471674.issue23543@psf.upfronthosting.co.za> Martin Panter added the comment: Python 3 will only use UTF-8 encoding if you ask it to, or if the default locale encoding happens to be UTF-8. I suspect one of the file names in the ?hay? list must contain a Unicode hyphen (U+2010), and your default encoding is some single byte encoding that cannot encode the hyphen. If you definitely want to write a UTF-8 file, use the open(encoding="utf-8") parameter. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 00:25:51 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 27 Feb 2015 23:25:51 +0000 Subject: [issue23512] The list of built-in functions is not alphabetical on https://docs.python.org/2/library/functions.html In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za> Message-ID: <1425079551.51.0.0458388963789.issue23512@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: The list of built-in http://text-processing.com/demo/sentiments is not alphabetical on https://docs.python.org/2/library/functions.html -> The list of built-in functions is not alphabetical on https://docs.python.org/2/library/functions.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 00:26:51 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Fri, 27 Feb 2015 23:26:51 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425079611.03.0.0381106094342.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Ok, if I don't finish it today, I *will* finish it tomorrow. Or Sunday. Sunday is the latest, though I'm pretty sure I'll be done by Saturday. Hardest part is likely going to be re-configuring the Android emulator to test it. Cyd (and anyone else who can), do you think you could test the binaries, too? I'll get them to you somehow. You have a real device; I have an old real device and an emulator. Side note for Cyd: I'd advise you just use the fork of CPython you have and just push them to GitHub: $ git remote add origin $ git push --all origin -u That will push your changes (and every branch of CPython, I have no clue what your branch name is, so this just does everything) to the GitHub mirror. So...I'm understanding that the game plan will go like this: - Cyd pushes the changes he made to a GitHub fork of Python (and hopefully posts the URL here ;) - I clone the repo and try to get the changes working with the dev version - Somewhere in between now and the end of the world, Ethan will set up a build slave I'll also help all I can with keeping these changes working with future versions of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 00:36:28 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 27 Feb 2015 23:36:28 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425080188.77.0.900888652656.issue23496@psf.upfronthosting.co.za> Ethan Furman added the comment: Yup, that sounds right! ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 00:57:26 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 27 Feb 2015 23:57:26 +0000 Subject: [issue23254] Document how to close the TCPServer listening socket In-Reply-To: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za> Message-ID: <1425081446.45.0.700938898787.issue23254@psf.upfronthosting.co.za> Martin Panter added the comment: Posting server_close.v2.patch, which tests fileno(), and uses a single space between the new sentences. Also added a bit to the how-to at the top (using doubly-spaced sentences to match the rest of the paragraph). ---------- Added file: http://bugs.python.org/file38271/server_close.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 01:53:28 2015 From: report at bugs.python.org (Demian Brecht) Date: Sat, 28 Feb 2015 00:53:28 +0000 Subject: [issue23254] Document how to close the TCPServer listening socket In-Reply-To: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za> Message-ID: <1425084808.76.0.720858978598.issue23254@psf.upfronthosting.co.za> Demian Brecht added the comment: LGTM. I'm not sure whether or not it's eligible for 3.4 though as it's a documentation and not a functional fix. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 01:54:29 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Feb 2015 00:54:29 +0000 Subject: [issue23528] Limit decompressed data when reading from GzipFile In-Reply-To: <1424946126.98.0.486244279604.issue23528@psf.upfronthosting.co.za> Message-ID: <1425084869.36.0.228935169761.issue23528@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps we should move the discussion of a common base class to Issue 23529. I only opened this as a separate issue because I thought it might be appropriate as a bug fix for 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 01:59:32 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Feb 2015 00:59:32 +0000 Subject: [issue23529] Limit decompressed data when reading from LZMAFile and BZ2File In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za> Message-ID: <1425085172.59.0.886668222222.issue23529@psf.upfronthosting.co.za> Martin Panter added the comment: ## BufferedReader.peek() ## See , but basically my concern is that the documentation says ?the number of bytes returned may be less or more than requested?, without any mention of EOF or other conditions. ## Buffer sizing ## In the code review, Nikolaus raised the idea of allowing a custom ?buffer_size? parameter for the BufferedReader. I think this would need a bit of consideration about how it should work: 1. Should it be a direct wrapper around BufferedReader(buffer_size=...)? 2. Should it also support an unbuffered reader mode like open(buffering=0), socket.makefile(buffering=0), and subprocess.Popen(bufsize=0)? 3. Should there be any consideration for buffering in write mode (mirroring the equivalent open(), etc parameters)? ## Common raw decompression stream class ## Having a common base class mapping the generic decompressor object API to the RawIOBase API is a good thing. I will try to make one in my next patch iteration. In the mean time, here are a couple of issues to consider: * What module should it reside in? Perhaps ?gzip?, because it is the most commonly-used of the three decompressors? Perhaps ?io?, being the most relevant common dependency? Or a brand new internal module?! * The zlib.decompressobj() API is slightly different, since it has the ?unconsumed_tail? attribute and flush() methods, and decompress(max_length=0) does not mean return zero bytes (Issue 23200). In Issue 23528, Nikolaus also pointed out that ?GzipFile would need to additionally overwrite read() and write() in order to handle the CRC and gzip header.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 02:24:44 2015 From: report at bugs.python.org (Demian Brecht) Date: Sat, 28 Feb 2015 01:24:44 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425086684.07.0.173769602199.issue23539@psf.upfronthosting.co.za> Demian Brecht added the comment: > Also, I think OPTIONS should be removed from the list of methods that enforce a Content-Length. I wouldn?t normally expect any payload for OPTIONS, since RFC 7231 explicitly says it does not define a use for a payload, but requires a Content-Type if a payload is sent. I think Martin's right about this and it's consistent with my concern about servers treating the existence of a Content-Length header as an indicator of a request body. In any event, with the new logic, a Content-Length header will be added if the body is not None. > I've just put the logic inside _set_content_length Fair enough. It /does/ encapsulate all logic around setting the content length within the method. I've left a couple minor comments in Rietveld. In addition to what's there, docs should also be updated to reflect the new behaviour. Thanks for the work on this! ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 02:39:21 2015 From: report at bugs.python.org (Andrew Harrington) Date: Sat, 28 Feb 2015 01:39:21 +0000 Subject: [issue23544] IDLE hangs when selecting Stack View with debug active In-Reply-To: <1425077344.51.0.944257309725.issue23544@psf.upfronthosting.co.za> Message-ID: Andrew Harrington added the comment: I was using this without looking at documentation, as a newbies would. Graying and disabling until after an exception makes sense, but even the menu item name is misleading: any time the program is running there is a stack that you might want to view. Better labels in the menu than "Stack Viewer" would be "stack trace" or "stack after exception" (maybe too long) or "stack after crash". On Fri, Feb 27, 2015 at 4:49 PM, Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > Verified on Windows whenever the debugger is active, meaning that a > program is running. (Debug On just means that it will become active when > code is run.) No stepping is needed; debugger can be pointing to the inital > docstring line. For me also, Idle stops and has to be externally closed, > as opposed to totally disappearing by itself. > > The doc for Stack Viewer says "Show the stack traceback of the last > exception". Example: > > >>> 1/0 > Traceback (most recent call last): > File "", line 1, in > 1/0 > ZeroDivisionError: division by zero > >>> > > Selecting Stack Viewer pops up a viewer box. This still works after > [DEBUG ON] > >>> > turns the debugger on but inactive. Entering anything at the prompt > disables viewing the 'last' exception, contrary to my understanding of the > short doc. So I might add '(if no other code has been run)' to the doc. > > Selecting Stack Viewer while a program is running (sleeping in this next > example) > > >>> import time; time.sleep(10); 1/0 > > brings up a box after the exception is printed. So 'last exception' can > actually be 'next exception'. But in this case, the user process is left > 'running' and no '>>> ' prompt appears, and one must Shell -> Restart to do > anything further. This is not good behavior. > > When one selects Debug -> Debugger while user code is running, Idle brings > up a message box "Don't debug now: You can only toggle the debugger when > idle". I think Debug -> Stack Viewer should be similarly disabled, though > perhaps graying out the menu entry might be better. It could also be grayed > out when there the 'last exception' cannot be viewed because other code has > been run. Stack Viewer should definitely be ignored when the debugger is > active, and I see no need to let people select it *before* an exception > occurs and the prompt is displayed. The next menu entry, Auto-open Stack > Viewer, takes care of opening upon future exceptions. > > ---------- > stage: -> needs patch > title: IDLE hangs with debug on and stack viewer -> IDLE hangs when > selecting Stack View with debug active > > _______________________________________ > Python tracker > > _______________________________________ > -- Dr. Andrew N. Harrington Computer Science Department Graduate Program Director gpd at cs.luc.edu Loyola University Chicago 529 Lewis Tower, 111 E. Pearson St. (Downtown) 104 Loyola Hall, 1032 W. Sheridan Road (Rogers Park) http://www.cs.luc.edu/~anh Phone: 312-915-7982 Fax: 312-915-7998 aharrin at luc.edu (as professor, not gpd role) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 06:40:50 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 28 Feb 2015 05:40:50 +0000 Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za> Message-ID: <1425102050.11.0.629187083783.issue22853@psf.upfronthosting.co.za> Davin Potts added the comment: Attaching a patch for 2.7 that applies Florian's fix and provides a test for it as well. Although the issue is not triggered on 3.4 or default (3.5), there is the potential for regression there -- attaching a single patch that works for both 3.4 and 3.5 to provide a regression test (only a test, nothing to "fix"). These patches have been tested on OS X 10.10 and Ubuntu 12.04.5 64-bit for each of 2.7, 3.4, and default (3.5). ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file38272/issue_22853_fix_and_test_import_lock_in_queue_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 06:41:35 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 28 Feb 2015 05:41:35 +0000 Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za> Message-ID: <1425102095.7.0.422738191783.issue22853@psf.upfronthosting.co.za> Changes by Davin Potts : Added file: http://bugs.python.org/file38273/issue_22853_only_test_import_lock_in_queue_py34_and_py35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 06:48:30 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 28 Feb 2015 05:48:30 +0000 Subject: [issue23254] Document how to close the TCPServer listening socket In-Reply-To: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za> Message-ID: <1425102510.23.0.191183570161.issue23254@psf.upfronthosting.co.za> R. David Murray added the comment: In general documentation changes go in all maintained versions (ie: right now that would be 2.7, 3.4, and default/3.5). The only exception, really, would be if the change didn't apply to one or more of the versions because of code differences. (Note: I haven't reviewed the patch itself yet ;) ---------- nosy: +r.david.murray versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 06:51:26 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 28 Feb 2015 05:51:26 +0000 Subject: [issue23525] isbuiltin, isroutine, etc. In-Reply-To: <1424930605.81.0.317229186778.issue23525@psf.upfronthosting.co.za> Message-ID: <1425102686.55.0.16585198607.issue23525@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 07:00:51 2015 From: report at bugs.python.org (eryksun) Date: Sat, 28 Feb 2015 06:00:51 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1425103251.84.0.769772130826.issue23530@psf.upfronthosting.co.za> eryksun added the comment: > Well, we already expose CPU affinity: > > >>> import os > >>> os.sched_getaffinity(0) > {0} os.sched_getaffinity only exists on some POSIX systems, such as Linux. For Windows, here's a ctypes version of sched_getaffinity and sched_setaffinity: import sys from ctypes import * from ctypes.wintypes import * __all__ = ['sched_getaffinity', 'sched_setaffinity'] kernel32 = WinDLL('kernel32') DWORD_PTR = WPARAM PDWORD_PTR = POINTER(DWORD_PTR) GetCurrentProcess = kernel32.GetCurrentProcess GetCurrentProcess.restype = HANDLE OpenProcess = kernel32.OpenProcess OpenProcess.restype = HANDLE OpenProcess.argtypes = (DWORD, # dwDesiredAccess,_In_ BOOL, # bInheritHandle,_In_ DWORD) # dwProcessId, _In_ GetProcessAffinityMask = kernel32.GetProcessAffinityMask GetProcessAffinityMask.argtypes = ( HANDLE, # hProcess, _In_ PDWORD_PTR, # lpProcessAffinityMask, _Out_ PDWORD_PTR) # lpSystemAffinityMask, _Out_ SetProcessAffinityMask = kernel32.SetProcessAffinityMask SetProcessAffinityMask.argtypes = ( HANDLE, # hProcess, _In_ DWORD_PTR) # dwProcessAffinityMask, _In_ PROCESS_SET_INFORMATION = 0x0200 PROCESS_QUERY_INFORMATION = 0x0400 PROCESS_QUERY_LIMITED_INFORMATION = 0x1000 if sys.getwindowsversion().major < 6: PROCESS_QUERY_LIMITED_INFORMATION = PROCESS_QUERY_INFORMATION def sched_getaffinity(pid): if pid == 0: hProcess = GetCurrentProcess() else: hProcess = OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, False, pid) if not hProcess: raise WinError() lpProcessAffinityMask = DWORD_PTR() lpSystemAffinityMask = DWORD_PTR() if not GetProcessAffinityMask(hProcess, byref(lpProcessAffinityMask), byref(lpSystemAffinityMask)): raise WinError() mask = lpProcessAffinityMask.value return {c for c in range(sizeof(DWORD_PTR) * 8) if (1 << c) & mask} def sched_setaffinity(pid, mask): if pid == 0: hProcess = GetCurrentProcess() else: hProcess = OpenProcess(PROCESS_SET_INFORMATION, False, pid) if not hProcess: raise WinError() bitmask = 0 for cpu in mask: if not isinstance(cpu, int): raise TypeError('expected an iterator of ints, but ' 'iterator yielded %r' % type(cpu)) if cpu < 0: raise ValueError('negative CPU number') if cpu >= sizeof(DWORD_PTR) * 8: raise ValueError('CPU number too large') bitmask |= 1 << cpu if not SetProcessAffinityMask(hProcess, bitmask): raise WinError() ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 07:14:01 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 28 Feb 2015 06:14:01 +0000 Subject: [issue23138] cookiejar parses cookie value as int with empty name-value pair and Expires In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za> Message-ID: <1425104041.26.0.610389574768.issue23138@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 07:59:45 2015 From: report at bugs.python.org (Georg Brandl) Date: Sat, 28 Feb 2015 06:59:45 +0000 Subject: [issue23512] The list of built-in functions is not alphabetical on https://docs.python.org/2/library/functions.html In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za> Message-ID: <1425106785.82.0.1719813005.issue23512@psf.upfronthosting.co.za> Georg Brandl added the comment: I agree with Edward. The table makes no distinction between the two group of builtins, so it is confusing why it would list them not in alphabetical order. I wouldn't go so far as to call it "disrespectful" though :) ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 08:05:26 2015 From: report at bugs.python.org (miles) Date: Sat, 28 Feb 2015 07:05:26 +0000 Subject: [issue23382] Maybe can not shutdown ThreadPoolExecutor when call the method of shutdown In-Reply-To: <1422951603.17.0.63584283635.issue23382@psf.upfronthosting.co.za> Message-ID: <1425107126.87.0.735313004987.issue23382@psf.upfronthosting.co.za> miles added the comment: The attachment includes the patch file ---------- keywords: +patch nosy: +milesli Added file: http://bugs.python.org/file38274/thread.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 08:59:27 2015 From: report at bugs.python.org (Liam Marsh) Date: Sat, 28 Feb 2015 07:59:27 +0000 Subject: [issue23546] windows, IDLE and pep 397 Message-ID: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za> New submission from Liam Marsh: hello, pep 397 describes a "Python launcher for the Windows platform. A Python launcher is a single executable which uses a number of heuristics to locate a Python executable and launch it with a specified command line." Problem: that affects only the "open" file action behavior, and not the "EDIT with idle" file action behavior, and then it is the last installed IDLE who wins. the problem is not the IDLE changes themselves, but that one version's IDLE can only run the edited script in its version, and ignoring the shebang. Could the windows installer install a third executable (for ex: pyi.exe) which launch the correct IDLE according to the shebang line of the edited file? Or maybe it should be done using "pyw.exe /edit "... Than you for reading this and have a nice day/evening! ---------- components: IDLE, Windows messages: 236870 nosy: Liam.Marsh, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: windows, IDLE and pep 397 type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 09:58:29 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 28 Feb 2015 08:58:29 +0000 Subject: [issue23546] windows, IDLE and pep 397 In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za> Message-ID: <1425113909.92.0.854044126913.issue23546@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Installation versions: -Python 2.7, Python 3.2, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 10:04:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 09:04:24 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1425114264.46.0.0327454809156.issue20204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What type of warning is more preferable here? It will be emitted at import. E.g.: $ ./python -Wall Python 3.5.0a1+ (default:28ba862036cc+, Feb 28 2015, 11:01:23) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import tkinter _frozen_importlib:321: SyntaxWarning: builtin type tkapp has no the __module__ attribute _frozen_importlib:321: SyntaxWarning: builtin type tktimertoken has no the __module__ attribute DeprecationWarning? RuntimeWarning? ---------- nosy: +ezio.melotti priority: high -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 10:22:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 09:22:10 +0000 Subject: [issue23304] Unused Superclass in calendar.py In-Reply-To: <1421963210.26.0.700938779083.issue23304@psf.upfronthosting.co.za> Message-ID: <1425115330.3.0.683090941938.issue23304@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 10:27:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 09:27:28 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1425115648.98.0.617976689434.issue23458@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 10:42:45 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 28 Feb 2015 09:42:45 +0000 Subject: [issue23528] Limit decompressed data when reading from GzipFile In-Reply-To: <1424946126.98.0.486244279604.issue23528@psf.upfronthosting.co.za> Message-ID: <1425116565.42.0.65080352251.issue23528@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 10:42:51 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 28 Feb 2015 09:42:51 +0000 Subject: [issue23529] Limit decompressed data when reading from LZMAFile and BZ2File In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za> Message-ID: <1425116571.33.0.326898928076.issue23529@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 11:08:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 10:08:19 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1425118099.89.0.371407796769.issue23521@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 11:23:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 10:23:44 +0000 Subject: [issue21619] Cleaning up a subprocess with a broken pipe In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za> Message-ID: <1425119024.2.0.869863217842.issue21619@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 11:46:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 28 Feb 2015 10:46:47 +0000 Subject: [issue21619] Cleaning up a subprocess with a broken pipe In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za> Message-ID: <20150228104644.16406.10498@psf.io> Roundup Robot added the comment: New changeset b5e9ddbdd4a7 by Serhiy Storchaka in branch '3.4': Issue #21619: Popen objects no longer leave a zombie after exit in the with https://hg.python.org/cpython/rev/b5e9ddbdd4a7 New changeset cdac249808a8 by Serhiy Storchaka in branch 'default': Issue #21619: Popen objects no longer leave a zombie after exit in the with https://hg.python.org/cpython/rev/cdac249808a8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 11:48:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 10:48:01 +0000 Subject: [issue21619] Cleaning up a subprocess with a broken pipe In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za> Message-ID: <1425120481.26.0.961701146623.issue21619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Martin. ---------- resolution: -> fixed stage: patch review -> resolved type: -> resource usage versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 11:49:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 10:49:36 +0000 Subject: [issue21619] Cleaning up a subprocess with a broken pipe In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za> Message-ID: <1425120576.06.0.916768651481.issue21619@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 11:50:07 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Feb 2015 10:50:07 +0000 Subject: [issue21619] Cleaning up a subprocess with a broken pipe In-Reply-To: <1425120481.26.0.961701146623.issue21619@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Why not ignoring BrokenPipeError like communicate()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 12:21:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 11:21:34 +0000 Subject: [issue23062] test_argparse --version test cases In-Reply-To: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za> Message-ID: <1425122494.63.0.228785681513.issue23062@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why the test class is moved? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 12:28:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 28 Feb 2015 11:28:56 +0000 Subject: [issue21619] Cleaning up a subprocess with a broken pipe In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za> Message-ID: <20150228112853.77542.34496@psf.io> Roundup Robot added the comment: New changeset 1b4d916329e7 by Serhiy Storchaka in branch '3.4': Fixed a test for issue #21619 on Windows. https://hg.python.org/cpython/rev/1b4d916329e7 New changeset eae459e35cb9 by Serhiy Storchaka in branch 'default': Fixed a test for issue #21619 on Windows. https://hg.python.org/cpython/rev/eae459e35cb9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 12:33:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 11:33:06 +0000 Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za> Message-ID: <1425123186.09.0.996743774709.issue23088@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be mention that the result of PyUnicode_AsUTF8() can contain null bytes? And the same for PyBytes_AS_STRING()/PyBytes_AsString()? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 12:44:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 28 Feb 2015 11:44:43 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1425123883.9.0.747160850662.issue20204@psf.upfronthosting.co.za> Nick Coghlan added the comment: The case for RuntimeWarning: the object isn't necessarily *broken* as such (most things will still work), but pickling and some introspection features may not work properly. The case for DeprecationWarning: breaking picking and introspection is bad when the fix (setting __module__) is straightforward, so this should eventually become an AttributeError: AttributeError: __module__ not set on builtin type tkapp My own preference is for the latter - eventually making it a hard requirement to specify the module name properly. Even true builtins officially live in the builtins module: >>> str.__module__ 'builtins' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 13:00:51 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 28 Feb 2015 12:00:51 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1425124851.13.0.0055077947299.issue17576@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, something appears to have gotten confused along the way here. Barry's original problem report was that operator.index() was returning a different answer than operator.__index__() for int subclasses. Absolutely nothing to do with the int builtin at all. While the fact int() *may* return int subclasses isn't especially good, it's also a longstanding behaviour. The problem Barry reports, where a subclassing based proxy type isn't reverting to a normal integer when accessed via operator.index() despite defining __index__() to do exactly that should be possible to fix just by applying the stricter check specifically in PyNumber_Index. Expanding the scope to cover __int__() and __trunc__() as well would be much, much hairier, as those are much older interfaces, and used in a wider variety of situations. We specifically invented __index__() to stay away from that mess while making it possible to explicitly indicate that a type supports a lossless conversion to int rather than a potentially lossy one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 13:06:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 12:06:47 +0000 Subject: [issue22341] Python 3 crc32 documentation clarifications In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za> Message-ID: <1425125207.68.0.222089616127.issue22341@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: crc & 0xffffffff is still used in gzip, zipfile and tarfile. And some comments say about signess of 32-bit checksums. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 13:08:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 12:08:49 +0000 Subject: [issue23200] Clarify max_length and flush() for zlib decompression In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> Message-ID: <1425125329.21.0.841156256057.issue23200@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +nadeem.vawda stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 14:31:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 13:31:34 +0000 Subject: [issue22350] nntplib file write failure causes exception from QUIT command In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za> Message-ID: <1425130294.62.0.351445271332.issue22350@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 14:34:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 13:34:48 +0000 Subject: [issue23247] Multibyte codec StreamWriter.reset() crashes In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1425130488.62.0.95195667584.issue23247@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 14:35:25 2015 From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgQXR0aWxhIFTDs3Ro?=) Date: Sat, 28 Feb 2015 13:35:25 +0000 Subject: [issue13966] Add disable_interspersed_args() to argparse.ArgumentParser In-Reply-To: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za> Message-ID: <1425130525.93.0.22791391536.issue13966@psf.upfronthosting.co.za> L?szl? Attila T?th added the comment: It seems I found the solution in the attached file argparse.disable_interspersed_args.python35.diff, and it's much-much easier than I thought. I assume that this patch can cleanly applied to earlier versions (python 3.2-3.4), but I didn't check it. ---------- versions: +Python 3.2, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38275/argparse.disable_interspersed_args.python35.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 14:37:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 13:37:26 +0000 Subject: [issue23231] Fix codecs.iterencode/decode() by allowing data parameter to be omitted In-Reply-To: <1421153299.35.0.701583632763.issue23231@psf.upfronthosting.co.za> Message-ID: <1425130646.99.0.602540623124.issue23231@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 14:43:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 13:43:59 +0000 Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments disappeared In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za> Message-ID: <1425131039.56.0.374617155943.issue23391@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review nosy: +pitrou stage: -> patch review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 14:57:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 13:57:49 +0000 Subject: [issue23411] Update urllib.parse.__all__ In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> Message-ID: <1425131869.84.0.844533063615.issue23411@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 15:01:00 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 28 Feb 2015 14:01:00 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425132060.1.0.00356255418576.issue23496@psf.upfronthosting.co.za> Stefan Krah added the comment: > I wouldn't know if they're reported to the same bug tracker...it's possible they aren't. Well, why don't you try? :) > Additionally it's possible that the lack of locale support in libc isn't considered a bug. Their "struct lconv" violates both the C standard and POSIX. It is 100% a bug. Lack of locale support would be defensible, shipping a broken localeconv() isn't. I'm just furious that 20+ OSS projects go out of their way to work around this trivial bug. It's a waste of resources. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 15:04:27 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sat, 28 Feb 2015 14:04:27 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425132267.61.0.785937231172.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: >Well, why don't you try? :) Resource optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 15:06:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 14:06:50 +0000 Subject: [issue23411] Update urllib.parse.__all__ In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> Message-ID: <1425132410.45.0.842969274686.issue23411@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Exposed classes are the types of results returned by urllib.parse functions. It is very unlikely that they will be directly used by the user. I see the only benefit of adding these class to __all__ that they will become visible for pydoc. Is it worth to apply the patch to maintained releases or to 3.5 only? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 15:10:24 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 28 Feb 2015 14:10:24 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425132624.43.0.160423548195.issue23496@psf.upfronthosting.co.za> Stefan Krah added the comment: Fine, I'm also optimizing and the "fix" isn't going into libmpdec. Android can use the Python version of decimal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 15:20:10 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 28 Feb 2015 14:20:10 +0000 Subject: [issue23545] Turn on extra warnings on GCC In-Reply-To: <1425076183.98.0.20319163057.issue23545@psf.upfronthosting.co.za> Message-ID: <1425133210.3.0.0805394698947.issue23545@psf.upfronthosting.co.za> Stefan Krah added the comment: +1. I think the flags should go into CFLAGS_NODIST. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 15:24:13 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 28 Feb 2015 14:24:13 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1425133453.81.0.627704724153.issue20305@psf.upfronthosting.co.za> Stefan Krah added the comment: Consider the libmpdec part rejected. It is too much work given that external libmpdecs need to be compatible and Android can use the Python version of decimal. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 15:36:25 2015 From: report at bugs.python.org (Michael Bevilacqua-Linn) Date: Sat, 28 Feb 2015 14:36:25 +0000 Subject: [issue23547] Engineering at Google in 2015 In-Reply-To: Message-ID: New submission from Michael Bevilacqua-Linn: Hey thanks so much for reaching out! I'm not really interested in leaving Philly or my current job at the moment though... Thanks! MBL On Fri, Feb 27, 2015 at 4:48 AM, Margaret O'Reilly wrote: > Hi Michael, > > I hope you are well. > > > My name is Margaret and I am part of the Google Technical Recruiting > team. I tried reaching you about a month ago and just wanted to check back > in to see if you might be interested in exploring a potential engineering > role at Google? > > With your experience and our current open roles, we may have a role that?s > a good fit for you. If you are interested in hearing more, please let me > know :-) > > > If however this isn?t something you?re interested in, just let me know and > we?ll be sure not to spam. > > > Thanks and looking forward to your response. > > > Regards, > > > Margaret. > > > > > On Thu, Jan 29, 2015 at 10:58 AM, Margaret O'Reilly > wrote: > >> Hi Michael, >> >> I hope all is well. My name is Margaret and I am currently working with >> Google's Recruitment team. I found your profile online and you interest and >> experience in building scalable distributed systems caught my eye as we >> have a team in Google which I think would be a great match for you! >> >> I know my colleague Derrick got in touch with you in 2014 and relocation >> wasn't an option. I wanted to get back in touch again to see if now might >> be a more convenient time perhaps? If so, I would be delighted to hear from >> you and I'll happily arrange a call at your convenience! >> >> Thanks and looking forward to hearing from you! >> >> Kind Regards, >> >> Margaret >> >> Paxos Made Live - An Engineering Perspective >> >> Bigtable: A Distributed Storage System for Structured Data >> >> > > > > -- > Best Regards, > > Margaret > > Margaret O' Reilly | Technical Sourcer | margaretor at google.com | +353 1 > 519 3003 > ---------- messages: 236889 nosy: Michael.Bevilacqua-Linn priority: normal severity: normal status: open title: Engineering at Google in 2015 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 15:51:10 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 28 Feb 2015 14:51:10 +0000 Subject: [issue23547] Engineering at Google in 2015 In-Reply-To: Message-ID: <1425135070.05.0.500573773633.issue23547@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 16:02:16 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 28 Feb 2015 15:02:16 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1425135736.83.0.636397566376.issue23521@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- stage: needs patch -> commit review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 16:07:25 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sat, 28 Feb 2015 15:07:25 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425136045.57.0.118006610897.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: >Fine, I'm also optimizing and the "fix" isn't going into libmpdec. >Android can use the Python version of decimal. Er, ok. Not entirely sure what this means, mostly because the handful of spare cycles not allocated to a) getting a fork up, running and patched b) learning git on the fly for a) c) porting spidermonkey (why I ported Python) and d) learning Python, are already dedicated to other projects. And work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 16:27:35 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 28 Feb 2015 15:27:35 +0000 Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc In-Reply-To: <1423675815.31.0.721977402363.issue23446@psf.upfronthosting.co.za> Message-ID: <1425137255.84.0.343074317752.issue23446@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 16:27:54 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 28 Feb 2015 15:27:54 +0000 Subject: [issue23490] allocation (and overwrite) of a 0 byte buffer In-Reply-To: <1424434009.7.0.146767591235.issue23490@psf.upfronthosting.co.za> Message-ID: <1425137274.28.0.492189063325.issue23490@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 16:42:58 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 28 Feb 2015 15:42:58 +0000 Subject: [issue17140] Document multiprocessing.pool.ThreadPool In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1425138178.57.0.0867548857301.issue17140@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 16:46:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 28 Feb 2015 15:46:11 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <20150228154608.19160.24923@psf.io> Roundup Robot added the comment: New changeset 8fe15bf68522 by Alexander Belopolsky in branch '3.4': Fixes #23521: Corrected pure python implementation of timedelta division. https://hg.python.org/cpython/rev/8fe15bf68522 New changeset d783132d72bc by Alexander Belopolsky in branch 'default': Fixes #23521: Corrected pure python implementation of timedelta division. https://hg.python.org/cpython/rev/d783132d72bc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 16:48:52 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 28 Feb 2015 15:48:52 +0000 Subject: [issue23521] OverflowError from timedelta * float in datetime.py In-Reply-To: <1424883947.81.0.425363902916.issue23521@psf.upfronthosting.co.za> Message-ID: <1425138532.93.0.866714889492.issue23521@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 17:13:01 2015 From: report at bugs.python.org (Jack O'Connor) Date: Sat, 28 Feb 2015 16:13:01 +0000 Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3 Message-ID: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za> New submission from Jack O'Connor: This toy program: import asyncio @asyncio.coroutine def main(): p = yield from asyncio.create_subprocess_shell('echo hi') yield from p.wait() asyncio.get_event_loop().run_until_complete(main()) Produces this output on Arch Linux under Python 3.4.3 (but not 3.4.2): hi Exception ignored in: > Traceback (most recent call last): File "/home/jacko/Downloads/Python-3.4.3/Lib/asyncio/base_events.py", line 361, in __del__ File "/home/jacko/Downloads/Python-3.4.3/Lib/asyncio/unix_events.py", line 57, in close File "/home/jacko/Downloads/Python-3.4.3/Lib/asyncio/unix_events.py", line 138, in remove_signal_handler TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object ---------- components: asyncio messages: 236892 nosy: gvanrossum, haypo, oconnor663, yselivanov priority: normal severity: normal status: open title: TypeError in event loop finalizer, new in Python 3.4.3 type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 17:13:14 2015 From: report at bugs.python.org (James Rutherford) Date: Sat, 28 Feb 2015 16:13:14 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425139994.56.0.126460216247.issue23539@psf.upfronthosting.co.za> James Rutherford added the comment: Happy to remove OPTIONS from the list of methods that gets a content-length where body is None, but do we also want to consider behaviour if it's the empty string? My feeling is that '' implies "present but empty" (so should have a content-length set to zero), whereas None implies "missing" (so should only have a content-length header set to zero if the method is expecting a body. I've updated the patch with this logic, including ensuring proper explicit test coverage for the cases described. Docs updated too. ---------- Added file: http://bugs.python.org/file38276/issue23539-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 17:22:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 16:22:30 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1425140550.63.0.897441988234.issue22351@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 17:34:17 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 28 Feb 2015 16:34:17 +0000 Subject: [issue18382] multiprocessing's overlapped PipeConnection issues on Windows 8 In-Reply-To: <1373114737.55.0.0779572840335.issue18382@psf.upfronthosting.co.za> Message-ID: <1425141257.96.0.733409725369.issue18382@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower components: +Library (Lib), Windows -Extension Modules nosy: +tim.golden, zach.ware stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 17:36:21 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 28 Feb 2015 16:36:21 +0000 Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3 In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za> Message-ID: <1425141381.45.0.542772296677.issue23548@psf.upfronthosting.co.za> Guido van Rossum added the comment: Does it also have that error if you add `asyncio.get_event_loop().close()` to the end of the program? Can you figure out what the value of `sig` and `handler` are in the traceback? My gut feeling tells me this is due to `signal.default_int_handler` being None at that point in the program tear-down sequence. (Which is why I recommend closing the loop.) The tear-down sequence at best has a partial order, which is why this may come and go depending on random variables like which Python version you use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 17:37:41 2015 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 28 Feb 2015 16:37:41 +0000 Subject: [issue23549] heapq docs should be more precise about how to access the smallest element Message-ID: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za> New submission from Eli Bendersky: The heapq documentation has this paragraph after the doc of nsmallest: The latter two functions perform best for smaller values of n. For larger values, it is more efficient to use the sorted() function. Also, when n==1, it is more efficient to use the built-in min() and max() functions. This is confusing as it suggests to use min() on a heap to find the minimal element. heap[0] is the minimal element, but this is only mentioned at the very top - so you need to read the doc of the entire module to find it. Nothing in the docs of methods suggests it. ---------- assignee: docs at python components: Documentation messages: 236895 nosy: docs at python, eli.bendersky priority: normal severity: normal status: open title: heapq docs should be more precise about how to access the smallest element type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 17:45:48 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 28 Feb 2015 16:45:48 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1425141948.74.0.818910427128.issue19980@psf.upfronthosting.co.za> Mark Lawrence added the comment: Pang :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 17:47:23 2015 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 28 Feb 2015 16:47:23 +0000 Subject: [issue23549] heapq docs should be more precise about how to access the smallest element In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za> Message-ID: <1425142043.96.0.511452341476.issue23549@psf.upfronthosting.co.za> Eli Bendersky added the comment: Proposed patch (generated vs. the 3.4 docs) is attached ---------- keywords: +patch Added file: http://bugs.python.org/file38277/issue23549.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 18:04:44 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 28 Feb 2015 17:04:44 +0000 Subject: [issue23304] Unused Superclass in calendar.py In-Reply-To: <1421963210.26.0.700938779083.issue23304@psf.upfronthosting.co.za> Message-ID: <1425143084.15.0.328982586702.issue23304@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 18:28:46 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 28 Feb 2015 17:28:46 +0000 Subject: [issue23062] test_argparse --version test cases In-Reply-To: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za> Message-ID: <1425144526.09.0.0515718976095.issue23062@psf.upfronthosting.co.za> Berker Peksag added the comment: > Why the test class is moved? Just wanted to group all TestHelp* tests together. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 18:31:17 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 28 Feb 2015 17:31:17 +0000 Subject: [issue23542] Update PEP 476 for using urllib2.build_opener() In-Reply-To: <1425069828.0.0.476725699175.issue23542@psf.upfronthosting.co.za> Message-ID: <1425144677.37.0.650901713174.issue23542@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 18:38:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 17:38:07 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1425145087.19.0.644392420492.issue22351@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is it possible to make tests based on mocked server instead of real local server? NNTP_SSL still is not tested. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 18:39:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 17:39:29 +0000 Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch exiting exceptions In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za> Message-ID: <1425145169.77.0.76651676253.issue23430@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 19:00:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 18:00:43 +0000 Subject: [issue23062] test_argparse --version test cases In-Reply-To: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za> Message-ID: <1425146443.98.0.737820942239.issue23062@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: But it already was between two help tests: TestHelpNoHelpOptional and TestHelpNone. I think that original test tested that the help attribute is optional for the --version argument and default description is printed in help output. This test shouldn't be removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 19:27:13 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 28 Feb 2015 18:27:13 +0000 Subject: [issue23529] Limit decompressed data when reading from LZMAFile and BZ2File In-Reply-To: <1425085172.59.0.886668222222.issue23529@psf.upfronthosting.co.za> (Martin Panter's message of "Sat, 28 Feb 2015 00:59:32 +0000") Message-ID: <87ioelvqma.fsf@vostro.rath.org> Nikolaus Rath added the comment: On Feb 27 2015, Martin Panter wrote: > In the code review, Nikolaus raised the idea of allowing a custom > ?buffer_size? parameter for the BufferedReader. I think this would > need a bit of consideration about how it should work: > > 1. Should it be a direct wrapper around > BufferedReader(buffer_size=...)? I'm not 100% sure what you mean by that, but I think the answer is Yes. > 2. Should it also support an unbuffered reader mode like > open(buffering=0), socket.makefile(buffering=0), and > subprocess.Popen(bufsize=0)? Yes, in that case the DecompressReader should simply be used without encapsulating it in BufferedReader. > 3. Should there be any consideration for buffering in write mode > (mirroring the equivalent open(), etc parameters)? I don't think so. There's not much to be gained by buffering data before passing it to the compressor, so the only point of buffering is to avoid short writes (or reads in case of decompressing). But the low-level compressor code already avoids short writes. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F ?Time flies like an arrow, fruit flies like a Banana.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 19:21:10 2015 From: report at bugs.python.org (Hammerite) Date: Sat, 28 Feb 2015 18:21:10 +0000 Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check" property for a character Message-ID: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za> New submission from Hammerite: Unicode Standard Annex #15 (http://unicode.org/reports/tr15/#Stable_Code_Points) describes how each character in Unicode, for each of the four normalisation forms, has a "Quick_Check" value that aids in determining whether a given string is in that normalisation form. It goes on to describe, in section 9.1, how this "Quick_Check" value may be used to optimise the concatenation of a string onto a normalised string to produce another normalised string: normalisation need only be performed from the last "stable" character in the left-hand string onwards, where a character is "stable" if it has the "Quick_Check" property and has a canonical combining class of 0. This will generally be more efficient than re-running the normalisation algorithm on the entire concatenated string, if the strings involved are long. The unicodedata standard-library module does not, in my understanding, expose this information. I would like to see a new function added that allows us to determine whether a given character has the "Quick_Check" property for a given normalisation form. This function might accept two parameters, the first of which is a string indicating the normalisation form and the second of which is the character being tested (similar to unicodedata.normalize()). Suppose we have a need to accept text data, receiving chunks of it at a time, and every time we receive a new chunk we need to append it to the string so far and also make sure that the resulting string is normalised to a particular normalisation form (NFD say). This implies that we would like to be able to concatenate the new chunk (which may not be normalised) onto the string "so far" (which is) and have the result be normalised - but without re-doing normalisation of the whole string over again, as this might be inefficient. From the linked UAX, this might be achieved like this, where unicodedata.quick_check() is the requested function: def concat (s1, s2): LSCP = len(s1) # Last stable character position while LSCP > 0: LSCP -= 1 if unicodedata.combining(s1[LSCP]) == 0 and unicodedata.quick_check('NFD', s1[LSCP]): break return s1[:LSCP] + unicodedata.normalize('NFD', s1[LSCP:] + s2) ---------- components: Library (Lib), Unicode messages: 236901 nosy: Hammerite, ezio.melotti, haypo priority: normal severity: normal status: open title: Add to unicodedata a function to query the "Quick_Check" property for a character type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 19:28:48 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 28 Feb 2015 18:28:48 +0000 Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check" property for a character In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za> Message-ID: <1425148128.21.0.160280762118.issue23550@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +benjamin.peterson, lemburg, loewis, pitrou versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 20:22:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 19:22:19 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1425151339.08.0.843375792491.issue19980@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is a problem with the patch. When you are in interactive help utility, then the request 'help' runs nested interactive help utility. The difference between unpatched behavior is that now you need press Ctrl-D or 'q' twice to exit to normal Python interpreter. When you type 'help' repeatedly, your could run third, fourth, etc nested help utility. Here is modified patch. Now help('help') produces the same output as help(help), but the 'help' request in interactive help utility prints help intro message. >>> help('help') Help on _Helper in module _sitebuiltins object: help = class _Helper(builtins.object) | Define the builtin 'help'. | | This is a wrapper around pydoc.help that provides a helpful message | when 'help' is typed at the Python interactive prompt. | | Calling help() at the Python prompt starts an interactive help session. | Calling help(thing) prints help for the python object 'thing'. | | Methods defined here: | | __call__(self, *args, **kwds) | | __repr__(self) | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) >>> help() Welcome to Python 3.5's help utility! If this is your first time using Python, you should definitely check out the tutorial on the Internet at http://docs.python.org/3.5/tutorial/. Enter the name of any module, keyword, or topic to get help on writing Python programs and using Python modules. To quit this help utility and return to the interpreter, just type "quit". To get a list of available modules, keywords, symbols, or topics, type "modules", "keywords", "symbols", or "topics". Each module also comes with a one-line summary of what it does; to list the modules whose name or summary contain a given string such as "spam", type "modules spam". help> help Welcome to Python 3.5's help utility! If this is your first time using Python, you should definitely check out the tutorial on the Internet at http://docs.python.org/3.5/tutorial/. Enter the name of any module, keyword, or topic to get help on writing Python programs and using Python modules. To quit this help utility and return to the interpreter, just type "quit". To get a list of available modules, keywords, symbols, or topics, type "modules", "keywords", "symbols", or "topics". Each module also comes with a one-line summary of what it does; to list the modules whose name or summary contain a given string such as "spam", type "modules spam". help> ---------- assignee: docs at python -> serhiy.storchaka nosy: +serhiy.storchaka Added file: http://bugs.python.org/file38278/issue19880v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 20:24:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 19:24:24 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1425151464.17.0.607436996379.issue19980@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file38278/issue19880v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 20:25:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 19:25:48 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1425151548.93.0.622596577887.issue19980@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file38279/issue19880v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 20:36:27 2015 From: report at bugs.python.org (Jack O'Connor) Date: Sat, 28 Feb 2015 19:36:27 +0000 Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3 In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za> Message-ID: <1425152187.42.0.0856478445708.issue23548@psf.upfronthosting.co.za> Jack O'Connor added the comment: `close()` fixes it; thanks for the workaround! When I throw a print statement inside `remove_signal_handler`, it says that sig is 17 and handler is 0. 17 looks to be SIGCHLD, presumably from the little echo subprocess exiting in this example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 20:44:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 28 Feb 2015 19:44:52 +0000 Subject: [issue23544] IDLE hangs when selecting Stack View with debug active In-Reply-To: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za> Message-ID: <1425152692.3.0.693701080637.issue23544@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that 'Stack Viewer' does not explain what this does, which is to gives a more detail view of the stack and name bindings after an exception. The doc entry does not either. I will consider 'Stack Trace' or maybe 'Exception Review'. I think a popup message is needed too. PS. When replying to email, please snip the messages you are responding to (except possible for a line or two). That message sits above yours when viewed on the web page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 21:11:59 2015 From: report at bugs.python.org (Yassine ABOUKIR) Date: Sat, 28 Feb 2015 20:11:59 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za> Message-ID: <1425154319.37.0.826930013218.issue23505@psf.upfronthosting.co.za> Changes by Yassine ABOUKIR : ---------- nosy: +benjamin.peterson, pitrou, python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 21:16:57 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Feb 2015 20:16:57 +0000 Subject: [issue23549] heapq docs should be more precise about how to access the smallest element In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za> Message-ID: <1425154617.32.0.904896605371.issue23549@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 21:35:52 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Feb 2015 20:35:52 +0000 Subject: [issue23551] IDLE to provide menu options for using PIP Message-ID: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> New submission from Raymond Hettinger: In teaching Python, I find that many Windows users are command-line challenged and have difficulties using and accessing PIP. In the spirit of what Tortoise has done for version control, I propose that menu options be added for PIP. PyPI (Python Package Index) --------------------------- * Ensure pip / Upgrade pip * Show installed packages (freeze) (and give options to update or remove) * Install from requirements file (install -r) * Search for package * Install package * Upgrade package (install -U) * Uninstall package * Change default repository (default pypi.python.org) * Change default install directory (in case the user doesn't have admin rights) This change would be a major step forward in making the PyPi accessible by people who lack the skills or inclination to wrestle with PIP. I would love to be able to start a class with a fresh Python download from python.org and effortlessly install requests and other tools without users having to fire-up a terminal window and wrestle with the various parts. ---------- assignee: terry.reedy components: IDLE messages: 236906 nosy: rhettinger, terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE to provide menu options for using PIP type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 21:41:01 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 28 Feb 2015 20:41:01 +0000 Subject: [issue23551] IDLE to provide menu options for using PIP In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1425156061.36.0.277680251086.issue23551@psf.upfronthosting.co.za> Donald Stufft added the comment: I don't know if this should be part of IDLE or not, but I've long wondered if we should make a GUI frontend for pip. To be clear, I'm not against this being in IDLE either, but just saying I've thought about making a pip-gui project in the past, I just haven't had the time or motivation to really do it. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 21:42:52 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Feb 2015 20:42:52 +0000 Subject: [issue23552] Have timeit warn about runs that are not independent of each other Message-ID: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za> New submission from Raymond Hettinger: IPython 3.0 added a useful feature that we ought to consider for inclusion either in timeit.repeat() or in the command-line interface: """Using %timeit prints warnings if there is at least a 4x difference in timings between the slowest and fastest runs, since this might meant that the multiple runs are not independent of one another.""" ---------- components: Library (Lib) messages: 236908 nosy: rhettinger priority: normal severity: normal status: open title: Have timeit warn about runs that are not independent of each other type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 21:51:16 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 28 Feb 2015 20:51:16 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1425156676.03.0.107302457357.issue18986@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I'm also eager to hear what limitations prevented the acceptance. Please do link back here when you've posted. I have to say, I'm not entirely surprised. In my implementation, I struggled with some cases, and it certainly doesn't feel like a fully safe implementation. That said, since I mentioned the implementation in jaraco.util earlier, I wanted to announce that those implementations (FoldedCase and FoldedCaseKeyedDict) have been moved to two libraries (jaraco.text and jaraco.collections). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 21:54:24 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 28 Feb 2015 20:54:24 +0000 Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check" property for a character In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za> Message-ID: <54F22AEF.6030203@egenix.com> Marc-Andre Lemburg added the comment: Can you provide a patch for this ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 22:26:27 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Sat, 28 Feb 2015 21:26:27 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1425158787.5.0.749562281842.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Ok...so the joys of autoconf configuring bite again. ALL Android devices have /dev/ptmx (adb even assumes it)...should the configure script be modified to skip that check if cross-compiling for Android? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 22:36:26 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Feb 2015 21:36:26 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425159386.25.0.745916367519.issue23539@psf.upfronthosting.co.za> Martin Panter added the comment: Yes I agree with the behaviour that None means no body (for requests such as GET), and an empty string means an empty but present body. Correct me if I?m wrong, but I think the fix for Issue 14721 already does that. Perhaps the new behaviour needs a ?Changed in version X? tag? I?m not sure, but I tend to think of this as a new feature, rather than a bug fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 22:37:24 2015 From: report at bugs.python.org (Hammerite) Date: Sat, 28 Feb 2015 21:37:24 +0000 Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check" property for a character In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za> Message-ID: <1425159444.69.0.592118940912.issue23550@psf.upfronthosting.co.za> Hammerite added the comment: No, I haven't done any work on it. Is that the "done" thing when suggesting something? I'm sorry, I wasn't aware. I could look into it. I am unfamiliar with the CPython codebase, but I can have a go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 22:45:39 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Feb 2015 21:45:39 +0000 Subject: [issue23411] Update urllib.parse.__all__ In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> Message-ID: <1425159939.85.0.95079312643.issue23411@psf.upfronthosting.co.za> Martin Panter added the comment: For what it?s worth, I have used the the SplitResult class directly to build URLs from components, and to get at the hostname:port parsing functionality, as described in Issue 23416. As well as pydoc, I notice when things are missing from __all__ when I try to do ?from import *? to experiment in the interactive interpreter. Though I?m not fussed if this only goes into 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 22:46:58 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 28 Feb 2015 21:46:58 +0000 Subject: [issue23549] heapq docs should be more precise about how to access the smallest element In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za> Message-ID: <1425160018.75.0.504848037924.issue23549@psf.upfronthosting.co.za> Martin Panter added the comment: ?Smalest? is spelt with a double L. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 22:48:40 2015 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 28 Feb 2015 21:48:40 +0000 Subject: [issue23549] heapq docs should be more precise about how to access the smallest element In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za> Message-ID: <1425160120.92.0.746950081148.issue23549@psf.upfronthosting.co.za> Eli Bendersky added the comment: Good catch. Attaching a new version of the patch with the typo fixed. ---------- Added file: http://bugs.python.org/file38280/issue23549.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 23:07:39 2015 From: report at bugs.python.org (James Rutherford) Date: Sat, 28 Feb 2015 22:07:39 +0000 Subject: [issue23539] Content-length not set for HTTP methods expecting body when body is None In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za> Message-ID: <1425161259.96.0.947771337128.issue23539@psf.upfronthosting.co.za> James Rutherford added the comment: I actually consider this a fix for the fix in 14721, rather than a new feature. The only new behaviour here is setting content length to be zero if body is None on PATCH, POST, or PUT. Happy to change the labeling if that's the consensus but IMO it's a bugfix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 23:13:54 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 28 Feb 2015 22:13:54 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1425161634.37.0.329658317941.issue19980@psf.upfronthosting.co.za> Mark Lawrence added the comment: LGTM. I noticed this running the tests. test_modules (test.test_pydoc.PydocImportTest) ... skipped 'causes undesireable side-effects (#20128)' test_modules_search (test.test_pydoc.PydocImportTest) ... skipped 'causes undesireable side-effects (#20128)' test_modules_search_builtin (test.test_pydoc.PydocImportTest) ... skipped 'some buildbots are not cooperating (#20128)' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 23:18:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 22:18:31 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1425161911.96.0.901335262097.issue20204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It also can be ImportWarning (warnings triggered during the process of importing a module (ignored by default)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 23:24:49 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 28 Feb 2015 22:24:49 +0000 Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc In-Reply-To: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za> Message-ID: <1425162289.08.0.228165793581.issue20128@psf.upfronthosting.co.za> Mark Lawrence added the comment: Whilst testing #19980 I noticed that three tests are still skipped. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 23:42:36 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 28 Feb 2015 22:42:36 +0000 Subject: [issue23547] Engineering at Google in 2015 Message-ID: <1425163356.22.0.393671492011.issue23547@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- Removed message: http://bugs.python.org/msg236889 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 23:43:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 28 Feb 2015 22:43:43 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <20150228224340.39434.33937@psf.io> Roundup Robot added the comment: New changeset 4a1fe339dcf6 by Serhiy Storchaka in branch 'default': Issue #19980: Improved help() for non-recognized strings. help('') now https://hg.python.org/cpython/rev/4a1fe339dcf6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 23:44:08 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 28 Feb 2015 22:44:08 +0000 Subject: [issue23547] Misdirected Message-ID: <1425163448.36.0.602868190212.issue23547@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: -> resolved title: Engineering at Google in 2015 -> Misdirected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 28 23:46:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Feb 2015 22:46:58 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1425163618.22.0.968354794414.issue19980@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Mark. > I noticed this running the tests. This is temporary OK. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________