From report at bugs.python.org Thu May 1 00:00:30 2014 From: report at bugs.python.org (Jim Jewett) Date: Wed, 30 Apr 2014 22:00:30 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: Jim Jewett added the comment: On Wed, Apr 30, 2014 at 3:05 PM, Adam Polkosnik wrote: > test.zip up there is the test case for this change. Is there any other test case needed? ah; I see the confusion. test.zip is test *data*. When I asked for a test *case*, I meant something that ensures the data will be used to actually run the test automatically. Typically, that would involve adding something to Lib/test/test_zipfile.py. I'm guessing it would be easiest to add a new class inheriting from unittest.TestCase and opening test.zip in the setUp, then using a bunch of assert* methods to verify that the file was read and interpreted correctly. -jJ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 00:13:45 2014 From: report at bugs.python.org (Jim Jewett) Date: Wed, 30 Apr 2014 22:13:45 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1398885110.1.0.45638107752.issue6839@psf.upfronthosting.co.za> Message-ID: Jim Jewett added the comment: On Wed, Apr 30, 2014 at 3:11 PM, Adam Polkosnik > I've got some test cases where the zlib_forward_slash.patch doesn't cut it. My recommendation (and I could be convinced otherwise) would be to replace if fname_str != zinfo.orig_filename: raise ... with something more like self.filename_check(fname_str, zinfo.orig_filename) and a default implementation of filename_check that does nothing if they're equal; calls the slash replace (since the standard supports that correction); does nothing else if they're now equal; emits a warning (or prints, in 2.7.6) otherwise. In 2.7.6, you would have to keep the new methods private, but in 3.5, users could override filename_check to handle the windows path normalization, or whatever other problems you have documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 00:25:39 2014 From: report at bugs.python.org (Eric Olson) Date: Wed, 30 Apr 2014 22:25:39 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398896739.17.0.78820868798.issue2159@psf.upfronthosting.co.za> Eric Olson added the comment: Also, I'm happy to allow the code to be ported to pybsddb. As long as it doesn't cause any problems with CPython licensing - and I can't think of any way it could. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 00:33:31 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Apr 2014 22:33:31 +0000 Subject: [issue21394] Lib/random.py: use more efficient code to convert bytes to integer In-Reply-To: <1398852467.62.0.62846026727.issue21394@psf.upfronthosting.co.za> Message-ID: <1398897211.75.0.543972826053.issue21394@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, I didn't read the right version of the code. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 01:42:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Apr 2014 23:42:09 +0000 Subject: [issue18564] Integer overflow in socketmodule In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za> Message-ID: <1398901329.12.0.460729363531.issue18564@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Interestingly, the tests are skipped here (Linux 3.11.0-20-generic). For some reason my socket module is built without bluetooth support (HAVE_BLUETOOTH_BLUETOOTH_H and HAVE_BLUETOOTH_H are both undefined). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 01:45:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Apr 2014 23:45:50 +0000 Subject: [issue18564] Integer overflow in socketmodule In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za> Message-ID: <1398901550.83.0.0661487086986.issue18564@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, I had to install libbluetooth-dev. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 01:57:10 2014 From: report at bugs.python.org (Min RK) Date: Wed, 30 Apr 2014 23:57:10 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398902230.43.0.707814982796.issue21351@psf.upfronthosting.co.za> Min RK added the comment: Thanks for clarifying that there is indeed a reference cycle by way of the module, I hadn't realized that. The gc blocking behavior is exactly why I brought up the issue. The real code where this causes a problem (rather than the toy example I attached) is in pyzmq, where destroying a Context object calls `zmq_term`, a GIL-less C call that will (and should) block until all associated sockets are closed. Deleting a socket closes it. Sockets hold a reference to the Context and not vice versa, which has ensured that the sockets are collected before the Context until Python 3.4. Does this mean it is no longer possible to express that one object should be cleaned up before another via references? I think I will switch to adding an atexit call to set a flag that prevents any cleanup logic during the atexit process, since it does not appear to be possible to ensure deletion of one object before another in 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 02:05:52 2014 From: report at bugs.python.org (Alan McIntyre) Date: Thu, 01 May 2014 00:05:52 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1398902752.68.0.800178176484.issue6839@psf.upfronthosting.co.za> Changes by Alan McIntyre : ---------- nosy: -alanmcintyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 02:17:29 2014 From: report at bugs.python.org (Tim Peters) Date: Thu, 01 May 2014 00:17:29 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398903449.92.0.0738300134446.issue21351@psf.upfronthosting.co.za> Tim Peters added the comment: There's no way to influence finalization order for objects in cycles, and there never was. So nothing actually changed in that respect ;-) What did change is that Python used to forcibly break many module-level cycles in a way that just happened to result in the finalization order you wanted. Outside of cycles it's still as predictable as before. For example, you could reliably get the finalization order you want by replacing the last two lines with p.child() p.child() Then the children aren't in cycles, and will be finalized first. But that's still due to other CPython implementation details (which haven't yet changed), not to language guarantees. But an atexit handler sounds like a saner way to proceed :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 02:25:03 2014 From: report at bugs.python.org (Elias Zamaria) Date: Thu, 01 May 2014 00:25:03 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1397486628.48.0.807014364675.issue19980@psf.upfronthosting.co.za> Message-ID: Elias Zamaria added the comment: Sorry for the late response but I have been busy with various things. I may be able to work on this but I don't know when or how long it will take me. I would suggest that someone else work on it if anyone wants it done any time soon. I am sorry about this. On Mon, Apr 14, 2014 at 7:43 AM, Jessica McKellar wrote: > > Jessica McKellar added the comment: > > Elias, thanks for your patch! > > I think it's important to add the second part of Terry's suggestion which > gives the user a specific next step to take, namely: > > > Try help('help') for information on recognized strings or help(str) for > help on the str class. > > Can you add that to your patch? > > Additionally, we'll want to make sure we don't accidentally break this new > functionality. Can you add a few test cases, for example what happens when > you run help on a module (e.g. help("os"), 2) help on an instance of a > class (e.g. help(1)), and help on a string that doesn't have a special > meaning, (e.g. help("abcxyz"))? > > I don't see any existing tests for help(), but it is an instance of > site._Helper (as reported by type(help)), and site tests live in > Lib/test/test_site.py. It also gets loaded into builtins, so tests could > also live in Lib/test/test_builtins.py. > > ---------- > nosy: +Jessica.McKellar, jesstess > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 02:27:25 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 01 May 2014 00:27:25 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398904045.04.0.859125048371.issue2159@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I would like a bit more comfortable if you return True/False. Maybe I am missing something, I am not familiar with this either, but looks like more... sensible, instead of counting on implicit and magical 0/1 -> False/True conversion. What do you think?. Maybe I am missing something, I am not familiar with the details either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 02:29:47 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 01 May 2014 00:29:47 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398904187.45.0.507850335516.issue2159@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: BTW, would you mind to sign a contributor form?. https://www.python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 02:30:53 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 01 May 2014 00:30:53 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398904253.48.0.963737068713.issue2159@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Oh, I see that your already did. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 02:42:18 2014 From: report at bugs.python.org (Min RK) Date: Thu, 01 May 2014 00:42:18 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za> Message-ID: <1398904938.5.0.819252707106.issue21351@psf.upfronthosting.co.za> Min RK added the comment: Thanks for your help and patience. Closing as slightly unfortunate, but not unintended behavior. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 03:00:06 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 01 May 2014 01:00:06 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <1398906006.85.0.178865264677.issue20951@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Maybe. I have 1.0.1g. Could you maybe post the output of the failed test? I'd like to understand how the patch broke the test (looking at your patch alone didn't tell me much). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 03:18:37 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 01 May 2014 01:18:37 +0000 Subject: [issue7267] format method: c presentation type broken In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <1398907117.68.0.0229326414321.issue7267@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If the purpose of backporting .format was/is to help people writing forward-looking code, or now, to write 2&3 code, then it should work like .format in 3.x, at lease when the format string is unicode. ---------- nosy: +terry.reedy stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 03:23:02 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 01 May 2014 01:23:02 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> Message-ID: <1398907382.55.0.791775531867.issue21377@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file35123/issue_21377_r4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 03:30:26 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 01 May 2014 01:30:26 +0000 Subject: [issue2716] Reimplement audioop because of copyright issues In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za> Message-ID: <1398907826.72.0.812498608932.issue2716@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Audioop was not removed in 3.x; the security bugs have been fixed; and no lawsuit. I agree with Aaron about modifying 2 files. I would also change 'shamelessly stolen' to 'taken'. IP is no longer something to joke about. ---------- nosy: +terry.reedy versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 03:32:55 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 01 May 2014 01:32:55 +0000 Subject: [issue2716] Document license under which audioop is used In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za> Message-ID: <1398907975.19.0.501341521507.issue2716@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python priority: high -> normal title: Reimplement audioop because of copyright issues -> Document license under which audioop is used _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 03:35:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 01 May 2014 01:35:46 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <1398908146.6.0.610668884196.issue7267@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: format method: c presentation type broken -> format method: c presentation type broken in 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 05:08:00 2014 From: report at bugs.python.org (Eric Olson) Date: Thu, 01 May 2014 03:08:00 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398913680.56.0.867322242953.issue2159@psf.upfronthosting.co.za> Eric Olson added the comment: I did try the suggestion to return Py_False, but that gives the wrong result since Py_False is not 0 and gets returned as Py_True. I looked for similar code, and this looks like the convention for handling "if obj". PyObject_IsTrue() is called on the object. What it returns can be affected by an nb_bool function that returns 0 or 1 (or -1). Here are a few similar examples that need to implement nb_bool to handle converting an obj to a bool: Objects/floatobject.c:float_bool Modules/_datetimemodule.c:delta_bool Objects/complexobject.c:complex_bool For many types, there is no nb_bool, and other things are tried such as getting the length. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 06:46:43 2014 From: report at bugs.python.org (paul j3) Date: Thu, 01 May 2014 04:46:43 +0000 Subject: [issue9625] argparse: Problem with defaults for variable nargs when using choices In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za> Message-ID: <1398919603.69.0.465127876259.issue9625@psf.upfronthosting.co.za> paul j3 added the comment: There's a complicating issue - should these default values be passed through the type function? In most cases in `_get_values`, the string first goes through `_get_value`, and then to `_check_value`. For example the 'else:' case: value = [self._get_value(action, v) for v in arg_strings] for v in value: self._check_value(action, v) The '*' positional case could coded the same way, allowing: parser.add_argument('foo', nargs='*', type=int, choices=range(5), default=['0',1,'2']) and objecting to default=[6,'7','a'] # out of range string or int or invalid value This does impose a further constraint on the 'type' function, that it accepts a converted value. e.g. int(1) is as valid as int('1'). But we need to be careful that this case is handled in a way that is consistent with other defaults (including the recent change that delayed evaluating defaults till the end). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 08:29:26 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 01 May 2014 06:29:26 +0000 Subject: [issue21403] cElementTree's Element creation handles attrib argument different from ET In-Reply-To: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> Message-ID: <1398925766.28.0.13416069213.issue21403@psf.upfronthosting.co.za> Stefan Behnel added the comment: Works for me in 3.2 and 3.4, fails in 2.7, as reported. I'll leave it to Eli to decide if this should get fixed in 2.7. In Py2, ET and cET were different modules, so this could also be considered a missing feature in cET. Given that it leads to a serialisation failure, though, it shouldn't hurt to change the behaviour. (changing title to something more specific) ---------- nosy: +scoder title: cElementTree creation of nodes with attributes is bugged -> cElementTree's Element creation handles attrib argument different from ET _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 08:32:28 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 01 May 2014 06:32:28 +0000 Subject: [issue21403] cElementTree's Element creation handles attrib argument different from ET In-Reply-To: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> Message-ID: <1398925948.96.0.696514086629.issue21403@psf.upfronthosting.co.za> Stefan Behnel added the comment: Ah, sorry, actually, it does not work in Py3.2: >>> import xml.etree.cElementTree as cET >>> root = cET.Element('root', attrib={'Name':'Root'}) >>> child = cET.SubElement(root, 'child', attrib={'Name':'Child'}) >>> cET.tostring(root) b'' That's even worse than in 2.7 as it doesn't raise an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 08:40:52 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 01 May 2014 06:40:52 +0000 Subject: [issue21403] cElementTree's Element creation handles attrib argument different from ET In-Reply-To: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> Message-ID: <1398926452.0.0.411828497976.issue21403@psf.upfronthosting.co.za> Stefan Behnel added the comment: According to issue 1572710, this is not a bug. The "attrib" argument is supposed to be a positional argument, not a keyword argument. This makes sense, given that arbitrary keyword arguments are accepted for additional XML attributes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 08:44:55 2014 From: report at bugs.python.org (Roman Inflianskas) Date: Thu, 01 May 2014 06:44:55 +0000 Subject: [issue21405] Allow using symbols from Unicode block "Superscripts and Subscripts" in identifiers Message-ID: <1398926695.28.0.870869900387.issue21405@psf.upfronthosting.co.za> New submission from Roman Inflianskas: It's really useful that python 3 allows me to use some Unicode symbols (as specified in https://docs.python.org/3.4/reference/lexical_analysis.html#identifiers), especially Greek symbols for mathematical programs. But when I write mathematical program with lots of indices I would like to use symbols from block "Superscripts and Subscripts" (as id_continue), for example: ???? I don't see any problems with allowing yet another subset of Unicode symbols. In Julia, for example, I can use them without problems. ---------- components: Unicode messages: 217681 nosy: ezio.melotti, haypo, rominf priority: normal severity: normal status: open title: Allow using symbols from Unicode block "Superscripts and Subscripts" in identifiers versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 09:39:07 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 May 2014 07:39:07 +0000 Subject: [issue21351] refcounts not respected at process exit In-Reply-To: <1398904938.5.0.819252707106.issue21351@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Never rely on the GC. Avoid cycles by using the weakref module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 12:25:31 2014 From: report at bugs.python.org (akira) Date: Thu, 01 May 2014 10:25:31 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1398939931.04.0.327766776902.issue21332@psf.upfronthosting.co.za> akira added the comment: I've changed test_newlines to work also with Python io implementation. I've updated the patch. Note: tests use 10 seconds timeouts: I don't know how long it should take to read back a line from a subprocess so that the timeout would indicate a deadlock. ---------- Added file: http://bugs.python.org/file35124/subprocess-line-buffering-issue21332-ps2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 12:27:33 2014 From: report at bugs.python.org (akira) Date: Thu, 01 May 2014 10:27:33 +0000 Subject: [issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation In-Reply-To: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za> Message-ID: <1398940053.27.0.559866112173.issue21396@psf.upfronthosting.co.za> akira added the comment: I've uploaded the patch that makes C implementation behave according to the docs like Python implementation with the corresponding tests. Issue #21332 is a dependency for this issue: subprocess' test_universal_newlines needs to be updated to work with Python version. For Reference ------------- issue #12591 introduces `write_through` to support subprocess' stdin pipe in text mode with bufsize=0 i.e., TextIOWrapper.buffer is unbuffered (raw) and Python and C implementation behave the same in this particular case. C implementation (pseudo-code):: if self.write_through: flush_text_buffer() buffer.flush() # <-- undocumented Python implementation:: if self.write_through: pass # _pyio.TextIOWrapper.write() calls buffer.write() directly behaves according to the current documentation [1]: If *write_through* is ``True``, calls to :meth:`write` are guaranteed not to be buffered: any data written on the :class:`TextIOWrapper` object is immediately handled to its underlying binary *buffer* [1]: hg.python.org/cpython/file/2a56d3896d50/Doc/library/io.rst For reference, here's how subprocess.py uses write_through [2]:: self.stdin = io.open(pipe, 'wb', bufsize) if universal_newlines=True: self.stdin = io.TextIOWrapper(self.stdin, write_through=True, line_buffering=(bufsize == 1)) # <-- issue #21332 http://hg.python.org/cpython/rev/9ce8fa0a0899/ - introduce io.TextIOWrapper in subprocess http://hg.python.org/cpython/rev/5cc536fbd7c1 - introduce write_through [2]: http://hg.python.org/cpython/file/2a56d3896d50/Lib/subprocess.py#l849 ---------- keywords: +patch Added file: http://bugs.python.org/file35125/io-write_through-c-vs-python-issue21396.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 12:49:06 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 01 May 2014 10:49:06 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1398941346.75.0.351375588187.issue2159@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: OK, you did your homework. I checked "PyObject_Is_True()" function and I agree. This actually looks like a "leak" when True/False were added to Python. Python3 is inheriting it :-). OK. I see three issues in the code: a) You are getting a key from the database, and you are not freeing it. So, this code leaks memory. b) You should check database errors too. Documentation says "When the end of the database is reached, the dptr member of the key is a null pointer. If an error is detected, the dptr member of the key shall be a null pointer and the error condition of the database shall be set.". Raise an exception with the proper error. Would be nice to test that too, but it is probably nos possible. c) Please, use NULL instead of "0". Thanks for your effort, Eric. ---------- assignee: -> jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 13:40:35 2014 From: report at bugs.python.org (Yinon Ehrlich) Date: Thu, 01 May 2014 11:40:35 +0000 Subject: [issue21391] PATCH: using the abspath shortcut in Lib/shutil In-Reply-To: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> Message-ID: <1398944435.91.0.161286206735.issue21391@psf.upfronthosting.co.za> Yinon Ehrlich added the comment: Use the 'abspath' shortcut instead of 'os.path.abspath' See the attached patch (sorry, forgot to attach before) ---------- keywords: +patch Added file: http://bugs.python.org/file35126/shutil.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 13:46:50 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 01 May 2014 11:46:50 +0000 Subject: [issue21405] Allow using symbols from Unicode block "Superscripts and Subscripts" in identifiers In-Reply-To: <1398926695.28.0.870869900387.issue21405@psf.upfronthosting.co.za> Message-ID: <1398944810.37.0.181491262906.issue21405@psf.upfronthosting.co.za> Steven D'Aprano added the comment: 3.1, 3.2, 3.3 and 3.4 are all in feature-freeze, so this is only an option for 3.5. A very tentative +1 on this feature. But I fear it may need to be discussed on python-ideas first. ---------- nosy: +steven.daprano type: -> enhancement versions: -Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 13:47:49 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 01 May 2014 11:47:49 +0000 Subject: [issue21391] PATCH: using the abspath shortcut in Lib/shutil In-Reply-To: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> Message-ID: <1398944869.38.0.839854228328.issue21391@psf.upfronthosting.co.za> Eric V. Smith added the comment: Wouldn't it be better to switch uses of abspath to be os.path.abspath? os.path is used elsewhere in the file, after all. Brett added "from os.path import abspath" in http://hg.python.org/cpython/rev/686e5d38be42 but I think that import should be deleted and os.path.abspath used directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 13:48:21 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 01 May 2014 11:48:21 +0000 Subject: [issue21391] PATCH: using the abspath shortcut in Lib/shutil In-Reply-To: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> Message-ID: <1398944901.16.0.833464464252.issue21391@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 14:09:37 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 May 2014 12:09:37 +0000 Subject: [issue20951] SSLSocket.send() returns 0 for non-blocking socket In-Reply-To: <1395004591.32.0.211111410214.issue20951@psf.upfronthosting.co.za> Message-ID: <1398946177.62.0.918699222848.issue20951@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, the test hangs after one of the threads crashes: test__all__ (test.test_poplib.TestPOP3_SSLClass) ... Exception in thread Thread-23: Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/threading.py", line 920, in _bootstrap_inner self.run() File "/home/antoine/cpython/default/Lib/test/test_poplib.py", line 218, in run asyncore.loop(timeout=0.1, count=1) File "/home/antoine/cpython/default/Lib/asyncore.py", line 212, in loop poll_fun(timeout, map) File "/home/antoine/cpython/default/Lib/asyncore.py", line 153, in poll read(obj) File "/home/antoine/cpython/default/Lib/asyncore.py", line 87, in read obj.handle_error() File "/home/antoine/cpython/default/Lib/asyncore.py", line 83, in read obj.handle_read_event() File "/home/antoine/cpython/default/Lib/asyncore.py", line 422, in handle_read_event self.handle_accept() File "/home/antoine/cpython/default/Lib/asyncore.py", line 499, in handle_accept self.handle_accepted(*pair) File "/home/antoine/cpython/default/Lib/test/test_poplib.py", line 228, in handle_accepted self.handler_instance = self.handler(conn) File "/home/antoine/cpython/default/Lib/test/test_poplib.py", line 368, in __init__ self.push('+OK dummy pop3 server ready. ') File "/home/antoine/cpython/default/Lib/test/test_poplib.py", line 82, in push asynchat.async_chat.push(self, data.encode("ISO-8859-1") + b'\r\n') File "/home/antoine/cpython/default/Lib/asynchat.py", line 190, in push self.initiate_send() File "/home/antoine/cpython/default/Lib/asynchat.py", line 243, in initiate_send self.handle_error() File "/home/antoine/cpython/default/Lib/asynchat.py", line 241, in initiate_send num_sent = self.send(data) File "/home/antoine/cpython/default/Lib/asyncore.py", line 366, in send result = self.socket.send(data) File "/home/antoine/cpython/default/Lib/ssl.py", line 667, in send return self._sslobj.write(data) ssl.SSLWantReadError: The operation did not complete (read) (_ssl.c:1636) This was due to a simplistic handling of asyncore SSL connections in test_poplib, which I've fixed by reusing the code from test_ftplib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 14:12:17 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 01 May 2014 12:12:17 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1398946337.15.0.22919198614.issue21109@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Let me present for discussion a proposal (and a patch with documentation) with an approach that is a little different, but in my opinion the most effective. I hope that it will appeal to all involved. My proposal consists of a new class SafeTarFile, that is a subclass and drop-in replacement for the TarFile class and can be employed whenever the user feels the necessity. It can be used the same way as TarFile, with the difference that SafeTarFile is equipped with a wide range of tests and as soon as it detects anything bad it interrupts the current operation with a SecurityError exception. This way damage is effectively averted, and it is up to the developer to decide whether he rejects the archive altogether (which is the obvious and recommended measure) or he wants to continue to process it in a subsequent step (on his own responsibility). To simplify a few common operations, SafeTarFile has three more methods: analyze(), filter() and is_safe(). These methods will allow access to the archive without SecurityError exceptions being raised. The analyze() method is a kind of low-level iterator that produces each TarInfo object together with a list of warnings (if the member is bad) as a tuple. This gives a developer access to all the information he needs to implement his own more differentiated way of handling bad archives. The filter() method is a convenience method that provides an iterator over all the "good" members of an archive leaving out all the "bad" ones. It can be used as an argument to SafeTarFile.extractall() for example. is_safe() is a high-level shortcut method that reduces the result of the analysis to a simple True or False. SafeTarFile has a variety of checks that test e.g. for bad pathnames, bad permissions and duplicate files. Also, to prevent denial-of-service scenarios, it enforces user-defined limits upon the archive, such as a maximum number of files or a maxmimum size of unpacked data. The main advantage of this approach is the higher degree of security. The practice of rewriting paths (e.g. like in Daniel.Garcia's patch) is error-prone, has side-effects and is hard to maintain because of its tendency towards regression. It just adds another layer of complexity to an already complex and delicate problem. SafeTarFile (or whatever it will be called) is backward compatible and easy to maintain, because it is an isolated addition to the tarfile module. It is easily subclassable to add more tests. It can be used as a standalone tool to check for bad archives and possible denial-of-service scenarios. Its analyze() method tells the user exactly what's wrong with the archive instead of keeping it away from him. Instead of silently extracting files to locations they weren't expected to be stored (i.e. after "fixing" their pathnames), SafeTarFile simply refuses to extract them at all. This way it is far more transparent and understandable to the user what happens. Feedback is welcome. ---------- assignee: -> lars.gustaebel priority: release blocker -> normal versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file35127/safetarfile-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 14:17:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 May 2014 12:17:47 +0000 Subject: [issue21406] Some socket constants are not enums Message-ID: <1398946667.03.0.621371730374.issue21406@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Many constants in the socket module, are not int enums. Examples are socket.CAN_BCM, socket.BTPROTO_RFCOMM, etc. For example when creating a bluetooth socket, you may get the following repr(): >>> socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM, socket.BTPROTO_RFCOMM) (notice the integer "proto") ---------- messages: 217691 nosy: barry, eli.bendersky, ethan.furman, neologix, pitrou priority: low severity: normal status: open title: Some socket constants are not enums type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 14:18:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 May 2014 12:18:58 +0000 Subject: [issue21405] Allow using symbols from Unicode block "Superscripts and Subscripts" in identifiers In-Reply-To: <1398926695.28.0.870869900387.issue21405@psf.upfronthosting.co.za> Message-ID: <1398946738.81.0.230627906133.issue21405@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think python-dev or python-ideas should indeed be consulted before. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 14:20:14 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 01 May 2014 12:20:14 +0000 Subject: [issue21404] Compression level for tarfile/zipfile In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za> Message-ID: <1398946814.63.0.961502296616.issue21404@psf.upfronthosting.co.za> Lars Gust?bel added the comment: tarfile.open() actually supports a compress_level argument for gzip and bzip2 and a preset argument for lzma compression. ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 14:26:34 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 May 2014 12:26:34 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> Message-ID: <1398947194.17.0.0808597976869.issue21377@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks! The latest patch looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 14:36:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 May 2014 12:36:31 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> Message-ID: <3gKGL43wPSz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 4ed1b6c7e2f3 by Antoine Pitrou in branch 'default': Issue #21377: PyBytes_Concat() now tries to concatenate in-place when the first argument has a reference count of 1. http://hg.python.org/cpython/rev/4ed1b6c7e2f3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 14:43:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 May 2014 12:43:11 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> Message-ID: <1398948191.8.0.846460169425.issue21377@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 15:02:00 2014 From: report at bugs.python.org (Roman Inflianskas) Date: Thu, 01 May 2014 13:02:00 +0000 Subject: [issue21405] Allow using symbols from Unicode block "Superscripts and Subscripts" in identifiers In-Reply-To: <1398926695.28.0.870869900387.issue21405@psf.upfronthosting.co.za> Message-ID: <1398949320.71.0.489816830905.issue21405@psf.upfronthosting.co.za> Roman Inflianskas added the comment: I'm sorry, I didn't now that bugtracker is not for features discussing. I'll wrote the letter to the python-ideas: https://groups.google.com/forum/#!topic/python-ideas/yjR7j9TSFeE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 15:48:51 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 01 May 2014 13:48:51 +0000 Subject: [issue21407] Add function signatures to _decimal Message-ID: <1398952131.31.0.29720873547.issue21407@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: skrah components: Extension Modules nosy: skrah priority: normal severity: normal status: open title: Add function signatures to _decimal type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 15:54:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 May 2014 13:54:24 +0000 Subject: [issue21407] Add function signatures to _decimal Message-ID: <3gKJ3z2cZGz7Lky@mail.python.org> New submission from Roundup Robot: New changeset 40b06a75d1c6 by Stefan Krah in branch 'default': Issue #21407: _decimal now supports function signatures. http://hg.python.org/cpython/rev/40b06a75d1c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 16:19:45 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 01 May 2014 14:19:45 +0000 Subject: [issue21399] inspect and class methods In-Reply-To: <1398860523.15.0.277604564567.issue21399@psf.upfronthosting.co.za> Message-ID: <1398953985.06.0.800426213934.issue21399@psf.upfronthosting.co.za> Stefan Krah added the comment: Okay, thanks. I've used "$cls" for Decimal.from_float in 40b06a75d1c6, and it appears to work already. Feel free to close the issue (I don't know whether AC emits "$cls" or if it should). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 16:20:40 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 01 May 2014 14:20:40 +0000 Subject: [issue21407] Add function signatures to _decimal In-Reply-To: <3gKJ3z2cZGz7Lky@mail.python.org> Message-ID: <1398954040.12.0.138419510994.issue21407@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 16:31:27 2014 From: report at bugs.python.org (Jean-Paul Calderone) Date: Thu, 01 May 2014 14:31:27 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done Message-ID: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone: $ ~/Projects/cpython/3.4/python -c ' class Foo(object): def __ne__(self, other): return "yup" def __eq__(self, other): return "nope" class Bar(object): pass print(object() != Foo(), object() == Foo()) print(Bar() != Foo(), Bar() == Foo()) ' yup nope False nope $ The output I would expect from this is yup nope yup nope That is, even when the type of the left-hand argument is not a base class of the type of the right-hand argument, delegation to the right-hand argument is sensible if the left-hand argument does not implement the comparison. Note that the output also demonstrates that this is already the behavior for `==`. Only `!=` seems to suffer from this issue. ---------- components: Interpreter Core messages: 217699 nosy: exarkun priority: normal severity: normal status: open title: delegation of `!=` to the right-hand side argument is not always done type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 16:40:38 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 01 May 2014 14:40:38 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1398955238.39.0.208015709151.issue21408@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That's because the implicit default __ne__ on Bar returns the opposite of __eq__. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 16:51:12 2014 From: report at bugs.python.org (Brett Cannon) Date: Thu, 01 May 2014 14:51:12 +0000 Subject: [issue21400] Code coverage documentation is out-of-date. In-Reply-To: <1398870474.7.0.668295680228.issue21400@psf.upfronthosting.co.za> Message-ID: <1398955872.94.0.972388871358.issue21400@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 16:58:59 2014 From: report at bugs.python.org (Brett Cannon) Date: Thu, 01 May 2014 14:58:59 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1398956339.3.0.404595759488.issue21401@psf.upfronthosting.co.za> Brett Cannon added the comment: Unfortunately it's impossible to warn against this in Python 2 since the bytes type is just another name for the str type: >>> str == bytes True >>> type(b'1') What we could potentially do, though, is change things such that -3 does what you are after when comparing bytes/str to unicode in Python 2. Unfortunately in that instance it's still a murky question as to whether that will help things more than hurt them as some people explicitly leave strings as-is in both Python 2 and Python 3 for either speed or code simplicity reasons. ---------- nosy: +brett.cannon title: python2 -3 does not warn about str to bytes conversions and comparisons -> python2 -3 does not warn about str/unicode to bytes conversions and comparisons _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 17:04:08 2014 From: report at bugs.python.org (Sworddragon) Date: Thu, 01 May 2014 15:04:08 +0000 Subject: [issue21404] Compression level for tarfile/zipfile In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za> Message-ID: <1398956648.85.0.920477744858.issue21404@psf.upfronthosting.co.za> Sworddragon added the comment: Could it be that compress_level is not documented? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 17:05:22 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 01 May 2014 15:05:22 +0000 Subject: [issue21404] Compression level for tarfile/zipfile In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za> Message-ID: <1398956722.49.0.319312366153.issue21404@psf.upfronthosting.co.za> Lars Gust?bel added the comment: That's right. But it is there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 17:08:00 2014 From: report at bugs.python.org (Sworddragon) Date: Thu, 01 May 2014 15:08:00 +0000 Subject: [issue21404] Compression level for tarfile/zipfile In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za> Message-ID: <1398956880.76.0.910269053885.issue21404@psf.upfronthosting.co.za> Sworddragon added the comment: Then this one is easy: The documentation needs just an update. But then there is still zipfile that doesn't provide (or at least document) a compression level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 17:14:12 2014 From: report at bugs.python.org (Joshua J Cogliati) Date: Thu, 01 May 2014 15:14:12 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1398957252.63.0.651652062338.issue21401@psf.upfronthosting.co.za> Joshua J Cogliati added the comment: Hm. That is a good point. Possibly it could only be done when from __future__ import unicode_literals has been used. For example: python2 -3 Python 2.7.5 Type "help", "copyright", "credits" or "license" for more information. >>> type(b"a") == type("a") True >>> from __future__ import unicode_literals >>> type(b"a") == type("a") False >>> b"a" == "a" True >>> b"a" + "a" u'aa' >>> After unicode_literals is used, then b"a" and "a" have a different type and the same code would be an issue in python3: python3 Python 3.3.2 >>> type(b"a") == type("a") False >>> b"a" == "a" False >>> b"a" + "a" Traceback (most recent call last): File "", line 1, in TypeError: can't concat bytes to str >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 17:43:40 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Thu, 01 May 2014 15:43:40 +0000 Subject: [issue21403] cElementTree's Element creation handles attrib argument different from ET In-Reply-To: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> Message-ID: <1398959020.93.0.673005149027.issue21403@psf.upfronthosting.co.za> Santoso Wijaya added the comment: There is still a matter of inconsistency between the two implementations and between 2.7 and 3.x. IMO, the Python-based ElementTree implementation is more graceful at handling the "attrib" argument. The signature of the factory function Element (and SubElement) in the doc is thus: class xml.etree.ElementTree.Element(tag, attrib={}, **extra) which is fair game for the user to use "attrib" as a keyword argument. Further, this serialization (in 3.x) does not really make sense, anyway: >>> cET.tostring(root) b'' ---------- components: +XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 17:46:15 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Thu, 01 May 2014 15:46:15 +0000 Subject: [issue21403] cElementTree's Element creation handles attrib argument different from ET In-Reply-To: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> Message-ID: <1398959175.3.0.622268148028.issue21403@psf.upfronthosting.co.za> Santoso Wijaya added the comment: Quoting dabrahams in issue 1572710: On second thought, I see what effbot is trying to say... but it's still a bug. Given the way the interface is declared and the behavior of regular python functions: Element(tag, attrib={}, **extra) indicates that I can pass attrib (or tag, for that matter) as a keyword argument. Nothing in the documentation gives the C implementation permission to behave differently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 17:50:16 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 01 May 2014 15:50:16 +0000 Subject: [issue21403] cElementTree's Element creation handles attrib argument different from ET In-Reply-To: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za> Message-ID: <1398959416.44.0.0880405104283.issue21403@psf.upfronthosting.co.za> Stefan Behnel added the comment: Note that this has been fixed in Py3 already (Py3.3, I guess). The only question is whether the behaviour will be changed in Py2.7. ---------- components: -XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 17:52:30 2014 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 01 May 2014 15:52:30 +0000 Subject: [issue21403] cElementTree's Element creation handles attrib argument different from ET In-Reply-To: <1398959416.44.0.0880405104283.issue21403@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: > Note that this has been fixed in Py3 already (Py3.3, I guess). The only > question is whether the behaviour will be changed in Py2.7. > I don't think this issue is acute enough to warrant fixes in 2.7; however, a documentation patch would be welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 19:23:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 May 2014 17:23:06 +0000 Subject: [issue21400] Code coverage documentation is out-of-date. In-Reply-To: <1398870474.7.0.668295680228.issue21400@psf.upfronthosting.co.za> Message-ID: <1398964986.62.0.871385750673.issue21400@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Devguide nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 19:33:35 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 01 May 2014 17:33:35 +0000 Subject: [issue21406] Some socket constants are not enums In-Reply-To: <1398946667.03.0.621371730374.issue21406@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Enum are for, well, enumerated values, so for values within a finite and known range (like days, cards, etc). OTOH, I'm not sure all socket constants could be categorized like this. It makes sense for address families, especially since they're used so much, but when it comes to e.g. SO_REUSEADDR or BTPROTO_RFCOMM, I'm not sure how we could categorize them. Unless would declare them all in a "SocketConstant" Enum? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 20:11:37 2014 From: report at bugs.python.org (David Watson) Date: Thu, 01 May 2014 18:11:37 +0000 Subject: [issue1599254] mailbox: other programs' messages can vanish without trace In-Reply-To: <1398697976.28.0.295022386502.issue1599254@psf.upfronthosting.co.za> Message-ID: <20140501181040.GA1993@localhost> David Watson added the comment: On Mon 28 Apr 2014, Jim Jewett wrote: > pinging David Watson: What is the status? If I understand correctly, (and I may well not), you have already opened other issues for parts of this, and (only) the final patch is ready for patch (and hopefully) commit review. Is this correct? No, I haven't opened any separate issues (I would be perfectly happy with fixing the original renaming-vs-copying problem and then leaving this issue open to deal with the rest). The patches mailbox-copy-back-2.7.diff and mailbox-tests-2.7-part1-for-copy-back.diff are what I suggest applying for the renaming-vs-copying problem. I haven't looked at the other patches in much detail, but for what it's worth, the tests in mailbox-tests-2.7-part2.diff do pass with mailbox-update-toc-again.diff applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 21:27:25 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 May 2014 19:27:25 +0000 Subject: [issue21406] Some socket constants are not enums In-Reply-To: <1398946667.03.0.621371730374.issue21406@psf.upfronthosting.co.za> Message-ID: <1398972445.57.0.239950356515.issue21406@psf.upfronthosting.co.za> R. David Murray added the comment: This is why we should have had named constants and not Enums :) But no, nothing in the python Enum implementation restricts it to a value *range*. It is really a collection of named constants. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 21:42:06 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 01 May 2014 19:42:06 +0000 Subject: [issue21406] Some socket constants are not enums In-Reply-To: <1398972445.57.0.239950356515.issue21406@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > But no, nothing in the python Enum implementation restricts it to a value *range*. It is really a collection of named constants. I didn't say in the implementation, I said in spirit. Would you describe all possible Unix PIDs are a Enum? Also, the problem is that many such constant can have identical values (because they can be passed at different syscalls/argument offset), and in this case the IntEnum equality isn't wanted: cf at neobox:~/python/hg/default$ cat /tmp/test.py from enum import IntEnum class Const(IntEnum): AF_INET = 1 SO_REUSEADDR = 1 print(Const.AF_INET == Const.SO_REUSEADDR) cf at neobox:~/python/hg/default$ ./python /tmp/test.py True Really? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 21:54:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 May 2014 19:54:46 +0000 Subject: [issue21406] Some socket constants are not enums In-Reply-To: <1398946667.03.0.621371730374.issue21406@psf.upfronthosting.co.za> Message-ID: <1398974086.96.0.146752059121.issue21406@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It makes sense for address families, especially since they're used so > much, but when it comes to e.g. SO_REUSEADDR or BTPROTO_RFCOMM, Hmm, I was thinking mostly about protocol numbers. All the BTPROTO_* constants should be part of a given enum (BlueToothProtocol?), the CAN_* constants part of another one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 21:58:53 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 01 May 2014 19:58:53 +0000 Subject: [issue21406] Some socket constants are not enums In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: To put it slightly differently: AF_XXX constant actually whome belong to the same namespace, the socket address family namespace. So we put them all in AddressFamily Enum. Now, for many constants defined in system header files, it's not so clear, e.g. BTPROTO_RFCOMM, TIPC_ADDR_ID, SCM_CREDENTIALS: in which Enum would you declare them? I'm not saying it's a bad idea: it actually probably makes sense for e.g. socket-level options (SO_REUSEADDR & Co), but it don't see any generic classification scheme that would make sense for all of them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 22:01:03 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 May 2014 20:01:03 +0000 Subject: [issue21406] Some socket constants are not enums In-Reply-To: <1398946667.03.0.621371730374.issue21406@psf.upfronthosting.co.za> Message-ID: <1398974463.65.0.340960918795.issue21406@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, I missed the fact that the "family" and "type" properties are re-computed on the fly; I thought the enum values where stored on the socket object. Then it makes it harder to do the same for "proto", since there are family-specific namespaces with colliding values, indeed. >>> socket.IPPROTO_ICMP 1 >>> socket.BTPROTO_HCI 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 22:07:11 2014 From: report at bugs.python.org (Jeff Hinrichs) Date: Thu, 01 May 2014 20:07:11 +0000 Subject: [issue21409] setup.py check - should fail and retrun a non 0 exit code Message-ID: <1398974831.77.0.0130360706808.issue21409@psf.upfronthosting.co.za> New submission from Jeff Hinrichs: python setup.py check python setup.py check --restructuredtext both incorrectly "warn" and don't "Fail" for things that will cause a failure when uploading to pypi. This is wrong. Additionally, they should return a non 0 exit code so they can be used as part of an CI such as drone.io / travis so the build will show as failing. Currently they do not, and if there are errors that will cause a pypi failure (like an unreadable long description) bad things happen. ---------- components: Distutils messages: 217719 nosy: dstufft, dundeemt, eric.araujo priority: normal severity: normal status: open title: setup.py check - should fail and retrun a non 0 exit code type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 22:08:35 2014 From: report at bugs.python.org (Jeff Hinrichs) Date: Thu, 01 May 2014 20:08:35 +0000 Subject: [issue21409] setup.py check - should fail and retrun a non 0 exit code In-Reply-To: <1398974831.77.0.0130360706808.issue21409@psf.upfronthosting.co.za> Message-ID: <1398974915.39.0.683140583216.issue21409@psf.upfronthosting.co.za> Jeff Hinrichs added the comment: example: (dhp)jlh at jlh-d520:~/Projects/dhp/src$ python setup.py check running check (dhp)jlh at jlh-d520:~/Projects/dhp/src$ python setup.py check --restructuredtext running check warning: check: Title underline too short. (line 2) warning: check: Could not finish the parsing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 22:27:29 2014 From: report at bugs.python.org (Jeff Hinrichs) Date: Thu, 01 May 2014 20:27:29 +0000 Subject: [issue21410] setup.py check --restructuredtext -- appears to pass if docutils not installed Message-ID: <1398976049.52.0.00446636547039.issue21410@psf.upfronthosting.co.za> New submission from Jeff Hinrichs: if you run setup.py check --restructuredtext without docutils installed, it will appear to pass if you add the -s flag, it will error and inform you that docutils is not installed. So nothing is reported and return results are the same as a "passing" check. $ python setup.py check --restructuredtext running check $ python setup.py check --restructuredtext -s running check error: The docutils package is needed. The not strict version is a little too loose to be of any good. ---------- components: Distutils messages: 217721 nosy: dstufft, dundeemt, eric.araujo priority: normal severity: normal status: open title: setup.py check --restructuredtext -- appears to pass if docutils not installed versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 22:30:16 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 01 May 2014 20:30:16 +0000 Subject: [issue21411] Enable Treat Warning as Error on 32-bit Windows Message-ID: <1398976216.25.0.391009605761.issue21411@psf.upfronthosting.co.za> New submission from Zachary Ware: Python 3.4 and 3.5 both compile without warnings on 32-bit Windows, so we should turn on Treat Warning as Error (/WX option to cl.exe). Setting that property in pyproject.props sets it for all projects, and the setting does not affect "Makefile projects" so warnings from OpenSSL, Tcl, Tk, or Tix will not kill the build. It will need to be explicitly disabled on 64-bit Windows; setting it in x64.props does the trick. One small issue is that /WX does pick up the "no profile information" warning in the PGUpdate build. I'm unsure whether we should turn off /WX in pgupdate.props, or just force PGUpdate builders to have run something for each PGI'd project. ---------- components: Build, Windows messages: 217722 nosy: loewis, tim.golden, zach.ware priority: low severity: normal status: open title: Enable Treat Warning as Error on 32-bit Windows type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 22:37:58 2014 From: report at bugs.python.org (John Beck) Date: Thu, 01 May 2014 20:37:58 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc Message-ID: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> New submission from John Beck: I am porting Python 3.4.0 to Solaris 12. The Makefile I inherited from my predecessor had --without-pymalloc as an option to be passed to configure. Curious why, I removed this line, only to find that after python was built, it core dumped: LD_LIBRARY_PATH=/builds/jbeck/ul-python-3/components/python/python34/build/sparcv9 ./python -E -S -m sysconfig --generate-posix-vars Fatal Python error: PyThreadState_Get: no current thread make[3]: *** [pybuilddir.txt] Abort (core dumped) But if I add the --without-pymalloc line back to my Makefile, everything works fine. Note that although this example was on sparc, the exact same thing occurred on x86. I searched for a similar bug but did not find out; please feel free to close this as a duplicate if there is one that I missed. I also suspect I have not provided enough information, out of a desire not to trigger information overload. But I would be happy to provide whatever specifics might be requested. ---------- components: Interpreter Core messages: 217723 nosy: jbeck priority: normal severity: normal status: open title: core dump in PyThreadState_Get when built --with-pymalloc type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 22:47:03 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 01 May 2014 20:47:03 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1398977223.43.0.77650434191.issue21412@psf.upfronthosting.co.za> Stefan Krah added the comment: On SPARC/suncc the flags in http://bugs.python.org/issue15963#msg170661 appear to work. Also, we have several Solaris build slaves that don't core dump. Some are offline, but you can click through to the ./configure steps of past builds to see the build flags. http://buildbot.python.org/all/waterfall?category=3.x.stable&category=3.x.unstable ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 23:06:55 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 01 May 2014 21:06:55 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za> Message-ID: <1398978415.3.0.219355262297.issue21037@psf.upfronthosting.co.za> Stefan Krah added the comment: > Hmm... perhaps Stefan would like to set something up? Being a correctness tool hipster, of course I already have the latest toy. :) The patch works on Debian 64-bit + clang. I can set up a VM. We may have to react quickly to some of the issues. Then again, anyone can run the tool, so there's no real secrecy anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 23:14:51 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 01 May 2014 21:14:51 +0000 Subject: [issue21399] inspect and class methods In-Reply-To: <1398860523.15.0.277604564567.issue21399@psf.upfronthosting.co.za> Message-ID: <1398978891.09.0.454783921367.issue21399@psf.upfronthosting.co.za> Yury Selivanov added the comment: Yeah, I'm closing this issue. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 23:18:01 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 01 May 2014 21:18:01 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1398979081.51.0.692137001257.issue21408@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Why would an subclass of object that doesn't redefine either __eq__ or __ne__ have a different behavior for inequality than object itself? Bar never defined __eq__, so it shouldn't have an implicit __ne__ any more than object itself does... Saying that Bar has an implicit __ne__ that object doesn't is answering how this happens, but it's not a why; is there a reason why this should be the case, or is this a bug (either in spec or in code) that should be fixed? ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 23:31:30 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 01 May 2014 21:31:30 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1398978415.3.0.219355262297.issue21037@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Being a correctness tool hipster, of course I already have the latest toy. :) The patch works on Debian 64-bit + clang. Thanks for testing it. I'll leave a few days more in case anyone has a comment, and I'll commit. > I can set up a VM. That would be great. > We may have to react quickly to some of the issues. > Then again, anyone can run the tool, so there's no real secrecy anyway. Exactly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 23:41:43 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 01 May 2014 21:41:43 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1398980503.8.0.786359844925.issue21408@psf.upfronthosting.co.za> Benjamin Peterson added the comment: The reason ``object() != Foo()`` "works" is that Foo is a subtype of object(), so the specialized __ne__ of Foo is called immediately without trying object.__ne__. I don't know whether it's a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 23:47:31 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 May 2014 21:47:31 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1398980851.59.0.595676086653.issue21408@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think it's a bug. The subclass-goes-first behavior is very intentional. The implicit __ne__ returning the boolean inverse of __eq__ is what fooled me when I looked at it. Or did you mean that following the subclass rule in the case where object is the other class is possibly suspect? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 1 23:52:06 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 01 May 2014 21:52:06 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1398981126.74.0.410393185554.issue21408@psf.upfronthosting.co.za> Benjamin Peterson added the comment: The subclass behavior is a red herring. I meant maybe object.__ne__ should check if the other object has a __ne__ method before falling back on ``not object.__eq__()``. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 00:13:45 2014 From: report at bugs.python.org (Shawn) Date: Thu, 01 May 2014 22:13:45 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1398982425.16.0.328191874958.issue21412@psf.upfronthosting.co.za> Changes by Shawn : ---------- nosy: +swalker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 00:24:36 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 May 2014 22:24:36 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1398983076.61.0.084740519538.issue21408@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, I see. Yes, that would seem more consistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 00:46:51 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 01 May 2014 22:46:51 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1398984411.45.0.598738112718.issue21412@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 00:49:32 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 01 May 2014 22:49:32 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1398984572.45.0.768363505205.issue21412@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: What compiler are you using?. I compile fine on Solaris with GCC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 01:03:33 2014 From: report at bugs.python.org (Samwyse) Date: Thu, 01 May 2014 23:03:33 +0000 Subject: [issue21413] urllib.request.urlopen dies on non-basic/digest auth schemes Message-ID: <1398985413.93.0.034829479965.issue21413@psf.upfronthosting.co.za> New submission from Samwyse: In Python 2.x, this opens an NTLM protected URL: opener = urllib2.build_opener(proxy_handler, auth_NTLM, auth_digest, auth_basic) urllib2.install_opener(opener) response = urllib2.urlopen(url) In Python 3.x, this raises an error: opener = urllib.request.build_opener(proxy_handler, auth_NTLM, auth_digest, auth_basic) urllib.request.install_opener(opener) response = urllib.request.urlopen(url) The error is: ValueError: AbstractDigestAuthHandler does not support the following scheme: 'NTLM' Removing auth_digest from the list of handlers allows the code to work. ---------- components: Library (Lib) messages: 217734 nosy: samwyse priority: normal severity: normal status: open title: urllib.request.urlopen dies on non-basic/digest auth schemes versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 01:11:10 2014 From: report at bugs.python.org (John Beck) Date: Thu, 01 May 2014 23:11:10 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1398985870.57.0.106141462906.issue21412@psf.upfronthosting.co.za> John Beck added the comment: Using Oracle Studio 12.3, same as mentioned in http://bugs.python.org/issue15963#msg170661 (as Stefan pointed out). I am using some of those flags but not all of them. I will try the others when I have a chance, then report back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 01:34:33 2014 From: report at bugs.python.org (Florent Xicluna) Date: Thu, 01 May 2014 23:34:33 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1398987273.94.0.198074287451.issue21408@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 02:14:49 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 02 May 2014 00:14:49 +0000 Subject: [issue21399] inspect and class methods In-Reply-To: <1398860523.15.0.277604564567.issue21399@psf.upfronthosting.co.za> Message-ID: <1398989689.91.0.824750870414.issue21399@psf.upfronthosting.co.za> Larry Hastings added the comment: By default AC emits "$type" for class methods, see dict_fromkeys in Objects/dictobject.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 03:28:11 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 02 May 2014 01:28:11 +0000 Subject: [issue21267] mktime_tz may return wrong result for past dates before Python 2.7.4 In-Reply-To: <1397678403.49.0.851331817917.issue21267@psf.upfronthosting.co.za> Message-ID: <1398994091.65.0.686197787713.issue21267@psf.upfronthosting.co.za> R. David Murray added the comment: Since you say the bug is fixed, what do you intend the purpose of this issue to be? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 03:29:27 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 02 May 2014 01:29:27 +0000 Subject: [issue21267] mktime_tz may return wrong result for past dates before Python 2.7.4 In-Reply-To: <1397678403.49.0.851331817917.issue21267@psf.upfronthosting.co.za> Message-ID: <1398994167.18.0.84628482467.issue21267@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, I missed the fact that you had closed it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 03:41:47 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 02 May 2014 01:41:47 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1398994907.91.0.550194367474.issue21332@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps you can avoid the 10 s deadlock timeout and threading in your test by closing the underlying input pipe file descriptor (or raw file object), without flushing it. Also, it seems to me that ?line_buffering=True? is redundant with ?write_through=True?. I?m not super familiar with the new write-through mode though, so I could be wrong. Perhaps the change in ?subprocess.py? may not be needed at least once Issue 21396 is fixed. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 03:49:13 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 02 May 2014 01:49:13 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1398995353.04.0.840398244847.issue21332@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry, it seems I was wrong on the second point. Looking closer, it seems write-through mode only flushes the TextIOWrapper layer, not the underlying binary file object, whereas line-buffering mode flushes everything to the OS, so the extra line_buffering=True flag would be needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 03:53:10 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 02 May 2014 01:53:10 +0000 Subject: [issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation In-Reply-To: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za> Message-ID: <1398995590.85.0.0701898811137.issue21396@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 04:04:07 2014 From: report at bugs.python.org (paul j3) Date: Fri, 02 May 2014 02:04:07 +0000 Subject: [issue9625] argparse: Problem with defaults for variable nargs when using choices In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za> Message-ID: <1398996247.77.0.824595863092.issue9625@psf.upfronthosting.co.za> Changes by paul j3 : Added file: http://bugs.python.org/file35128/notes.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 04:39:05 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 02 May 2014 02:39:05 +0000 Subject: [issue21363] io.TextIOWrapper always closes wrapped files In-Reply-To: <1398603389.33.0.793055654008.issue21363@psf.upfronthosting.co.za> Message-ID: <1398998345.66.0.716622685605.issue21363@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 05:01:07 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 02 May 2014 03:01:07 +0000 Subject: [issue21368] Check for systemd locale on startup if current locale is set to POSIX In-Reply-To: <1398627025.84.0.804520187603.issue21368@psf.upfronthosting.co.za> Message-ID: <1398999667.01.0.574950674845.issue21368@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 05:39:36 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 02 May 2014 03:39:36 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1399001976.71.0.86739470819.issue21364@psf.upfronthosting.co.za> Martin Panter added the comment: That particular revision isn?t sound so bad; I think the next revision, 78fb7f8cd349, which adds the make_streams_binary() function that replaces the variables is a worry though. This is the kind of code I use when I want to write binary data to stdout: output = sys.stdout.detach() sys.stdout = None # Avoid error message during shutdown, due to output being closed or garbage-collected output.write(...) This raises two issues: 1. Is the practice of setting sys.stdout to None documented or recommended anywhere? If not, could it be, or is there another way to do this? 2. The error message I am avoiding looks more broken than it could be: $ python3 -c 'from sys import stdout; stdout.detach().close()' Exception ignored in: $ The trailing dollar ($) sign just indicates that there was no newline printed. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 06:38:01 2014 From: report at bugs.python.org (akira) Date: Fri, 02 May 2014 04:38:01 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1399005481.2.0.304834737037.issue21332@psf.upfronthosting.co.za> akira added the comment: yes, line_buffering=(bufsize == 1) is necessary to support the current Python io implementation or if C implementation is fixed to avoid buffer.flush() on every write with write_through=True -- otherwise bufsize is not respected in text mode (it would always mean bufsize=0). Note: the current patch for issue #21396 (making C and Python io do the same thing) may break subprocess code with universal_newlines=True that expects (incorrectly) bufsize=0 by default -- as test_universal_newlines had (enabling universal_newlines shouldn't switch from bufsize=-1 to bufsize=0). <-- XXX backward compatibility issue! > Perhaps you can avoid the 10 s deadlock timeout and threading in your > test by closing the underlying input pipe file descriptor (or raw file > object), without flushing it. It is a good idea. There could be portability issues with the test: it relies on the fact that os.close doesn't flush already buffered data -- I don't know whether os.close causes flush on Windows (it doesn't on POSIX [1]: the data shall be discarded). [1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html I've uploaded a new patch with the updated tests. Please, review. ---------- Added file: http://bugs.python.org/file35129/subprocess-line-buffering-issue21332-ps3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 07:14:04 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Fri, 02 May 2014 05:14:04 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1399007644.03.0.303199399568.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Jim, The problems documented here are related to two cases (both apparently arriving from world of windows): 1. two relative paths with inverted slash in one of them (test\test2.txt vs test/test2.txt) 2. relative path vs absolute path (windows\temp\test.txt vs c:\windows\temp\test.txt) The extraction part seems to be doing a good job at writing the files into sane locations. IMHO, there's no point in trying to replace slashes or otherwise "normalize", as this would fix the cases where the presence of an inverted slashes should be noted in debug output. By the same token stripping the drive letter from the absolute path part would just deprive us from noticing such intricacies in these special zip files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 08:14:11 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 02 May 2014 06:14:11 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1399011251.67.0.833647920588.issue21332@psf.upfronthosting.co.za> Martin Panter added the comment: On second thoughts maybe the idea of closing the input is not such a good idea in practice. Once you call os.close() on the file descriptor, that descriptor becomes unallocated, and I can?t see any way to prevent p.stdin.close(), Popen() context, destructors, etc from trying to close the file descriptor again. If the Python test suite is ever multithreaded (I?m not really familiar with it), that would be a real problem. In any case closing an unallocated file descriptor is a bad idea. Maybe the deadlocking version is more appropriate after all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 09:14:29 2014 From: report at bugs.python.org (akira) Date: Fri, 02 May 2014 07:14:29 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1399014869.78.0.28144137829.issue21332@psf.upfronthosting.co.za> akira added the comment: to be clear: the test itself doesn't use threads, `python -mtest -j0` runs tests using multiple *processes*, not threads. There is no issue. If the test were to run in the presence of multiple threads then the issue would be the *explicit* p.stdin.close() in the test (look at the patch) that may close `p.stdin.fileno()` that might be opened in another thread (unrelated to the current test) after it was closed in the test the first time. I could call `getattr(p.stdin, 'buffer', p.stdin).raw.fd = -1` to avoid trying to close the fd the second time but I don't think it is necessary. I don't think tests are expected to run in the presence of multiple threads unless they start them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 09:39:41 2014 From: report at bugs.python.org (Alexander Boyd) Date: Fri, 02 May 2014 07:39:41 +0000 Subject: [issue21414] Add an intersperse function to itertools Message-ID: <1399016381.86.0.358283967216.issue21414@psf.upfronthosting.co.za> New submission from Alexander Boyd: Itertools would benefit greatly from a function (which I've named intersperse, after Haskell's equivalent) for yielding the items of an iterator with a given value placed between each. Sort of a str.join-like function, but for arbitrary sequences. Something like: >>> list(itertools.intersperse(1, [2, 3, 4])) [2, 1, 3, 1, 4] ---------- messages: 217746 nosy: javawizard priority: normal severity: normal status: open title: Add an intersperse function to itertools type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 10:23:25 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 08:23:25 +0000 Subject: [issue15104] Unclear language in __main__ description In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za> Message-ID: <1399019005.85.0.347216102959.issue15104@psf.upfronthosting.co.za> ?ric Araujo added the comment: Docs and indexing/cross-links in 2.7 should indeed be improved. I had forgotten which of 2.6 or 2.7 added support for executing packages thanks to __main__.py files and the docs don't contain an answer that's comprehensive and easy to find. ---------- assignee: docs at python -> eric.araujo nosy: +eric.araujo stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 12:29:57 2014 From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=) Date: Fri, 02 May 2014 10:29:57 +0000 Subject: [issue21415] Python __new__ method doc typo (it's a class and not a static method) Message-ID: <1399026596.96.0.389694886975.issue21415@psf.upfronthosting.co.za> New submission from Jurko Gospodneti?: Doc/reference/datamodel.rst documentation states that the __new__ method is a static method (in Python, not in C!) when it is in fact a class method. A patch has been prepared in the https://bitbucket.org/jurko/cpython repository. branch: datamodel_doc_typo_fix commit: 81c5ba188805e42292c3eb9cffa56fbd5b7c6aee But it'll probably be easier for you to just change that single word directly. :-D Hope this helps. Best regards, Jurko Gospodneti? ---------- assignee: docs at python components: Documentation hgrepos: 245 messages: 217748 nosy: Jurko.Gospodneti?, docs at python priority: normal severity: normal status: open title: Python __new__ method doc typo (it's a class and not a static method) type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 12:31:10 2014 From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=) Date: Fri, 02 May 2014 10:31:10 +0000 Subject: [issue21415] Python __new__ method doc typo (it's a class and not a static method) In-Reply-To: <1399026596.96.0.389694886975.issue21415@psf.upfronthosting.co.za> Message-ID: <1399026670.57.0.823164224804.issue21415@psf.upfronthosting.co.za> Changes by Jurko Gospodneti? : ---------- keywords: +patch Added file: http://bugs.python.org/file35130/81c5ba188805.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 14:07:35 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 02 May 2014 12:07:35 +0000 Subject: [issue21415] Python __new__ method doc typo (it's a class and not a static method) In-Reply-To: <1399026596.96.0.389694886975.issue21415@psf.upfronthosting.co.za> Message-ID: <1399032455.08.0.160204449904.issue21415@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Actually, no, it is a staticmethod. See Guido's tutorial from way back in version 2.2: [quote] __new__ is a static method. When defining it, you don't need to (but may!) use the phrase "__new__ = staticmethod(__new__)", because this is implied by its name (it is special-cased by the class constructor). [end quote] https://www.python.org/download/releases/2.2.3/descrintro I believe that this explains why you have to use this idiom inside __new__ when using super(): def __new__(cls, x): super().__new__(cls, x) If __new__ were a classmethod, the first argument "cls" would be provided automatically. If you try making __new__ a classmethod, it breaks: py> class Test: ... @classmethod ... def __new__(cls): ... pass ... py> x = Test() Traceback (most recent call last): File "", line 1, in TypeError: __new__() takes 1 positional argument but 2 were given whereas a staticmethod works fine. ---------- nosy: +steven.daprano resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 14:38:42 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 02 May 2014 12:38:42 +0000 Subject: [issue21399] inspect and class methods In-Reply-To: <1398989689.91.0.824750870414.issue21399@psf.upfronthosting.co.za> Message-ID: <20140502123840.GA3813@sleipnir.bytereef.org> Stefan Krah added the comment: > By default AC emits "$type" for class methods, see dict_fromkeys in Objects/dictobject.c. Thanks, good choice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 16:45:24 2014 From: report at bugs.python.org (eryksun) Date: Fri, 02 May 2014 14:45:24 +0000 Subject: [issue21415] Python __new__ method doc typo (it's a class and not a static method) In-Reply-To: <1399026596.96.0.389694886975.issue21415@psf.upfronthosting.co.za> Message-ID: <1399041924.91.0.331581890518.issue21415@psf.upfronthosting.co.za> eryksun added the comment: > I believe that this explains why you have to use this idiom > inside __new__ when using super(): > > def __new__(cls, x): > super().__new__(cls, x) Yes, if __new__ is defined and is a function, type_new replaces it with a staticmethod: http://hg.python.org/cpython/file/04f714765c13/Objects/typeobject.c#l2437 For example: >>> class A: __new__ = lambda c: 0 >>> type(vars(A)['__new__']) A heap type that defines __new__ has tp_new set to slot_tp_new. This looks up and calls __new__, with the class inserted as the first argument: http://hg.python.org/cpython/file/04f714765c13/Objects/typeobject.c#l6036 If you use a classmethod, looking up __new__ returns a method bound to the class. When called, this inserts the class in the args yet again: http://hg.python.org/cpython/file/04f714765c13/Objects/classobject.c#l321 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 16:51:54 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 02 May 2014 14:51:54 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1399042314.15.0.614216021241.issue21401@psf.upfronthosting.co.za> Brett Cannon added the comment: Yes, that's a possibility if we want to take the route and essentially prevent people from ever explicitly knowing that a str in Python 2 will be a str in Python 3 and they are okay with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 16:55:38 2014 From: report at bugs.python.org (Jim Jewett) Date: Fri, 02 May 2014 14:55:38 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1399007644.03.0.303199399568.issue6839@psf.upfronthosting.co.za> Message-ID: Jim Jewett added the comment: On Fri, May 2, 2014 at 1:14 AM, Adam Polkosnik > The problems documented here are related to two cases (both apparently arriving from world of windows): Good! I had thought you had even more! > 1. two relative paths with inverted slash in one of them (test\test2.txt vs test/test2.txt) My understanding from earlier -- and I may have been reading too much into some of the comments -- is that the standard defined \filename as an inferior alias for /filename and supported the fix. Notably, if you're extracting on windows with windows conventions, then windows will treat them identically anyhow. If you're extracting a windows file to a unix environment, then \t really should be translated to /t. > 2. relative path vs absolute path (windows\temp\test.txt vs c:\windows\temp\test.txt) These really are different, as leaving off the "C:" should mean "current drive", which will often (but not always) be C: This (and differing capitalization) are among the reasons to do the filename fix in a separate method, so that subclasses with more local knowledge can more easily do the right thing. Note that for python 3.4 and newer, pathlib may be helpful. It would probably even be possible to backport the essential parts as an implementation detail. But I'm not sure if that could be done compatibly with maintenance releases, or how much work it would take. > The extraction part seems to be doing a good job at writing the files into sane locations. > IMHO, there's no point in trying to replace slashes or otherwise "normalize", as this would fix the cases where the presence of an inverted slashes should be noted in debug output. My understanding had been that it was failing to extract entirely. So exactly what is the problem? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 17:19:29 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Fri, 02 May 2014 15:19:29 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1399043969.02.0.120285896664.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Extraction works fine, the issue was that raise() was creating an exception, and stoping the whole extraction process. When replaced with a warning, everything works fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 17:52:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 May 2014 15:52:44 +0000 Subject: [issue18604] Consolidate gui available checks in test.support In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za> Message-ID: <3gKyf22VQpz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 5f75eadecff1 by Zachary Ware in branch '2.7': Issue #18604: Consolidated checks for GUI availability. http://hg.python.org/cpython/rev/5f75eadecff1 New changeset eb361f69ddd1 by Zachary Ware in branch '3.4': Issue #18604: Consolidated checks for GUI availability. http://hg.python.org/cpython/rev/eb361f69ddd1 New changeset 82caec3865e3 by Zachary Ware in branch 'default': Closes #18604: Merge with 3.4 http://hg.python.org/cpython/rev/82caec3865e3 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 17:53:17 2014 From: report at bugs.python.org (Ethan Furman) Date: Fri, 02 May 2014 15:53:17 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1399045997.1.0.248837008134.issue6839@psf.upfronthosting.co.za> Ethan Furman added the comment: Adam Polkasnik said: -------------------- > Extraction works fine, the issue was that raise() was creating an exception, and > stopping the whole extraction process. That doesn't make sense. If an exception was "stopping the whole extraction process" then extraction was not working fine. Questions: - Are the names with '\' in them in the central directory, or the per-file header? - If in the central directory (which is the name we are going to use, yes?) how do we tell if the '\' should be a '/' or an escape? (such as '\t') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 18:42:24 2014 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Fri, 02 May 2014 16:42:24 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1399048944.22.0.632266510361.issue14019@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: The formatter module was deprecated in Python 3.4 and is scheduled for removal in Python 3.6. See [1] and [2]. --- [1] https://docs.python.org/3/library/formatter.html#module-formatter [2] https://docs.python.org/3/whatsnew/3.4.html#deprecated ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 18:43:01 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 02 May 2014 16:43:01 +0000 Subject: [issue21414] Add an intersperse function to itertools In-Reply-To: <1399016381.86.0.358283967216.issue21414@psf.upfronthosting.co.za> Message-ID: <1399048981.11.0.230099147059.issue21414@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 18:43:31 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 02 May 2014 16:43:31 +0000 Subject: [issue21413] urllib.request.urlopen dies on non-basic/digest auth schemes In-Reply-To: <1398985413.93.0.034829479965.issue21413@psf.upfronthosting.co.za> Message-ID: <1399049011.64.0.424521242798.issue21413@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 18:46:33 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 02 May 2014 16:46:33 +0000 Subject: [issue20544] Use specific asserts in operator tests In-Reply-To: <1391804710.79.0.27308793582.issue20544@psf.upfronthosting.co.za> Message-ID: <1399049193.5.0.866793617387.issue20544@psf.upfronthosting.co.za> Andrew Svetlov added the comment: LGTM. Ping? ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 18:46:42 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 02 May 2014 16:46:42 +0000 Subject: [issue21347] Don't use a list argument together with shell=True in subprocess' docs In-Reply-To: <1398366522.65.0.954174735085.issue21347@psf.upfronthosting.co.za> Message-ID: <1399049202.52.0.742496839945.issue21347@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:05:55 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 02 May 2014 17:05:55 +0000 Subject: [issue21335] Update importlib.__init__ to reset _frozen_importlib's loader to SourceFileLoader In-Reply-To: <1398265311.8.0.131352279084.issue21335@psf.upfronthosting.co.za> Message-ID: <1399050355.25.0.485510174876.issue21335@psf.upfronthosting.co.za> Brett Cannon added the comment: Even with setting SourceFileLoader, you still don't get file lines back. Why? Because all of the constructed objects in _frozen_importlib have their co_filename set before the back-patching in importlib.__init__ and so when the traceback module tries to do its thing it sees '' as the filename instead of importlib._bootstrap.__file__ which doesn't lead to linecache getting anything useful. IOW a whole lot of effort for code that people should never have to look at. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:08:01 2014 From: report at bugs.python.org (akira) Date: Fri, 02 May 2014 17:08:01 +0000 Subject: [issue21347] Don't use a list argument together with shell=True in subprocess' docs In-Reply-To: <1398366522.65.0.954174735085.issue21347@psf.upfronthosting.co.za> Message-ID: <1399050481.64.0.396298610069.issue21347@psf.upfronthosting.co.za> akira added the comment: I've checked the same documentation patch applies to both default (3.5) and 2.7 branches. There are no more instances of the misleading usage left (after applying the patch). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:10:39 2014 From: report at bugs.python.org (Derek Wilson) Date: Fri, 02 May 2014 17:10:39 +0000 Subject: [issue21416] argparse should accept bytes arguments as originally passed Message-ID: <1399050639.0.0.425035380654.issue21416@psf.upfronthosting.co.za> New submission from Derek Wilson: If I create an argument parser like: parser = argparse.ArgumentParser() parser.add_argument('somebytes', type=bytes, help='i want some bytes') parser.parse_args() the parse_args() call will raise an exception printing usage info indicating that an "invalid bytes value" was passed if any of the bytes on the command line are >127. if i'm specifying that i want bytes then i should expect that the argument should be interpreted as bytes and not text. I get that #8776 was closed because it makes sense not to clutter up internals, but in this instance i am building a command line parser and telling it exactly what i expect. if the solution from #8776 of os.fsencode(sys.argv) will definitely always work then argparse should do this internally if i tell it i expect bytes on the command line. ---------- components: Library (Lib) messages: 217761 nosy: underrun priority: normal severity: normal status: open title: argparse should accept bytes arguments as originally passed type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:19:57 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 02 May 2014 17:19:57 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za> Message-ID: <1399051197.44.0.765655060047.issue21037@psf.upfronthosting.co.za> Stefan Krah added the comment: Antoine, if you send me the buildbot credentials, we can get started. Environment vars: CC=clang ASAN_OPTIONS="allocator_may_return_null=1,handle_segv=0" I suggest to compile the release build, just --with-address-sanitizer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:22:03 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 17:22:03 +0000 Subject: [issue21397] tempfile.py: Fix grammar in docstring, comment typos In-Reply-To: <1398854871.81.0.354739462705.issue21397@psf.upfronthosting.co.za> Message-ID: <1399051323.16.0.532307796561.issue21397@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report and patch! I don't really see how "just" can be interpreted as applying to something else than "below", so I'm not sure the wording needs to be changed. The typo should be fixed. ---------- nosy: +eric.araujo stage: -> patch review versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:29:32 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 17:29:32 +0000 Subject: [issue21414] Add an intersperse function to itertools In-Reply-To: <1399016381.86.0.358283967216.issue21414@psf.upfronthosting.co.za> Message-ID: <1399051772.43.0.400135637772.issue21414@psf.upfronthosting.co.za> ?ric Araujo added the comment: I looked for a previous discussion of this on the Python mailing lists and found nothing. Existing solutions include https://twitter.com/snim2/status/393821419114483712 and http://stackoverflow.com/questions/5655708/python-most-elegant-way-to-intersperse-a-list-with-an-element Raymond is the one to decide whether this should be added. If he doesn't comment in the near future, feel free to propose this on python-ideas to see if people like it. You may also want to ask maintainers of projects like more-itertools if they have a similar function and if people use it. ---------- nosy: +eric.araujo, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:35:41 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 17:35:41 +0000 Subject: [issue21405] Allow using symbols from Unicode block "Superscripts and Subscripts" in identifiers In-Reply-To: <1398926695.28.0.870869900387.issue21405@psf.upfronthosting.co.za> Message-ID: <1399052141.41.0.999218759359.issue21405@psf.upfronthosting.co.za> ?ric Araujo added the comment: Many features are indeed discussed on this bug tracker, but for a big change like the one you propose we like to reach out to all of python-dev or all people on python-ideas to discuss pros and cons. The devguide should explain this in a little more detail. I don't know if the google group you posted to is a read-only or two-way mirror; the real list is found at https://mail.python.org/mailman/listinfo/python-ideas ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:36:36 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 17:36:36 +0000 Subject: [issue21405] Allow using symbols from Unicode block "Superscripts and Subscripts" in identifiers In-Reply-To: <1398926695.28.0.870869900387.issue21405@psf.upfronthosting.co.za> Message-ID: <1399052196.52.0.812015367073.issue21405@psf.upfronthosting.co.za> ?ric Araujo added the comment: FTR https://docs.python.org/devguide/#proposing-changes-to-python-itself ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:54:00 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 17:54:00 +0000 Subject: [issue21404] Document options used to control compression level in tarfile In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za> Message-ID: <1399053240.32.0.601918917721.issue21404@psf.upfronthosting.co.za> ?ric Araujo added the comment: I'm reclassifying this ticket as a doc bug, would you mind opening a separate ticket for zipfile? ---------- assignee: -> docs at python components: +Documentation -Library (Lib) keywords: +easy nosy: +docs at python, eric.araujo stage: -> needs patch title: Compression level for tarfile/zipfile -> Document options used to control compression level in tarfile versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:56:20 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 17:56:20 +0000 Subject: [issue21400] Code coverage documentation is out-of-date. In-Reply-To: <1398870474.7.0.668295680228.issue21400@psf.upfronthosting.co.za> Message-ID: <1399053380.21.0.022928307256.issue21400@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think Walter is referring to Ned's coverage.py project, i.e. the standard coverage module that you get with pip install coverage. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:57:37 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 17:57:37 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1399053457.09.0.95114445413.issue21398@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 19:59:39 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 17:59:39 +0000 Subject: [issue21391] PATCH: using the abspath shortcut in Lib/shutil In-Reply-To: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> Message-ID: <1399053579.67.0.854596226927.issue21391@psf.upfronthosting.co.za> ?ric Araujo added the comment: IMO either change would not improve the code at all. Suggest closing this. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:00:16 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 02 May 2014 18:00:16 +0000 Subject: [issue21417] Compression level for zipfile Message-ID: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za> New submission from Sworddragon: This is a fork from this ticket: http://bugs.python.org/issue21404 tarfile has a compression level and seems to get now the missing documentation for it. But there is still a compression level missing for zipfile. ---------- components: Library (Lib) messages: 217770 nosy: Sworddragon priority: normal severity: normal status: open title: Compression level for zipfile versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:00:24 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 02 May 2014 18:00:24 +0000 Subject: [issue21417] Compression level for zipfile In-Reply-To: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za> Message-ID: <1399053624.82.0.78770502704.issue21417@psf.upfronthosting.co.za> Changes by Sworddragon : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:01:11 2014 From: report at bugs.python.org (Sworddragon) Date: Fri, 02 May 2014 18:01:11 +0000 Subject: [issue21404] Document options used to control compression level in tarfile In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za> Message-ID: <1399053671.62.0.741471520421.issue21404@psf.upfronthosting.co.za> Sworddragon added the comment: Sure, here is the new ticket: http://bugs.python.org/issue21417 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:01:54 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 18:01:54 +0000 Subject: [issue21368] Check for systemd locale on startup if current locale is set to POSIX In-Reply-To: <1398627025.84.0.804520187603.issue21368@psf.upfronthosting.co.za> Message-ID: <1399053714.49.0.39958024418.issue21368@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:02:48 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 18:02:48 +0000 Subject: [issue21417] Compression level for zipfile In-Reply-To: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za> Message-ID: <1399053768.99.0.787102184341.issue21417@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +alanmcintyre stage: -> needs patch versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:07:51 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 18:07:51 +0000 Subject: [issue21366] Document that return in finally overwrites prev value In-Reply-To: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za> Message-ID: <1399054071.23.0.91322611284.issue21366@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks, your proposed wording sounds good to me. David (picked you seni-randomly as a senior core dev and native speaker), what do you think? ---------- nosy: +eric.araujo, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:09:58 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 02 May 2014 18:09:58 +0000 Subject: [issue21413] urllib.request.urlopen dies on non-basic/digest auth schemes In-Reply-To: <1398985413.93.0.034829479965.issue21413@psf.upfronthosting.co.za> Message-ID: <1399054198.05.0.653144141981.issue21413@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +orsenthil versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:23:15 2014 From: report at bugs.python.org (Shawn) Date: Fri, 02 May 2014 18:23:15 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1399054995.51.0.720480504312.issue13405@psf.upfronthosting.co.za> Changes by Shawn : ---------- nosy: +swalker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:29:08 2014 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 02 May 2014 18:29:08 +0000 Subject: [issue21391] PATCH: using the abspath shortcut in Lib/shutil In-Reply-To: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> Message-ID: <1399055348.31.0.503006507679.issue21391@psf.upfronthosting.co.za> Eric V. Smith added the comment: I disagree. It took me longer than I'd like to admit to track down the file history and understand it. I'd like to prevent other people from having to try and understand why it works this way. On the other hand, it looks like people have discovered it: https://mail.python.org/pipermail/tutor/2012-August/090891.html so getting rid of it isn't so simple. If we are going to keep it, we should add a test for it (which actually might exist, I haven't checked yet). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:41:31 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 02 May 2014 18:41:31 +0000 Subject: [issue18604] Consolidate gui available checks in test.support In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za> Message-ID: <1399056091.38.0.698448609202.issue18604@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thank you Zach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 20:45:35 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 02 May 2014 18:45:35 +0000 Subject: [issue21366] Document that return in finally overwrites prev value In-Reply-To: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za> Message-ID: <1399056335.45.0.0819932244967.issue21366@psf.upfronthosting.co.za> R. David Murray added the comment: The precisionist in me isn't quite happy, but any wording I've come up with to make it more precise isn't as informative :) (The 'real' situation is that the return value of the function is determined by the last return statement executed, which in turn is determined by the try/finally logic....but as far as I can see the suggested phrasing is equivalent to that in every respect that matters). I also have an impulse to add "so don't do that" :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 21:11:02 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 02 May 2014 19:11:02 +0000 Subject: [issue21368] Check for systemd locale on startup if current locale is set to POSIX In-Reply-To: <1398627025.84.0.804520187603.issue21368@psf.upfronthosting.co.za> Message-ID: <1399057862.26.0.351789499422.issue21368@psf.upfronthosting.co.za> Stefan Krah added the comment: Why is the default encoding of POSIX wrong on a modern Linux system? Today I installed Debian testing, and the first question of the installer is to choose between "C" and "English" locales for the install. This with the remark that the chosen locale will be the default system locale. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 21:22:40 2014 From: report at bugs.python.org (Robert Snoeberger) Date: Fri, 02 May 2014 19:22:40 +0000 Subject: [issue21418] Segv during call to super_init in application embedding Python interpreter. Message-ID: <1399058560.74.0.137672140336.issue21418@psf.upfronthosting.co.za> New submission from Robert Snoeberger: While embedding the Python interpreter in an application, I have encountered a crash when the built-in function 'super' is invoked with no arguments. The crash occurs during a call to PyObject_Call. A file is attached, super_invoke.c, that reproduces the crash. The reproduction steps on my machine are the following: % gcc -o super_invoke super_invoke.c -I/path_to_py/include/python3.5m -L/path_to_py/lib -lpthread -ldl -lutil -lm -lpython3.5m -Xlinker -export-dynamic % ./super_invoke Call super with no arguments... Segmentation fault % The crash appears to occur in the function super_init contained in the file Objects/typeobject.c. The code path enters the if statement that checks for no input arguments. The following two lines cause the crash. PyFrameObject *f = PyThreadState_GET()->frame; PyCodeObject *co = f->f_code; The PyFrameObject pointer 'f' is NULL. ---------- files: super_invoke.c messages: 217777 nosy: snoeberger priority: normal severity: normal status: open title: Segv during call to super_init in application embedding Python interpreter. type: crash versions: Python 3.5 Added file: http://bugs.python.org/file35131/super_invoke.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 21:30:24 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Fri, 02 May 2014 19:30:24 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1399059024.43.0.508167797649.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Ethan, I'd refer you to msg92309... And When testing with WinZip it looks like this: No errors detected in compressed data of C:\Downloads\test.zip. Testing ... Testing test\ OK Testing test\test2.txt OK Testing test1.txt OK Then in python: Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AM D64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import zipfile >>> zf = zipfile.ZipFile('test.zip') >>> namelist = zf.namelist() >>> namelist ['test/', 'test/test2.txt', 'test1.txt'] >>> for af in namelist: ... zf.read(af) ... Traceback (most recent call last): File "", line 2, in File "c:\Python34\lib\zipfile.py", line 1117, in read with self.open(name, "r", pwd) as fp: File "c:\Python34\lib\zipfile.py", line 1180, in open % (zinfo.orig_filename, fname)) zipfile.BadZipFile: File name in directory 'test\\' and header b'test/' differ. So, based on that everything is already converted to forward slashes for the extraction. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 21:46:04 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 19:46:04 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1399059964.76.0.554172164896.issue21398@psf.upfronthosting.co.za> STINNER Victor added the comment: "LC_CTYPE=C: pydoc leaves terminal in an unusable state" In the use case, pydoc doesn't touch the terminal, it's the pager: the program "less". I don't see how to ensure that the terminal state is restored, even on error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:03:18 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 20:03:18 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1399060998.24.0.681552028656.issue21412@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:04:18 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 20:04:18 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1399061058.96.0.0434406464408.issue21412@psf.upfronthosting.co.za> STINNER Victor added the comment: "LD_LIBRARY_PATH=/builds/jbeck/ul-python-3/components/python/python34/build/sparcv9 ./python -E -S -m sysconfig --generate-posix-vars Fatal Python error: PyThreadState_Get: no current thread" Could you please run this command in gdb and copy/paste the C traceback (gdb command "where") where the fatal error occurs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:07:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 May 2014 20:07:29 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <3gL4J02fPkz7Ll5@mail.python.org> Roundup Robot added the comment: New changeset 8704198680ba by Victor Stinner in branch 'default': Issue #21393: random.c: on Windows, close the hCryptProv handle at exit http://hg.python.org/cpython/rev/8704198680ba ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 21:58:55 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 02 May 2014 19:58:55 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399060735.2.0.6634722801.issue21121@psf.upfronthosting.co.za> Changes by Stefan Krah : Added file: http://bugs.python.org/file35134/issue21121-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 21:50:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 19:50:56 +0000 Subject: [issue21418] Segv during call to super_init in application embedding Python interpreter. In-Reply-To: <1399058560.74.0.137672140336.issue21418@psf.upfronthosting.co.za> Message-ID: <1399060256.89.0.608959749156.issue21418@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 21:58:39 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 02 May 2014 19:58:39 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399060719.06.0.671150695151.issue21121@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, Ned. I'm attaching a second version of the existing patch with improved error handling and a fix for test_distutils, which failed. The result is slightly overcomplicated, so I came up with a different approach in issue21121-3.diff. Thoughts? ---------- Added file: http://bugs.python.org/file35133/issue21121-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:07:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 20:07:47 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1399061267.48.0.482947847505.issue21393@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:10:48 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 02 May 2014 20:10:48 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1399059964.76.0.554172164896.issue21398@psf.upfronthosting.co.za> Message-ID: <20140502201047.GA32210@sleipnir.bytereef.org> Stefan Krah added the comment: STINNER Victor wrote: > I don't see how to ensure that the terminal state is restored, even on error. Python2 suppresses the exception until after normal exit (pressing 'q'). I think that behavior is better. In Python3 you can also get the unusable terminal by pressing Ctrl-C, i.e. without any UnicodeError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 21:39:18 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 19:39:18 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1399059558.44.0.820449245901.issue21398@psf.upfronthosting.co.za> STINNER Victor added the comment: heapq documentation contains "Fran?ois" which is not encodable to ASCII. When using LC_ALL=C, the locale encoding is ASCII (at least on Linux). It's not easy to specify a different error handler globally in pydoc, different functions are used and child processes are spawned. The subprocess module doesn't allow to specify an error handler different than strict (see #6135). I propose pydoc_encoding.patch which escapes manually non-encodable characters. I chose sys.getfilesystemencoding(), I'm not sure that it's the encoding used for all cases of getpager() on all platforms. For example, on Windows, sys.getfilesystemencoding() is the ANSI code page, whereas sys.stdout.encoding is the OEM code page. ---------- keywords: +patch Added file: http://bugs.python.org/file35132/pydoc_encoding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:31:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 May 2014 20:31:29 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <3gL4qh4JhvzQTH@mail.python.org> Roundup Robot added the comment: New changeset 5b0fda8f5718 by Victor Stinner in branch 'default': Issue #21233: Add new C functions: PyMem_RawCalloc(), PyMem_Calloc(), http://hg.python.org/cpython/rev/5b0fda8f5718 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:35:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 20:35:08 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1399062908.1.0.0465587922034.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: > There is no need to hurry. I changed my mind :-p It should be easier for numpy to test the development version of Python. Let's wait for buildbots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:51:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 20:51:47 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) Message-ID: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch modifies long_lshift() to allocate the result using calloc() instead of malloc(). The goal is to avoid allocating physical memory for the least significat digits (zeros). According to my tests in issue #21233 (calloc), Linux and Windows have an optimized calloc() functions and at least Linux avoids allocating memory for pages initialized by zeros until pages at modified. ---------- files: long_lshift.patch keywords: patch messages: 217787 nosy: haypo, pitrou priority: normal severity: normal status: open title: Use calloc() instead of malloc() for int << int (lshift) type: performance versions: Python 3.5 Added file: http://bugs.python.org/file35135/long_lshift.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:53:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 20:53:53 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399064033.08.0.507927065359.issue21419@psf.upfronthosting.co.za> STINNER Victor added the comment: bench_long_rshift.py: Microbenchmark for int << int (lshift) operation. Results on Linux: Common platform: Bits: int=32, long=64, long long=64, size_t=64, void*=64 Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Python unicode implementation: PEP 393 Timer: time.perf_counter CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz Platform: Linux-3.13.9-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Platform of campaign orig: SCM: hg revision=5b0fda8f5718 tag=tip branch=default date="2014-05-02 22:31 +0200" Python version: 3.5.0a0 (default:5b0fda8f5718, May 2 2014, 22:47:06) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Date: 2014-05-02 22:47:12 Timer precision: 46 ns Platform of campaign calloc: Timer precision: 49 ns Python version: 3.5.0a0 (default:5b0fda8f5718+, May 2 2014, 22:45:58) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Date: 2014-05-02 22:46:42 SCM: hg revision=5b0fda8f5718+ tag=tip branch=default date="2014-05-02 22:31 +0200" ----------------+-------------+---------------- Tests?????????? | ???????orig | ?????????calloc ----------------+-------------+---------------- 1 << (2 ** 0)?? | ??39 ns (*) | ??????????38 ns 1 << (2 ** 1)?? | ??38 ns (*) | ??????????37 ns 1 << (2 ** 3)?? | ??38 ns (*) | ??????????37 ns 1 << (2 ** 5)?? | ??42 ns (*) | ????39 ns (-8%) 1 << (2 ** 10)? | ??43 ns (*) | ???37 ns (-14%) 1 << (2 ** 15)? | ?157 ns (*) | ???90 ns (-43%) 1 << (2 ** 20)? | 3.91 us (*) | ???74 ns (-98%) 1 << (2 ** 25)? | ?206 us (*) | ??86 ns (-100%) 1 << (2 ** 28)? | 4.06 ms (*) | ?4.1 us (-100%) 123 << 1??????? | ??11 ns (*) | ??????????12 ns 12345678 << 1?? | ??11 ns (*) | ??????????12 ns 12345678 << 100 | ??11 ns (*) | ??????????11 ns ----------------+-------------+---------------- Total?????????? | 4.27 ms (*) | 4.57 us (-100%) ----------------+-------------+---------------- ---------- Added file: http://bugs.python.org/file35136/bench_long_rshift.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 22:59:22 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 02 May 2014 20:59:22 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399064362.41.0.320751040863.issue21419@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Looks like you forgot to actually use the use_calloc parameter you put in the long_alloc prototype. It accepts it, but it's never used or passed to another function. So right now, the only difference in behavior is that there is an extra layer of function calls involved in _PyLong_New. On that note, might it make sense to change all other calls to _PyLong_New within longobject.c to use long_alloc(size, 0) to at least make long object's themselves avoid the overhead of the extra function call? Maybe I'm overestimating how much of a difference an extra C level function call will make, but it seems like PyLongs make new PyLongs an awful lot. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:00:55 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 02 May 2014 21:00:55 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399064455.75.0.473571052173.issue21419@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Given your benchmarks show improvements (you posted while I was typing my last comment), I'm guessing it's just the posted patch that's wrong, and your local changes actually use use_calloc? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:02:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 21:02:53 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399064573.68.0.14015774699.issue21419@psf.upfronthosting.co.za> STINNER Victor added the comment: Without the patch, 1 << (2**29) allocates 69.9 MB. With the patch, 1 << (2**29) allocates 0.1 MB (104 KB). Without the patch, $ ./python Python 3.5.0a0 (default:5b0fda8f5718, May 2 2014, 22:47:06) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux >>> import os >>> os.system("grep RSS /proc/%s/status" % os.getpid()) VmRSS: 6164 kB >>> x=1 << (2**29) >>> os.system("grep RSS /proc/%s/status" % os.getpid()) VmRSS: 76064 kB With the patch: haypo at selma$ ./python Python 3.5.0a0 (default:5b0fda8f5718+, May 2 2014, 22:55:47) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system("grep RSS /proc/%s/status" % os.getpid()) VmRSS: 5864 kB >>> x=1 << (2**29) >>> os.system("grep RSS /proc/%s/status" % os.getpid()) VmRSS: 5968 kB ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:10:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 21:10:15 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399065015.51.0.725173698422.issue21419@psf.upfronthosting.co.za> STINNER Victor added the comment: > Looks like you forgot to actually use the use_calloc parameter you put in the long_alloc prototype. It accepts it, but it's never used or passed to another function. Oh f###, you're right. See new patch. I ran again the new benchmark: my (updated) patch makes most operations slower, except for "1 << (2 ** 28)". For 1 << (2 ** 28), it's much faster, but it is worth to modify long_lshift() for this rare use case? Updated benchmark: Common platform: Timer: time.perf_counter Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Platform: Linux-3.13.9-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz Python unicode implementation: PEP 393 Bits: int=32, long=64, long long=64, size_t=64, void*=64 CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Platform of campaign orig: Python version: 3.5.0a0 (default:5b0fda8f5718, May 2 2014, 22:47:06) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] SCM: hg revision=5b0fda8f5718 tag=tip branch=default date="2014-05-02 22:31 +0200" Timer precision: 46 ns Date: 2014-05-02 22:47:12 Platform of campaign calloc2: Python version: 3.5.0a0 (default:5b0fda8f5718+, May 2 2014, 23:04:59) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Date: 2014-05-02 23:05:23 SCM: hg revision=5b0fda8f5718+ tag=tip branch=default date="2014-05-02 22:31 +0200" Timer precision: 45 ns ----------------+-------------+---------------- Tests?????????? | ???????orig | ????????calloc2 ----------------+-------------+---------------- 1 << (2 ** 0)?? | ??39 ns (*) | ???50 ns (+30%) 1 << (2 ** 1)?? | ??38 ns (*) | ???47 ns (+22%) 1 << (2 ** 3)?? | ??38 ns (*) | ???48 ns (+26%) 1 << (2 ** 5)?? | ??42 ns (*) | ???50 ns (+17%) 1 << (2 ** 10)? | ??43 ns (*) | ???53 ns (+23%) 1 << (2 ** 15)? | ?157 ns (*) | ??172 ns (+10%) 1 << (2 ** 20)? | 3.91 us (*) | ????????3.95 us 1 << (2 ** 25)? | ?206 us (*) | ???218 us (+5%) 1 << (2 ** 28)? | 4.06 ms (*) | 4.29 us (-100%) 123 << 1??????? | ??11 ns (*) | ??????????11 ns 12345678 << 1?? | ??11 ns (*) | ??????????11 ns 12345678 << 100 | ??11 ns (*) | ??????????11 ns ----------------+-------------+---------------- Total?????????? | 4.27 ms (*) | ??226 us (-95%) ----------------+-------------+---------------- ---------- Added file: http://bugs.python.org/file35137/long_lshift2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:12:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 21:12:06 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399065126.65.0.692053087282.issue21419@psf.upfronthosting.co.za> STINNER Victor added the comment: > Without the patch, 1 << (2**29) allocates 69.9 MB. With the patch, 1 << (2**29) allocates 0.1 MB (104 KB). This is still true with long_lshift2.patch (except that in my new test, it allocates 196 kB). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:13:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 21:13:20 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1399065200.52.0.633361896364.issue21233@psf.upfronthosting.co.za> STINNER Victor added the comment: Antoine Pitrou wrote: > The real use case I envision is with huge powers of two. If I write: > x = 2 ** 1000000 I created the issue #21419 for this idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:16:55 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 02 May 2014 21:16:55 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399065415.15.0.865384168051.issue21419@psf.upfronthosting.co.za> Josh Rosenberg added the comment: While you're doing this, might it make sense to add a special case to long_pow so it identifies cases where a (digit-sized) value with an absolute value equal to a power of 2 is being raised to a positive integer exponent, and convert said cases to equivalent left shifts? Identifying powers of 2 can be done in constant time with no memory overhead for register sized values (see http://graphics.stanford.edu/~seander/bithacks.html#DetermineIfPowerOf2 ); if you've already handled the case for 0, then checking if it's a power of 2 is just: (v & (v - 1)) == 0 It adds a little complexity, but even just handling 2 alone specially would at least make it so the semi-common case of making a large power of 2 doesn't have significantly different performance using 2 ** (numbits - 1) instead of 1 << (numbits - 1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:19:54 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 02 May 2014 21:19:54 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399065594.92.0.3754815569.issue21419@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I swear, I need to refresh before I post a long comment. If this is slowing everything down a little just to make 1 << (2 ** 29) faster (and did you really mean 1 << (1 << 29) ? :-) ), then I'd say drop it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:26:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 May 2014 21:26:17 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <3gL62w4jnNz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 62438d1b11c7 by Victor Stinner in branch 'default': Issue #21233: Oops, Fix _PyObject_Alloc(): initialize nbytes before going to http://hg.python.org/cpython/rev/62438d1b11c7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:27:34 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 02 May 2014 21:27:34 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399066054.82.0.182500330097.issue21419@psf.upfronthosting.co.za> Josh Rosenberg added the comment: One possible way to salvage it: Have you considered declaring long_alloc as Py_LOCAL_INLINE, or, now that I've checked #5553, a macro for long_alloc, so it gets inlined, and doesn't add the check overhead to everything (since properly inlining with a constant argument to use_calloc should make the optimizer trim the unused code path at compile time)? Probably not very PEP7 friendly to macro-ize something that long I'm guessing... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:43:47 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 02 May 2014 21:43:47 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399067027.98.0.4649821802.issue21419@psf.upfronthosting.co.za> Josh Rosenberg added the comment: And now that I'm thinking about it, the probable cause of the slowdown is that, for any PyLongObject that's smaller than PAGESIZE (give or take), using Calloc means calloc is just calling memset to zero the PyLongObject header and the "used" part of the high order bits along with everything else, where the original Malloc code avoided performing two passes over the memory, initializing each byte in order, and writing each one exactly once. The Calloc approach uses two passes, and the second one isn't wholly sequential, so it may be getting bit by the CPU cache not keeping up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:54:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 21:54:22 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n Message-ID: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> New submission from STINNER Victor: The algorithm for 2 ** n (long_pow) is slower than 1 << n algorithm (long_lshift). I propose to compute x**y as 1<= 0. Attached patch implements this idea. According to my microbenchmark, it is 4x faster to small power (2**0 .. 2**1024) and up to 340x faster for large power (2**(2**28)). ---------- files: pow2.patch keywords: patch messages: 217800 nosy: haypo priority: normal severity: normal status: open title: Optimize 2 ** n: implement it as 1 << n type: performance versions: Python 3.5 Added file: http://bugs.python.org/file35138/pow2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:54:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 21:54:54 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n In-Reply-To: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> Message-ID: <1399067694.45.0.608029651721.issue21420@psf.upfronthosting.co.za> STINNER Victor added the comment: Results of bench_pow2.py on Linux. Common platform: CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz Platform: Linux-3.13.9-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug Timer: time.perf_counter Python unicode implementation: PEP 393 Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Bits: int=32, long=64, long long=64, size_t=64, void*=64 Platform of campaign orig: Date: 2014-05-02 23:45:29 SCM: hg revision=62438d1b11c7 tag=tip branch=default date="2014-05-02 23:26 +0200" Timer precision: 49 ns Python version: 3.5.0a0 (default:62438d1b11c7, May 2 2014, 23:45:22) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Platform of campaign pow2: Python version: 3.5.0a0 (default:62438d1b11c7+, May 2 2014, 23:47:50) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] SCM: hg revision=62438d1b11c7+ tag=tip branch=default date="2014-05-02 23:26 +0200" Timer precision: 51 ns Date: 2014-05-02 23:48:03 ---------------+--------------+---------------- Tests????????? | ????????orig | ???????????pow2 ---------------+--------------+---------------- 2 ** 0???????? | ???40 ns (*) | ????44 ns (+9%) 2 ** 1???????? | ??264 ns (*) | ???62 ns (-76%) 2 ** 3???????? | ??270 ns (*) | ???62 ns (-77%) 2 ** 5???????? | ??269 ns (*) | ???62 ns (-77%) 2 ** 10??????? | ??278 ns (*) | ???63 ns (-78%) 2 ** 15??????? | ??299 ns (*) | ???62 ns (-79%) 2 ** 20??????? | ??287 ns (*) | ???62 ns (-78%) 2 ** 25??????? | ??302 ns (*) | ???62 ns (-79%) 2 ** 28??????? | ??293 ns (*) | ???62 ns (-79%) 2 ** (2 ** 0)? | ??264 ns (*) | ???62 ns (-77%) 2 ** (2 ** 1)? | ??264 ns (*) | ???62 ns (-76%) 2 ** (2 ** 3)? | ??264 ns (*) | ???62 ns (-77%) 2 ** (2 ** 5)? | ??286 ns (*) | ???68 ns (-76%) 2 ** (2 ** 10) | ??740 ns (*) | ???68 ns (-91%) 2 ** (2 ** 15) | ?93.1 us (*) | ?180 ns (-100%) 2 ** (2 ** 20) | ?3.94 ms (*) | 3.89 us (-100%) 2 ** (2 ** 25) | ??154 ms (*) | ?213 us (-100%) 2 ** (2 ** 28) | 1.36 sec (*) | 4.01 ms (-100%) ---------------+--------------+---------------- Total????????? | 1.52 sec (*) | 4.23 ms (-100%) ---------------+--------------+---------------- ---------- Added file: http://bugs.python.org/file35139/bench_pow2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:57:35 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 21:57:35 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n In-Reply-To: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> Message-ID: <1399067855.43.0.254672228784.issue21420@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, the patch implements another micro-optimization: "(x << 0) is x" becomes True. I included it in the same patch to reduce the overhead for 2 ** 0. ---------- nosy: +josh.rosenberg, pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:57:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 May 2014 21:57:58 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n In-Reply-To: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> Message-ID: <1399067878.39.0.473165184323.issue21420@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 2 23:59:47 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 02 May 2014 21:59:47 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1399067987.79.0.540591768117.issue21398@psf.upfronthosting.co.za> Stefan Krah added the comment: The patch works well BTW. We can create another issue for the general misbehavior of pydoc with other exceptions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 00:31:37 2014 From: report at bugs.python.org (John Beck) Date: Fri, 02 May 2014 22:31:37 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1399069897.27.0.324863243413.issue21412@psf.upfronthosting.co.za> John Beck added the comment: Victor: sure; see attached. ---------- Added file: http://bugs.python.org/file35140/where.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 00:35:41 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 22:35:41 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399070141.73.0.0811130017256.issue21121@psf.upfronthosting.co.za> ?ric Araujo added the comment: I like issue21121-3.diff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 00:49:15 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 02 May 2014 22:49:15 +0000 Subject: [issue21385] Compiling modified AST crashes on debug build unless linenumbering discarded In-Reply-To: <1398762010.89.0.992252148712.issue21385@psf.upfronthosting.co.za> Message-ID: <1399070955.8.0.308464695663.issue21385@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 3.1 to 3.3 only get internet security patcches, and I don't believe this is such an issue. It is not clear from the title (a statement, not a request) and your text what specific patch you would like. If you want to 'reopen a discussion', please post on python-ideas. It appears that your idea is to abandon a rule that does not work. But it is not clear from a first reading exactly what alternative you want. ---------- nosy: +terry.reedy versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 01:06:39 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 02 May 2014 23:06:39 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1399071999.54.0.0560711878566.issue21402@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A reference to a non-existent attribute fails no matter who calls the function. Stephen, can you suggest a patch, perhaps based on code in other functions that try to access _default_root? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 01:14:58 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 02 May 2014 23:14:58 +0000 Subject: [issue21414] Add an intersperse function to itertools In-Reply-To: <1399016381.86.0.358283967216.issue21414@psf.upfronthosting.co.za> Message-ID: <1399072498.16.0.00231308752846.issue21414@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 01:58:02 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 May 2014 23:58:02 +0000 Subject: [issue21352] improve documentation indexing In-Reply-To: <1398457661.12.0.679738685491.issue21352@psf.upfronthosting.co.za> Message-ID: <1399075082.4.0.676430969784.issue21352@psf.upfronthosting.co.za> ?ric Araujo added the comment: I have to agree the index pages are often frustrating for me too. Not sure if this involves code changes in Sphinx itself or if we can improve the markup in the Python docs sources. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 02:02:42 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 03 May 2014 00:02:42 +0000 Subject: [issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__ Message-ID: <1399075361.96.0.75684702655.issue21421@psf.upfronthosting.co.za> New submission from Josh Rosenberg: Unlike the other collections ABCs, MappingView and its subclasses (Keys|Items|Values)View don't define __slots__, so users inheriting them to take advantage of the mix-in methods get a __dict__ and __weakref__, even if they try to avoid it by declaring their own __slots__. This is sub-optimal (I don't think any library class should leave __slots__ undefined, but it's particularly bad when they're intended to be used a base classes). I've attached a patch that defines __slots__ for all of them; MappingView explicitly declares its _mapping slot, and the rest declare no slots at all. Only negative I can think of is that if the user provides their own __init__, doesn't call the super().__init__, and uses a different name than _mapping for whatever data structure they actually use, then there will be a pointer reserved for _mapping that never gets set. That said, if they don't define _mapping, none of the mix-in methods work anyway, so they may as well not inherit directly, and instead just use *View.register to become a virtual subclass. ---------- files: slots_for_mappingview_abcs.patch keywords: patch messages: 217809 nosy: josh.rosenberg priority: normal severity: normal status: open title: ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__ Added file: http://bugs.python.org/file35141/slots_for_mappingview_abcs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 02:11:03 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 03 May 2014 00:11:03 +0000 Subject: [issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__ In-Reply-To: <1399075361.96.0.75684702655.issue21421@psf.upfronthosting.co.za> Message-ID: <1399075863.67.0.551207770851.issue21421@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Hmm... First patch isn't generating a review diff (I'm guessing because my VM's time sync went farkakte). Trying again. ---------- Added file: http://bugs.python.org/file35142/slots_for_mappingview_abcs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 02:12:08 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 03 May 2014 00:12:08 +0000 Subject: [issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__ In-Reply-To: <1399075361.96.0.75684702655.issue21421@psf.upfronthosting.co.za> Message-ID: <1399075928.43.0.315987010583.issue21421@psf.upfronthosting.co.za> Changes by Josh Rosenberg : Removed file: http://bugs.python.org/file35141/slots_for_mappingview_abcs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 02:18:15 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 03 May 2014 00:18:15 +0000 Subject: [issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__ In-Reply-To: <1399075361.96.0.75684702655.issue21421@psf.upfronthosting.co.za> Message-ID: <1399076295.1.0.29076243827.issue21421@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I also wrote a slightly more thorough patch that simplifies some of the method implementations (largely just replacing a bunch of for/if/return True/False else return False/True with any/all calls against a generator expression). The one behavior difference is that I dramatically simplified Sequence's __iter__; the original just kept indexing until it got IndexError, the replacement just runs len(self) times, on the theory that a self-mutating Sequence should write its own __iter__, and we shouldn't jump through hoops to accommodate unsupported behavior like mutating a Sequence during iteration. All tests pass under both patches. ---------- Added file: http://bugs.python.org/file35143/collections_abc_cleanup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 03:23:26 2014 From: report at bugs.python.org (paul j3) Date: Sat, 03 May 2014 01:23:26 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1399080206.09.0.194794393215.issue14191@psf.upfronthosting.co.za> paul j3 added the comment: I encountered a conflict when merging this patch with http://bugs.python.org/issue15112. In my first testcase, 'cmd' and 'rest' failed the 'required' test in phase one of 'intermixed'. That's because 15112 postponed parsing them (with nargs=0/suppressed). I got around that by temporarily setting the 'required' attribute to False. The whole issue of when (or even whether) a positional that is satisfied with 0 arguments, is consumed, is a bit messy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 06:29:15 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 03 May 2014 04:29:15 +0000 Subject: [issue21368] Check for systemd locale on startup if current locale is set to POSIX In-Reply-To: <1399057862.26.0.351789499422.issue21368@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: That's the problem - even on UTF-8 systems, Linux programs will often be started in a misconfigured environment: the POSIX locale. Python 2 doesn't try to interpret the binary data as text, so it doesn't care. Python 3 *does* care, since it automatically converts several pieces of OS provided data to text using the locale encoding. systemd tackles that by adding the extra config file to ensure *all* the environments it creates get the right config, and to provide a more reliable "source of truth" as to the actual likely encoding of system interfaces. However, a fair bit of groundwork is needed to avoid any innate reliance on the locale encoding before we can reliably override it by default, so this issue is unlikely to go anywhere before PEP 432 is implemented (and even then, actually changing the behaviour would be a separate discussion). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 06:33:21 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 03 May 2014 04:33:21 +0000 Subject: [issue21414] Add an intersperse function to itertools In-Reply-To: <1399016381.86.0.358283967216.issue21414@psf.upfronthosting.co.za> Message-ID: <1399091601.92.0.80986152209.issue21414@psf.upfronthosting.co.za> Raymond Hettinger added the comment: What is the use case for interspersing values? I've not run across anything like it ever before. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 06:50:08 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 03 May 2014 04:50:08 +0000 Subject: [issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__ In-Reply-To: <1399075361.96.0.75684702655.issue21421@psf.upfronthosting.co.za> Message-ID: <1399092608.68.0.830769514668.issue21421@psf.upfronthosting.co.za> Raymond Hettinger added the comment: At first glance, this seems like a reasonable request. I leave it open for comments for a while before proceeding. ---------- assignee: -> rhettinger components: +Library (Lib) nosy: +rhettinger type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 06:59:56 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 03 May 2014 04:59:56 +0000 Subject: [issue20544] Use specific asserts in operator tests In-Reply-To: <1391804710.79.0.27308793582.issue20544@psf.upfronthosting.co.za> Message-ID: <1399093196.46.0.340638032634.issue20544@psf.upfronthosting.co.za> Raymond Hettinger added the comment: While this looks harmless, I seriously question whether it is an improvement. For example, how is this any better? - self.assertTrue(operator.setitem(a, 0, 2) is None) + self.assertIsNone(operator.setitem(a, 0, 2)) This error message for the first is already perfectly clear. I don't see anything that warrants the code churn. Also remember that changing tests is hazardous. We don't have tests for the tests. So, if a test gets damaged, we won't know about it. The particular patch seems fine, but the whole exercise of going through the test suite and altering the tests is a dubious. The odds of us getting ANY value out of this is vanishingly small. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 07:38:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 03 May 2014 05:38:46 +0000 Subject: [issue20544] Use specific asserts in operator tests In-Reply-To: <1391804710.79.0.27308793582.issue20544@psf.upfronthosting.co.za> Message-ID: <1399095526.78.0.0380932051047.issue20544@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The generic error message for the first is 'False is not true'. Clear but useless. The error message for the second is the more specific ' is not None'. Since the expression was supposed to evaluate to None, but did not, it would be helpful to me, at least, to know what it did evaluate to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 08:50:25 2014 From: report at bugs.python.org (akira) Date: Sat, 03 May 2014 06:50:25 +0000 Subject: [issue20866] segfailt with os.popen and SIGPIPE In-Reply-To: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za> Message-ID: <1399099825.49.0.614134451524.issue20866@psf.upfronthosting.co.za> akira added the comment: I can't reproduce it on Ubuntu 12.04 with Python 2.7.3, 2.7.6, 3.2, tip -- no segfault. It prints the expected output on both Python 2 and 3: (standard input) io-error "(standard input)" is printed by grep due to --files-with-match option io-error (Broken pipe) is because grep exits as soon as it sees the first decimal zero due to `--files-with-match 0` args without waiting for all input to arrive therefore the subsequent attempts by the parent python process to write to grep fail with BrokenPipeError. You could get the same behaviour using "python -c pass" instead of grep. If the input is less than an OS pipe buffer (~64K) then fd.write succeeds because the system call os.write(pipe, input) succeeds whether the child process reads its input or not. Introducing a delay before writing to the child process generates the error reliably even for small input because the delay allows the child process to exit. Despite being stdio-based Python 2 io behaves the same in this case. SIGPIPE is suppressed in python by default therefore the error is generated instead of dying on SIGPIPE. If the signal is restored: import signal signal.signal(signal.SIGPIPE, signal.SIG_DFL) # restore SIGPIPE then the parent process dies on SIGPIPE (if input is larger than the OS pipe buffer of if the child process is already exited -- the same as for BrokenPipeError). The behaviour is the same ("Broken pipe" for large input) if syscalls are used directly instead of os.popen: #!/usr/bin/env python from sys import argv, exit from os import close, dup2, execlp, fork, pipe, wait, write n = int(argv[1]) if len(argv) > 1 else 100000000 n = (n // 2) * 2 # make it even assert n > 1 in_, out = pipe() if fork() == 0: # child close(out) # close unused write end of the pipe dup2(in_, 0) # redirect stdin to the pipe close(in_) execlp('/bin/grep', '/bin/grep', '--files-with-match', '0') else: # parent close(in_) # close unused read end of the pipe while n > 1: n -= write(out, b'0\n' * (n // 2)) # write input to the child close(out) # no more input exit(wait()[1]) # wait for the child to exit assert 0 If you meant something else; you could write more specific test. For reference: os.popen() in Python 2: http://hg.python.org/cpython/file/2.7/Modules/posixmodule.c#l4560 os.popen() in Python 3: http://hg.python.org/cpython/file/3.4/Lib/os.py#l928 ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 11:11:13 2014 From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=) Date: Sat, 03 May 2014 09:11:13 +0000 Subject: [issue21415] Python __new__ method doc typo (it's a class and not a static method) In-Reply-To: <1399026596.96.0.389694886975.issue21415@psf.upfronthosting.co.za> Message-ID: <1399108273.26.0.566337008237.issue21415@psf.upfronthosting.co.za> Jurko Gospodneti? added the comment: Thanks for the detailed response! :-( I should have tested more before reporting the issue. Sorry for the noise. :-( I saw the 'cls' argument and assumed it was a class method. Having to explicitly specify cls did not seem to be in contradiction with this since I assumed __new__ is generally invoked on the class directly. I still do not see why it had to be a static method and has not been implemented as a class method, but I guess I'll better ask that kind of a question on the python user's newsgroup. :-) Just in case it can help someone else, here's some sample code what convinced me __new__ was indeed implemented as a static method: > class X: > pass > X.__new__() # TypeError: object.__new__(): not enough arguments > X.__new__(X) # creates a new X instance > x = X() > x.__new__() # TypeError: object.__new__(): not enough arguments > x.__new__(X) # creates a new X instance If __new__ had been a class method then calling 'x.__new__()' would have worked as well. Thanks again for the replies! Best regards, Jurko Gospodneti? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 12:17:54 2014 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 03 May 2014 10:17:54 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n In-Reply-To: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> Message-ID: <1399112274.95.0.00736976831683.issue21420@psf.upfronthosting.co.za> Stefan Behnel added the comment: LGTM, can't see a case where this might go wrong (errors and type checks are handled before the added code). It also seems a sufficiently common case to optimise it internally. The 2**n spelling is easier to read and to get right than the shifting, so it's good to make both similarly fast to remove an excuse for micro optimisations in Python code. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 14:32:59 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 03 May 2014 12:32:59 +0000 Subject: [issue20544] Use specific asserts in operator tests In-Reply-To: <1399095526.78.0.0380932051047.issue20544@psf.upfronthosting.co.za> Message-ID: Andrew Svetlov added the comment: Ok. I agree with Teddy but Raymond's arguments make a value also. Thus we need to make any decision and close the issue (and bunch of similar issues). On Sat, May 3, 2014 at 8:38 AM, Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > The generic error message for the first is 'False is not true'. Clear but useless. The error message for the second is the more specific ' is not None'. Since the expression was supposed to evaluate to None, but did not, it would be helpful to me, at least, to know what it did evaluate to. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 14:34:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 03 May 2014 12:34:17 +0000 Subject: [issue21422] int << 0: return the number unmodified Message-ID: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> New submission from STINNER Victor: I propose to add a micro-optimization for int << 0: return the number unmodified. See attached patch. ---------- files: long_lshift0.patch keywords: patch messages: 217822 nosy: haypo, mark.dickinson, serhiy.storchaka priority: normal severity: normal status: open title: int << 0: return the number unmodified type: performance versions: Python 3.5 Added file: http://bugs.python.org/file35144/long_lshift0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 14:45:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 03 May 2014 12:45:15 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n In-Reply-To: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> Message-ID: <1399121115.72.0.5607102898.issue21420@psf.upfronthosting.co.za> STINNER Victor added the comment: pow2_specialized.patch: here is a different approach, a little bit faster. I wrote a dedicated long_pow2() function which computes 2**k. Arguments in favor of pow2_specialized.patch instead of pow2.patch: - it's a little bit faster - don't touch long_lshift(), so there is no risk of performance regression - it becomes easier to implement #21419 optimization: use calloc() instead of malloc() for very large power of 2, to avoid allocating physical memory pages for zeros Results of bench_pow2.py comparing original Python, pow2.pathc and pow2_specialized.patch: Common platform: Platform: Linux-3.13.9-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Python unicode implementation: PEP 393 Bits: int=32, long=64, long long=64, size_t=64, void*=64 Timer: time.perf_counter CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Platform of campaign orig: SCM: hg revision=62438d1b11c7 tag=tip branch=default date="2014-05-02 23:26 +0200" Date: 2014-05-03 14:42:56 Timer precision: 46 ns Python version: 3.5.0a0 (default:62438d1b11c7, May 3 2014, 14:41:50) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Platform of campaign pow2: SCM: hg revision=62438d1b11c7+ tag=tip branch=default date="2014-05-02 23:26 +0200" Python version: 3.5.0a0 (default:62438d1b11c7+, May 3 2014, 14:41:13) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Date: 2014-05-03 14:41:21 Timer precision: 51 ns Platform of campaign pow2_specialized: SCM: hg revision=62438d1b11c7+ tag=tip branch=default date="2014-05-02 23:26 +0200" Date: 2014-05-03 14:40:26 Python version: 3.5.0a0 (default:62438d1b11c7+, May 3 2014, 14:40:18) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] Timer precision: 46 ns ---------------+--------------------+--------------+----------------- Tests????????? | ??????????????orig | ????????pow2 | pow2_specialized ---------------+--------------------+--------------+----------------- 2 ** 0???????? | ?????????39 ns (*) | 44 ns (+11%) | ???????????41 ns 2 ** 1???????? | ????264 ns (+531%) | 62 ns (+48%) | ???????42 ns (*) 2 ** 3???????? | ????269 ns (+554%) | 62 ns (+50%) | ???????41 ns (*) 2 ** 5???????? | ????269 ns (+560%) | 62 ns (+51%) | ???????41 ns (*) 2 ** 10??????? | ????279 ns (+410%) | 63 ns (+15%) | ???????55 ns (*) 2 ** 15??????? | ????299 ns (+460%) | 62 ns (+16%) | ???????53 ns (*) 2 ** 20??????? | ????287 ns (+426%) | 62 ns (+14%) | ???????55 ns (*) 2 ** 25??????? | ????302 ns (+466%) | 62 ns (+16%) | ???????53 ns (*) 2 ** 28??????? | ????293 ns (+438%) | 62 ns (+14%) | ???????55 ns (*) 2 ** (2 ** 0)? | ????264 ns (+549%) | 62 ns (+52%) | ???????41 ns (*) 2 ** (2 ** 1)? | ????264 ns (+524%) | 62 ns (+48%) | ???????42 ns (*) 2 ** (2 ** 3)? | ????263 ns (+548%) | 62 ns (+52%) | ???????41 ns (*) 2 ** (2 ** 5)? | ????283 ns (+346%) | ?68 ns (+8%) | ???????63 ns (*) 2 ** (2 ** 10) | ????715 ns (+950%) | ???68 ns (*) | ???????????69 ns 2 ** (2 ** 15) | ?89.6 us (+51109%) | ??175 ns (*) | ??????????177 ns 2 ** (2 ** 20) | 3.89 ms (+100603%) | ?3.86 us (*) | ?????????3.86 us 2 ** (2 ** 25) | ??152 ms (+66557%) | 240 us (+5%) | ??????228 us (*) 2 ** (2 ** 28) | 1.35 sec (+33851%) | ?3.99 ms (*) | ?????????3.99 ms ---------------+--------------------+--------------+----------------- Total????????? | 1.51 sec (+35664%) | ?????4.23 ms | ?????4.22 ms (*) ---------------+--------------------+--------------+----------------- ---------- Added file: http://bugs.python.org/file35145/pow2_specialized.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 15:13:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 03 May 2014 13:13:59 +0000 Subject: [issue20866] segfailt with os.popen and SIGPIPE In-Reply-To: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za> Message-ID: <1399122839.53.0.417670449026.issue20866@psf.upfronthosting.co.za> STINNER Victor added the comment: I can reproduce the crash. It occurs at the line "fd.write(data)". It looks like the crash occurs in the C function fwrite() which doesn't handle EPIPE / SIGPIPE correctly. Top of the gdb traceback: #0 0x00000033d0a8968b in __mempcpy_sse2 () from /lib64/libc.so.6 #1 0x00000033d0a79339 in __GI__IO_default_xsputn () from /lib64/libc.so.6 #2 0x00000033d0a77362 in __GI__IO_file_xsputn () from /lib64/libc.so.6 #3 0x00000033d0a6cfad in fwrite () from /lib64/libc.so.6 #4 0x0000000000435cc4 in file_write (f=0x7f46d74a2dc0, args=('0123456789\n0123456789\n0123456789\n...(truncated)) at Objects/fileobject.c:1852 Last syscalls (strace output): ... pipe2([3, 4], O_CLOEXEC) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f5ce26aca10) = 4711 close(3) = 0 fcntl(4, F_SETFD, 0) = 0 fstat(4, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 fstat(4, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5ce26ca000 write(4, "0123456789\n0123456789\n0123456789"..., 1097728) = 98304 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=4710, si_uid=1000} --- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4711, si_status=0, si_utime=0, si_stime=0} --- write(4, "89\n0123456789\n0123456789\n0123456"..., 999424) = -1 EPIPE (Broken pipe) --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=4710, si_uid=1000} --- --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7f5cdbe87000} --- +++ killed by SIGSEGV (core dumped) +++ ---------- nosy: +haypo, neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 15:43:14 2014 From: report at bugs.python.org (Brett Cannon) Date: Sat, 03 May 2014 13:43:14 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1399124594.07.0.394807200353.issue14019@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 15:57:07 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 03 May 2014 13:57:07 +0000 Subject: [issue21352] improve documentation indexing In-Reply-To: <1398457661.12.0.679738685491.issue21352@psf.upfronthosting.co.za> Message-ID: <1399125427.28.0.196158188399.issue21352@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 18:49:48 2014 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Sat, 03 May 2014 16:49:48 +0000 Subject: [issue18564] Integer overflow in socketmodule In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za> Message-ID: <1399135788.22.0.832772511933.issue18564@psf.upfronthosting.co.za> Changes by Michele Orr? : Added file: http://bugs.python.org/file35146/issue18564.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 19:15:36 2014 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Sat, 03 May 2014 17:15:36 +0000 Subject: [issue18564] Integer overflow in socketmodule In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za> Message-ID: <1399137336.79.0.198058720033.issue18564@psf.upfronthosting.co.za> Michele Orr? added the comment: Interestingly, implements a function for parsing bluetooth addresses, but it's completely broken. It would be much much more elegant to use str2ba() in our source code though. I am thinking about patching it there and then open another ticket here in order to adopt str2ba(). This way we can close this ticket for now. Does this sound reasonable to you, Antoine? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 21:29:59 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 03 May 2014 19:29:59 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1399145399.39.0.348175601691.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: I did a post-commit review. A couple of things: 1) I think Victor and I have a different view of the calloc() parameters. calloc(size_t nmemb, size_t size) If a memory region of bytes is allocated, IMO 'nbytes' should be in the place of 'nmemb' and '1' should be in the place of 'size'. That is, "allocate nbytes elements of size 1": calloc(nbytes, 1) In the commit the parameters are reversed in many places, which confuses me quite a bit, since it means "allocate one element of size nbytes". calloc(1, nbytes) 2) I'm not happy with the refactoring in bytearray_init(). I think it would be safer to make focused minimal changes in PyByteArray_Resize() instead. In fact, there is a behavior change which isn't correct: Before: ======= >>> x = bytearray(0) >>> m = memoryview(x) >>> x.__init__(10) Traceback (most recent call last): File "", line 1, in BufferError: Existing exports of data: object cannot be re-sized Now: ==== >>> x = bytearray(0) >>> m = memoryview(x) >>> x.__init__(10) >>> x[0] 0 >>> m[0] Traceback (most recent call last): File "", line 1, in IndexError: index out of bounds 3) Somewhat similarly, I wonder if it was necessary to refactor PyBytes_FromStringAndSize(). I find the new version more difficult to understand. 4) _PyObject_Alloc(): assert(nelem <= PY_SSIZE_T_MAX / elsize) can be called with elsize = 0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 21:34:59 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 03 May 2014 19:34:59 +0000 Subject: [issue20866] segfailt with os.popen and SIGPIPE In-Reply-To: <1399122839.53.0.417670449026.issue20866@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I can reproduce the crash. It occurs at the line "fd.write(data)". It looks like the crash occurs in the C function fwrite() which doesn't handle EPIPE / SIGPIPE correctly. Wouldn't be the first time. Note that in Python 3, we don't fopen/fwrite anymore, so Python 3 isn't affected. I suggest closing as "won't fix". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 22:26:16 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 03 May 2014 20:26:16 +0000 Subject: [issue20866] segfailt with os.popen and SIGPIPE In-Reply-To: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za> Message-ID: <1399148776.53.0.387273048336.issue20866@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I was thinking the same thing. This appears to be one of the 2.x bugs that have been fixed in 3.x but not 2.x because backporting the fix might break working code. If there another sensible fix that would be acceptable in 2.x? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 23:39:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 03 May 2014 21:39:14 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1399153154.71.0.941375585841.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: I forgot one thing: 5) If WITH_VALGRIND is defined, nbytes is uninitialized in _PyObject_Alloc(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 23:40:49 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 03 May 2014 21:40:49 +0000 Subject: [issue20866] segfailt with os.popen and SIGPIPE In-Reply-To: <1399148776.53.0.387273048336.issue20866@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: It's segfaulting inside fwrite(), so apart from completely rewriting the IO layer in 2.x, I don't see. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 3 23:57:18 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 03 May 2014 21:57:18 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1399154238.42.0.602663329801.issue21233@psf.upfronthosting.co.za> Stefan Krah added the comment: Another thing: 6) We need some kind of prominent documentation that existing programs need to be changed: Python 3.5.0a0 (default:62438d1b11c7+, May 3 2014, 23:35:03) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import failmalloc >>> failmalloc.enable() >>> bytes(1) Segmentation fault (core dumped) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:01:03 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 03 May 2014 22:01:03 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <1399154463.79.0.511645678309.issue21233@psf.upfronthosting.co.za> Nathaniel Smith added the comment: A simple solution would be to change the name of the struct, so that non-updated libraries will get a compile error instead of a runtime crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:02:09 2014 From: report at bugs.python.org (=?utf-8?q?Andreas_R=C3=B8sdal?=) Date: Sat, 03 May 2014 22:02:09 +0000 Subject: [issue20215] Python2.7 socketserver can not listen IPv6 address In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za> Message-ID: <1399154529.14.0.00586881555318.issue20215@psf.upfronthosting.co.za> Andreas R?sdal added the comment: Here's a patch which implements support in SocketServer to set IPv6 socket address family to AF_INET6 automatically if the TCPServer is specified to listen to an IPv6 address. This means that users of the TCPServer class will get the correct address family automatically for both IPv4 and IPv6 based on the IP address they specify, and hopefully this will be more userfriendly. The patch is against the latest Python 3.5. Note that this is my first patch to the Python project, I hope I did everything correct. ---------- keywords: +patch nosy: +andreasr Added file: http://bugs.python.org/file35147/issue20215_socketserver.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:15:59 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 03 May 2014 22:15:59 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399155359.71.0.292905309603.issue21422@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Every branch has a cost (in particular, it tends to contaminate global branch prediction tables and blow other code out of the L1 code cache). The cost isn't big, but branches shouldn't be added unless we know there is a real benefit. I would think that in real-world code, this branch will almost never be taken. The common case will pay a price (albiet a small one) for almost zero benefit. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:26:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 03 May 2014 22:26:31 +0000 Subject: [issue21375] Fix and test overflow behavior in the C version of heapq In-Reply-To: <1398707994.45.0.696035798055.issue21375@psf.upfronthosting.co.za> Message-ID: <3gLlKy3QQfz7Ljr@mail.python.org> Roundup Robot added the comment: New changeset 725cb631699a by Raymond Hettinger in branch '3.4': Issue 21375: Fix possible Py_ssizet overflow in heapq. http://hg.python.org/cpython/rev/725cb631699a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:30:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 03 May 2014 22:30:17 +0000 Subject: [issue21375] Fix and test overflow behavior in the C version of heapq In-Reply-To: <1398707994.45.0.696035798055.issue21375@psf.upfronthosting.co.za> Message-ID: <3gLlQK0LRGz7LlK@mail.python.org> Roundup Robot added the comment: New changeset b768d41dec0a by Raymond Hettinger in branch '2.7': Issue 21375: Fix possible Py_ssizet overflow in heapq. http://hg.python.org/cpython/rev/b768d41dec0a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:41:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 03 May 2014 22:41:29 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399155359.71.0.292905309603.issue21422@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > I would think that in real-world code, this branch will almost never be taken. The common case will pay a price (albiet a small one) for almost zero benefit. I think that x << 0 is common even if it's not written like that (it's more for i in range(8): ... x << i). The benefit is to reduce the memory footprint. Can you sow the overhead of the branch in a microbenchmark? The test is only done once, it's out of a loop. *If* it's possible to notice an overhead, we can maybe use GCC macro unlikely(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:45:52 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 03 May 2014 22:45:52 +0000 Subject: [issue21375] Fix and test overflow behavior in the C version of heapq In-Reply-To: <1398707994.45.0.696035798055.issue21375@psf.upfronthosting.co.za> Message-ID: <1399157152.22.0.562733234498.issue21375@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:49:18 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 03 May 2014 22:49:18 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1399154238.42.0.602663329801.issue21233@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > 6) We need some kind of prominent documentation that existing > programs need to be changed: My final commit includes an addition to What's New in Python 3.5 doc, including a notice in the porting section. It is not enough? Even if the API is public, the PyMemAllocator thing is low level. It's not part of the stable ABI. Except failmalloc, I don't know any user. I don't expect a lot of complain and it's easy to port the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:51:32 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 03 May 2014 22:51:32 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1399153154.71.0.941375585841.issue21233@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > 5) If WITH_VALGRIND is defined, nbytes is uninitialized in _PyObject_Alloc(). Did you see my second commit? It's nlt already fixed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 00:59:28 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 03 May 2014 22:59:28 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: <20140503225927.GA11524@sleipnir.bytereef.org> Stefan Krah added the comment: > > 5) If WITH_VALGRIND is defined, nbytes is uninitialized in > _PyObject_Alloc(). > > Did you see my second commit? It's nlt already fixed? I don't think so, I have revision 5d076506b3f5 here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 01:00:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 03 May 2014 23:00:51 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1399145399.39.0.348175601691.issue21233@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > "allocate nbytes elements of size 1" PyObject_Malloc(100) asks to allocate one object of 100 bytes. For PyMem_Malloc() and PyMem_RawMalloc(), it's more difficult to guess, but IMO it's sane to bet that a single memory block of size bytes is requested. I consider that char data[100] is a object of 100 bytes, but you call it 100 object of 1 byte. I don't think that using nelem or elsize matters in practice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 01:09:20 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 03 May 2014 23:09:20 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399158560.9.0.780911708534.issue21121@psf.upfronthosting.co.za> Ned Deily added the comment: I agree: issue21121-3.diff is a much better approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 01:17:55 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 03 May 2014 23:17:55 +0000 Subject: [issue17338] Add length_hint parameter to list, dict, set constructors to allow efficient presizing In-Reply-To: <1362245019.42.0.972918137955.issue17338@psf.upfronthosting.co.za> Message-ID: <1399159075.04.0.0919597359957.issue17338@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Based on all the negative comments, I'm closing this one. It adds too much complication in return for dubious value. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 01:25:44 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 03 May 2014 23:25:44 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: <20140503232543.GA11650@sleipnir.bytereef.org> Stefan Krah added the comment: STINNER Victor wrote: > PyObject_Malloc(100) asks to allocate one object of 100 bytes. Okay, then let's please call it: _PyObject_Calloc(void *ctx, size_t nobjs, size_t objsize) _PyObject_Alloc(int use_calloc, void *ctx, size_t nobjs, size_t objsize) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 01:32:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 03 May 2014 23:32:20 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <3gLmnv4LGDz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset 39f475aa0163 by Raymond Hettinger in branch 'default': Issue 21101: Internal API for dict getitem and setitem where the hash value is known. http://hg.python.org/cpython/rev/39f475aa0163 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 01:38:08 2014 From: report at bugs.python.org (Andreas van Cranenburgh) Date: Sat, 03 May 2014 23:38:08 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument Message-ID: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> New submission from Andreas van Cranenburgh: It would be useful if concurrent.futures.ThreadPoolExecutor took an initializer argument, like multiprocessing.Pool. This is useful for example to load a large dataset once upon initialization of each worker process, without have to pass the dataset as an argument with every job submission, which requires serialization. concurrent.futures has some advantages over multiprocessing such as detecting killed processes ( http://bugs.python.org/issue9205 ), so it would be good if the advantages of both can be combined. It appears that the following fork of concurrent.futures has added these arguments: https://github.com/enthought/encore/blob/7101984bc384da8e7975876ca2809cc0103c3efc/encore/concurrent/futures/enhanced_thread_pool_executor.py ---------- components: Library (Lib) messages: 217846 nosy: andreasvc priority: normal severity: normal status: open title: concurrent.futures.ThreadPoolExecutor should accept an initializer argument versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 01:40:56 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 03 May 2014 23:40:56 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399160456.49.0.0549791020454.issue21121@psf.upfronthosting.co.za> Larry Hastings added the comment: If you guys want this in 3.4.1, please get it checked in in the next, oh, eight hours. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 01:41:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 03 May 2014 23:41:26 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <3gLn0P6GSLz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset 592a57682ced by Raymond Hettinger in branch 'default': Issue #21101: Eliminate double hashing in the C code for collections.Counter(). http://hg.python.org/cpython/rev/592a57682ced ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 01:42:02 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 03 May 2014 23:42:02 +0000 Subject: [issue21101] Extend the PyDict C API to handle cases where the hash value is known In-Reply-To: <1396169909.67.0.904843670128.issue21101@psf.upfronthosting.co.za> Message-ID: <1399160522.19.0.185692578944.issue21101@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 02:19:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 May 2014 00:19:05 +0000 Subject: [issue21357] Increase filecmp test coverage from 63% to 76% In-Reply-To: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za> Message-ID: <3gLnqp4T4nz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset 57dacba9febf by Benjamin Peterson in branch '3.4': improve test coverage of filecmp (closes #21357) http://hg.python.org/cpython/rev/57dacba9febf New changeset c597654a7fd8 by Benjamin Peterson in branch 'default': merge 3.4 (#21357) http://hg.python.org/cpython/rev/c597654a7fd8 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 02:22:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 May 2014 00:22:40 +0000 Subject: [issue20642] Enhance deepcopy-ing for tuples In-Reply-To: <1392587167.09.0.0900280350163.issue20642@psf.upfronthosting.co.za> Message-ID: <3gLnvw4M3Fz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset 0df3004581fe by Benjamin Peterson in branch 'default': improve idioms (closes #20642) http://hg.python.org/cpython/rev/0df3004581fe ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 02:38:47 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 May 2014 00:38:47 +0000 Subject: [issue20642] Enhance deepcopy-ing for tuples In-Reply-To: <1392587167.09.0.0900280350163.issue20642@psf.upfronthosting.co.za> Message-ID: <1399163927.87.0.752633631547.issue20642@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This was a nice patch. Thanks. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 04:06:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 May 2014 02:06:40 +0000 Subject: [issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__ In-Reply-To: <1399075361.96.0.75684702655.issue21421@psf.upfronthosting.co.za> Message-ID: <3gLrCz0gXKz7Lkx@mail.python.org> Roundup Robot added the comment: New changeset 2c6a231e2c1e by Raymond Hettinger in branch 'default': Issue #21421: Add __slots__ to the MappingViews ABCs. http://hg.python.org/cpython/rev/2c6a231e2c1e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 04:09:57 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 May 2014 02:09:57 +0000 Subject: [issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__ In-Reply-To: <1399075361.96.0.75684702655.issue21421@psf.upfronthosting.co.za> Message-ID: <1399169397.05.0.327380207034.issue21421@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I've applied the __slots__ patch. Thank you for submitting it. Am leaving the rest of the ABCs code as-is. The current form may be a bit wordy but it is clean, fast, and easy to trace through a debugger. The expanded forms were chosen for a reason. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 04:13:34 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 May 2014 02:13:34 +0000 Subject: [issue21414] Add an intersperse function to itertools In-Reply-To: <1399016381.86.0.358283967216.issue21414@psf.upfronthosting.co.za> Message-ID: <1399169614.4.0.844551611732.issue21414@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I've looked into this a bit more. Even in Haskell, it seems that use case is for str.join() which we already have. I don't see intersperse() in any other functional languages. That suggests that its use cases aren't sufficiently common to warrant adding it to the standard library. Thank you for the submission. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 04:25:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 May 2014 02:25:58 +0000 Subject: [issue18604] Consolidate gui available checks in test.support In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za> Message-ID: <3gLrfF311Kz7Lkx@mail.python.org> Roundup Robot added the comment: New changeset 7ecb6e4b1077 by Ned Deily in branch '3.4': Issue #18604: Skip the Tk instantiation test on OS X because it can http://hg.python.org/cpython/rev/7ecb6e4b1077 New changeset 7f6d9990a9b1 by Ned Deily in branch 'default': Issue #18604: merge from 3.4 http://hg.python.org/cpython/rev/7f6d9990a9b1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 04:35:35 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 02:35:35 +0000 Subject: [issue18604] Consolidate gui available checks in test.support In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za> Message-ID: <1399170935.03.0.392931364558.issue18604@psf.upfronthosting.co.za> Ned Deily added the comment: For some reason, the newly-added Tk instantiation check causes the OS X Cocoa Tk to segfault when tests are run under regrtest -jn option, which causes each test to be run under a separate subprocess called from a separate thread. Somewhat surprisingly, the segfault doesn't seem to happen under the same conditions with 2.7, only with 3.4 and default, so there is something more at play here. But with the imminent tagging of 3.4.1rc1, I think it is better to disable the check for 3.4 (and default) on OS X pending further investigation. The check is redundant: if Tk doesn't work for some reason, the individual test should fail anyway, just a bit later. ---------- nosy: +ned.deily status: closed -> open versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 06:58:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 May 2014 04:58:55 +0000 Subject: [issue19414] iter(ordered_dict) yields keys not in dict in some circumstances In-Reply-To: <1382844474.66.0.775956254592.issue19414@psf.upfronthosting.co.za> Message-ID: <3gLw2k15xpz7Ljr@mail.python.org> Roundup Robot added the comment: New changeset a3c345ba3563 by Raymond Hettinger in branch 'default': Issue #19414: Have the OrderedDict mark deleted links as unusable. http://hg.python.org/cpython/rev/a3c345ba3563 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 07:05:02 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 May 2014 05:05:02 +0000 Subject: [issue19414] iter(ordered_dict) yields keys not in dict in some circumstances In-Reply-To: <1382844474.66.0.775956254592.issue19414@psf.upfronthosting.co.za> Message-ID: <1399179902.96.0.492079459599.issue19414@psf.upfronthosting.co.za> Raymond Hettinger added the comment: To address Armin's concern, I'm triggering an early failure by setting the link fields to None. That will help prevent accidental reliance on non-guaranteed behaviors. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 07:57:10 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 May 2014 05:57:10 +0000 Subject: [issue21424] Simplify and speed-up heaqp.nlargest() Message-ID: <1399183029.85.0.254812547035.issue21424@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Consolidate the logic for nlargest() into a single function. Remove both the C and pure Python base underlying code. With all the logic in a single function, it only becomes necessary to create, store, and compare the data tuples when a need item is added to the heap. This means that the rest of the comparisons (checking to see whether a new item needs to be added to the heap) can run faster and not need to create a (key, order, elem) tuple. The change reduces the number of tuples created and the number of ordering integers created. When rich comparisons were introduced, tuple ordering comparisons became twice as expensive (they are compared elementwise for equality and then there is an additional comparison call to order the first differing element). Under the existing nlargest() code, we pay that price for every lement in the iterable. In the new code, we pay that price only for the small subset of the iterable that actually gets added to the heap. After this, another patch for simplifying nsmallest() is forthcoming. ---------- components: Library (Lib) files: rid_nlargest.py messages: 217859 nosy: rhettinger priority: low severity: normal status: open title: Simplify and speed-up heaqp.nlargest() type: performance versions: Python 3.5 Added file: http://bugs.python.org/file35148/rid_nlargest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 09:42:40 2014 From: report at bugs.python.org (Jiong Du) Date: Sun, 04 May 2014 07:42:40 +0000 Subject: [issue19576] "Non-Python created threads" documentation doesn't mention PyEval_InitThreads() In-Reply-To: <1384379370.85.0.232061958171.issue19576@psf.upfronthosting.co.za> Message-ID: <1399189360.47.0.535298248584.issue19576@psf.upfronthosting.co.za> Jiong Du added the comment: this patch made a new issue<20891> ---------- nosy: +lolynx _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 10:28:40 2014 From: report at bugs.python.org (=?utf-8?q?M=C3=A1rton_Marczell?=) Date: Sun, 04 May 2014 08:28:40 +0000 Subject: [issue21425] Python 3 pipe handling breaks python mode in emacs on Windows Message-ID: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> New submission from M?rton Marczell: When I run a Python 3.3.4 prompt inside Emacs 24.3 on Windows 7, correct commands are evaluated immediately, but incorrect ones are delayed (I have to press Enter one more time), as seen below: >>> 1 1 >>> nonsense >>> Traceback (most recent call last): File "", line 1, in NameError: name 'nonsense' is not defined Python 2 does not do this. I've filed an Emacs bug report (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17304) and got the response to try this on the command line (where cat.exe is from an MSYS installation): python 2>&1 | cat.exe and it behaves the same way as in Emacs. ---------- components: Windows messages: 217861 nosy: marczellm priority: normal severity: normal status: open title: Python 3 pipe handling breaks python mode in emacs on Windows type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 11:27:50 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 04 May 2014 09:27:50 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399195670.41.0.0799443349512.issue21422@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Can you sow the overhead of the branch in a microbenchmark? Conversely, can you show a case where this optimisation provides a benefit in real code? We should be looking for a reason *to* apply the patch, not a reason *not* to apply the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 11:34:29 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 04 May 2014 09:34:29 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n In-Reply-To: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> Message-ID: <1399196069.29.0.0536756628818.issue21420@psf.upfronthosting.co.za> Mark Dickinson added the comment: Victor, can you demonstrate any cases of real code where this optimization makes a significant difference? There are many, many tiny optimisations we *could* be making in Objects/longobject.c; each of those potential optimisations adds to the cost of maintaining the code, detracts from readability, and potentially even slows down the common cases fractionally. In general, I think we should only be applying this sort of optimization when there's a clear benefit to real-world code. I don't think this one crosses that line. In the (I suspect rare) cases where a piece of real-world code is slowed down significantly due to a non-optimized 2**n, the code author still has the option of replacing that piece of code with 1< _______________________________________ From report at bugs.python.org Sun May 4 11:58:20 2014 From: report at bugs.python.org (Roman Inflianskas) Date: Sun, 04 May 2014 09:58:20 +0000 Subject: [issue21405] Allow using symbols from Unicode block "Superscripts and Subscripts" in identifiers In-Reply-To: <1398926695.28.0.870869900387.issue21405@psf.upfronthosting.co.za> Message-ID: <1399197500.97.0.358893427326.issue21405@psf.upfronthosting.co.za> Roman Inflianskas added the comment: See later discussion there: https://mail.python.org/pipermail/python-ideas/2014-May/027767.html Because of https://mail.python.org/pipermail/python-ideas/2014-May/027789.html I'm closing this issue. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 12:37:55 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 04 May 2014 10:37:55 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1399160456.49.0.0549791020454.issue21121@psf.upfronthosting.co.za> Message-ID: <20140504103754.GA16200@sleipnir.bytereef.org> Stefan Krah added the comment: > If you guys want this in 3.4.1, please get it checked in in the next, oh, eight hours. I can't commit today. Perhaps one of you wants to take over (I think we all agree that the third patch is the best). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 13:12:04 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 04 May 2014 11:12:04 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: Message-ID: <20140504111203.GA16483@sleipnir.bytereef.org> Stefan Krah added the comment: STINNER Victor wrote: > My final commit includes an addition to What's New in Python 3.5 doc, > including a notice in the porting section. It is not enough? I'm not sure: The usual case with ABI changes is that extensions may segfault if they are *not* recompiled [1]. In that case documenting it in What's New is standard procedure. Here the extension *is* recompiled and still segfaults. > Even if the API is public, the PyMemAllocator thing is low level. It's not > part of the stable ABI. Except failmalloc, I don't know any user. I don't > expect a lot of complain and it's easy to port the code. Perhaps it's worth asking on python-dev. Nathaniel's suggestion isn't bad either (e.g. name it PyMemAllocatorEx). [1] I was told on python-dev that many people in fact do not recompile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 13:41:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 May 2014 11:41:31 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <3gM4zG4hqMz7LmD@mail.python.org> Roundup Robot added the comment: New changeset 4f26430b03fd by Larry Hastings in branch '3.4': Issue #21088: Bugfix for curses.window.addch() regression in 3.4.0. http://hg.python.org/cpython/rev/4f26430b03fd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 13:48:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 May 2014 11:48:28 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <3gM57H4RXtz7LkK@mail.python.org> Roundup Robot added the comment: New changeset 3aa5fae8c313 by Larry Hastings in branch 'default': Issue #21088: Merge from 3.4. http://hg.python.org/cpython/rev/3aa5fae8c313 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 13:48:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 04 May 2014 11:48:50 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <1399204130.59.0.321837355303.issue21088@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- assignee: -> larry resolution: -> fixed stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 13:52:33 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 04 May 2014 11:52:33 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399204353.06.0.979085783942.issue21121@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry, I should have said "3.4.1rc1". You can still get it in for 3.4.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 14:34:32 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 04 May 2014 12:34:32 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399206872.82.0.190566335799.issue21121@psf.upfronthosting.co.za> Ronald Oussoren added the comment: This is the same issue as Issue18211. As that issue doesn't have a patch and this one does, I'm closing Issue18211 as a duplicate. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 14:40:21 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 04 May 2014 12:40:21 +0000 Subject: [issue18211] -Werror=statement-after-declaration problem In-Reply-To: <1371210635.81.0.102822533543.issue18211@psf.upfronthosting.co.za> Message-ID: <1399207221.79.0.68944793557.issue18211@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Closing this one because Issue21121 contains a usable patch. ---------- resolution: -> duplicate superseder: -> -Werror=declaration-after-statement is added even for extension modules through setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 14:41:04 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 04 May 2014 12:41:04 +0000 Subject: [issue18211] -Werror=statement-after-declaration problem In-Reply-To: <1371210635.81.0.102822533543.issue18211@psf.upfronthosting.co.za> Message-ID: <1399207264.9.0.47629094207.issue18211@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Sigh. Actually closing doesn't work due to the dependency :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 15:34:12 2014 From: report at bugs.python.org (Milan Oberkirch) Date: Sun, 04 May 2014 13:34:12 +0000 Subject: [issue21426] Invisible characters in email related souce files. Message-ID: <1399210450.89.0.0298298862351.issue21426@psf.upfronthosting.co.za> New submission from Milan Oberkirch: I found non-printable characters in the source files of the email package. Vim rendered it as '^L', pasting it on the linux console has the same effect as CTRL+L. In most places it was combined with regular newlines, sometimes as a replacement, sometimes additionally to them. My guess is that these files were saved with an editor replacing '\n' with '\r' and additional '\n' were inserted afterwards since the linebreaks seemed to be gone. I replaced these chars by '\n' or '' in the attached patch. ---------- components: email files: linebreak.patch keywords: patch messages: 217874 nosy: barry, r.david.murray, zvyn priority: normal severity: normal status: open title: Invisible characters in email related souce files. versions: Python 3.5 Added file: http://bugs.python.org/file35149/linebreak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 15:39:00 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 04 May 2014 13:39:00 +0000 Subject: [issue21426] Invisible characters in email related souce files. In-Reply-To: <1399210450.89.0.0298298862351.issue21426@psf.upfronthosting.co.za> Message-ID: <1399210740.43.0.597883647404.issue21426@psf.upfronthosting.co.za> Benjamin Peterson added the comment: They are page markers to assist in file nagivation. https://www.gnu.org/software/emacs/manual/html_node/emacs/Pages.html ---------- nosy: +benjamin.peterson resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 16:44:38 2014 From: report at bugs.python.org (diana) Date: Sun, 04 May 2014 14:44:38 +0000 Subject: [issue21357] Increase filecmp test coverage from 63% to 76% In-Reply-To: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za> Message-ID: <1399214678.87.0.197647114236.issue21357@psf.upfronthosting.co.za> diana added the comment: Thanks Benjamin! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 17:01:48 2014 From: report at bugs.python.org (Eric Olson) Date: Sun, 04 May 2014 15:01:48 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1399215708.28.0.139988130844.issue2159@psf.upfronthosting.co.za> Eric Olson added the comment: Hi, Thanks for finding those issues. I attached a new patch. a) Good find, I added the free() for gdbm. ndbm doesn't need free(). b) Added the error check. I don't know if a test can be made for this. If there was a common way to patch C libraries in CPython, I would give that a try. Also, do you know if we should check for the gdbm error before the dbm error, or does it not matter? c) Yes, it looks like NULL is used here instead of 0. Changed 0s to NULLS. Let me know if you see anything else. ---------- Added file: http://bugs.python.org/file35150/dbm_bool_e.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 17:38:46 2014 From: report at bugs.python.org (Uwe) Date: Sun, 04 May 2014 15:38:46 +0000 Subject: [issue21427] installer not working Message-ID: <1399217925.98.0.594848268677.issue21427@psf.upfronthosting.co.za> New submission from Uwe: Installer fails to install 3.4 on win7 32 bit Error: cannot register 64 bit component {BE22BD81-ECE5-45BD-83B8-84BA45846A2D} on 32 bit system. KeyPath: C:\Windows\py.exe ---------- messages: 217878 nosy: ellipso priority: normal severity: normal status: open title: installer not working type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 18:20:00 2014 From: report at bugs.python.org (Chappuis) Date: Sun, 04 May 2014 16:20:00 +0000 Subject: [issue21428] Python suddenly cares about EOLs formats on windows Message-ID: <1399220400.65.0.0106414482581.issue21428@psf.upfronthosting.co.za> New submission from Chappuis: When trying to execute the Software build program waf (http://ftp.waf.io/pub/release/waf-1.7.16) with the command python waf-1.7.16 --version, this unzip a folder in the current directory while reporting the version of the program on the standard input. Waf is distributed as a single file with unix end-of-lines. Executing the program with python 2.7 to 3.3 does not cause any problem, but executing with python-3.4.0 make the execution stop. I patched waf to solve the problem which is purely related to unix/dos end-of-lines. The behaviour of python-3.4.0 seems to have change regarding these EOL characters compared to the previous releases. Is that intentional? Kind regards Thierry ---------- components: Windows messages: 217879 nosy: pygnol priority: normal severity: normal status: open title: Python suddenly cares about EOLs formats on windows type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 18:24:51 2014 From: report at bugs.python.org (Mikaela Suomalainen) Date: Sun, 04 May 2014 16:24:51 +0000 Subject: [issue21429] Input.output error with multiprocessing Message-ID: <1399220691.1.0.523621963732.issue21429@psf.upfronthosting.co.za> New submission from Mikaela Suomalainen: I encountered this error with Limnoria and I was told to report it here. ``` ERROR 2014-05-04T18:04:04 supybot Uncaught exception in ['title']. Traceback (most recent call last): File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/callbacks.py", line 1266, in _callCommand self.callCommand(command, irc, msg, *args, **kwargs) File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/utils/python.py", line 91, in g f(self, *args, **kwargs) File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/callbacks.py", line 1247, in callCommand method(irc, msg, *args, **kwargs) File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/commands.py", line 1076, in newf f(self, irc, msg, args, *state.args, **state.kwargs) File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/plugins/Web/plugin.py", line 109, in newf f(self, irc, *args, **kwargs) File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/plugins/Web/plugin.py", line 96, in newf pn=self.name(), cn=f.__name__) File "/home/users/mkaysi/.local/lib/python3.4/site-packages/supybot/commands.py", line 120, in process p.start() File "/home/users/mkaysi/.pyenv/versions/3.4.0/lib/python3.4/multiprocessing/process.py", line 105, in start self._popen = self._Popen(self) File "/home/users/mkaysi/.pyenv/versions/3.4.0/lib/python3.4/multiprocessing/context.py", line 212, in _Popen return _default_context.get_context().Process._Popen(process_obj) File "/home/users/mkaysi/.pyenv/versions/3.4.0/lib/python3.4/multiprocessing/context.py", line 267, in _Popen return Popen(process_obj) File "/home/users/mkaysi/.pyenv/versions/3.4.0/lib/python3.4/multiprocessing/popen_fork.py", line 18, in __init__ sys.stdout.flush() OSError: [Errno 5] Input/output error ERROR 2014-05-04T18:04:04 supybot Exception id: 0xaaefe ``` ---------- components: Library (Lib) messages: 217880 nosy: mikaela priority: normal severity: normal status: open title: Input.output error with multiprocessing versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 20:01:57 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 04 May 2014 18:01:57 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399226517.43.0.499493231931.issue21121@psf.upfronthosting.co.za> ?ric Araujo added the comment: I can commit the patch but won?t be able to check the buildbots for the next twelve hours. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 20:06:33 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 18:06:33 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399226793.91.0.594854159834.issue21121@psf.upfronthosting.co.za> Ned Deily added the comment: There's no immediate rush now. It's too late for 3.4.1rc1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 20:08:47 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 04 May 2014 18:08:47 +0000 Subject: [issue18211] -Werror=statement-after-declaration problem In-Reply-To: <1371210635.81.0.102822533543.issue18211@psf.upfronthosting.co.za> Message-ID: <1399226927.72.0.621450060678.issue18211@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- dependencies: -CPython setup.py problems stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 20:35:56 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 04 May 2014 18:35:56 +0000 Subject: [issue18255] CPython setup.py problems In-Reply-To: <1371561186.46.0.280107378589.issue18255@psf.upfronthosting.co.za> Message-ID: <1399228556.68.0.224358138041.issue18255@psf.upfronthosting.co.za> ?ric Araujo added the comment: Note that the distutils feature freeze has been lifted, so in 3.5 sysconfig could be reused by distutils.sysconfig, but the existing functionality (different API + ability to override with env vars) must be preserved. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 21:05:46 2014 From: report at bugs.python.org (Bas Wijnen) Date: Sun, 04 May 2014 19:05:46 +0000 Subject: [issue21430] Document ssl.pending() Message-ID: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> New submission from Bas Wijnen: In order to use ssl sockets asynchronously, it is important to use the pending() method, otherwise the internal buffer will be ignored, and select may block for new data while it's already waiting. See bug #16976 and http://stackoverflow.com/questions/21663705/how-to-use-select-with-python-ssl-socket-buffering Using pending() works fine, but is entirely undocumented. https://docs.python.org/2.7/library/ssl.html (and all other versions) don't even mention the existence of the method. I hope this can be changed; using an undocumented feature isn't nice, but in this case there is no other good solution. ---------- assignee: docs at python components: Documentation messages: 217884 nosy: docs at python, shevek priority: normal severity: normal status: open title: Document ssl.pending() versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 21:35:48 2014 From: report at bugs.python.org (Christian Clauss) Date: Sun, 04 May 2014 19:35:48 +0000 Subject: [issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX In-Reply-To: <1265236812.59.0.190434450591.issue7850@psf.upfronthosting.co.za> Message-ID: <1399232148.94.0.593891117238.issue7850@psf.upfronthosting.co.za> Christian Clauss added the comment: assert sys.platform == platform.system().lower() Should that always be True? It is on Mac OS X but... On iOS (Pythonista): sys.platform ==> 'unknown' platform.system() ==> 'Darwin' https://docs.python.org/2/library/sys.html#sys.platform should be updated to provide the correct values for iOS and Android devices which now outnumber many of the other OSes listed. ---------- nosy: +Christian.Clauss _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 22:03:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 04 May 2014 20:03:28 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399195670.41.0.0799443349512.issue21422@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: The reason to apply the patch is to reduce the memory footprint. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 22:10:51 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 20:10:51 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" Message-ID: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> New submission from Ned Deily: Something went wrong with the update of pydoc_data topics for 3.4.1rc1. As can be seen in http://hg.python.org/releasing/3.4.1/rev/c67a19e11a71, the values for the topics dict should be strings but were updated as bytes. This causes pydoc topics searches to fail. The process problem needs to be fixed for 3.4.1 final. An example: $ /usr/local/bin/pydoc3.4 def Traceback (most recent call last): File "/usr/local/bin/pydoc3.4", line 5, in pydoc.cli() File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pydoc.py", line 2580, in cli help.help(arg) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pydoc.py", line 1860, in help elif request in self.keywords: self.showtopic(request) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pydoc.py", line 1941, in showtopic pager(doc.strip() + '\n') TypeError: can't concat bytes to str ---------- assignee: larry components: Build messages: 217887 nosy: georg.brandl, larry, ned.deily priority: release blocker severity: normal status: open title: 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 22:15:39 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 04 May 2014 20:15:39 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399234539.6.0.355051899004.issue21121@psf.upfronthosting.co.za> Stefan Krah added the comment: One more question: I think it's nicer to add CFLAGS_NODIST to 'renamed_variables' in Lib/sysconfig.py:265: renamed_variables = ('CFLAGS', 'CFLAGS_NODIST', 'LDFLAGS', 'CPPFLAGS') That way it's possible to look up CFLAGS_NODIST directly. For consistency, we can do the same for Lib/distutils/sysconfig.py, where the variable would be purely informational. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 22:30:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 04 May 2014 20:30:40 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1399235440.58.0.664596263354.issue21431@psf.upfronthosting.co.za> Larry Hastings added the comment: 3.4.1rc1 is the first release I've cut where the makefile didn't auto-download Sphinx. And then the makefile used "python" and "sphinx-build" straight off the path, rather than finding the local ones. To generate pydoc-topics, I had to do the following: % ./configure --prefix=`pwd`/release && make % ./release/bin/pip install sphinx % cd Doc % make pydoc-topics PYTHON=../release/bin/python SPHINXBUILD=../release/bin/sphinx-build And apparently this didn't work. Maybe there should be a "smoke test" to make sure pydoc-topics is okay? And... maybe "make pydoc-topics" should copy the data file itself, rather than making me cut and paste paths out of PEP 101? And *then* automatically test it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 22:33:44 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 20:33:44 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1399235624.67.0.91493319479.issue21431@psf.upfronthosting.co.za> Ned Deily added the comment: >From a first quick look, it appears that the problem occurs when using a Python 3 version of sphinx-build. With Python 2, the topics appear to be generated correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 22:45:42 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 20:45:42 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399236342.58.0.0812186836399.issue21121@psf.upfronthosting.co.za> Ned Deily added the comment: Is there any reason to expose CFLAGS_NODIST externally? It seems to me that it is only needed in the top-level setup.py for building standard library extension modules. Let's not add yet another configuration variable to the already confusing array we present to users through the two sysconfig.get_config_var(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 22:56:24 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 20:56:24 +0000 Subject: [issue21427] installer not working In-Reply-To: <1399217925.98.0.594848268677.issue21427@psf.upfronthosting.co.za> Message-ID: <1399236984.95.0.522849606812.issue21427@psf.upfronthosting.co.za> Ned Deily added the comment: Did you try using the 32-bit (x86) installer from https://www.python.org/downloads/release/python-340/ ? Unfortunately, I believe the default download button currently only downloads the 64-bit version. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 22:57:46 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 20:57:46 +0000 Subject: [issue21429] Input.output error with multiprocessing In-Reply-To: <1399220691.1.0.523621963732.issue21429@psf.upfronthosting.co.za> Message-ID: <1399237066.29.0.762632956826.issue21429@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 23:00:17 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 21:00:17 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1399237217.2.0.99689319799.issue21430@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 23:02:49 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 21:02:49 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1399237369.56.0.547190148375.issue21430@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 23:35:49 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sun, 04 May 2014 21:35:49 +0000 Subject: [issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__ In-Reply-To: <1399075361.96.0.75684702655.issue21421@psf.upfronthosting.co.za> Message-ID: <1399239349.96.0.254274870645.issue21421@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Cool. Thanks for the feedback. I split it into two patches for a reason; I wasn't wedded to the simplification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 23:40:26 2014 From: report at bugs.python.org (Uwe) Date: Sun, 04 May 2014 21:40:26 +0000 Subject: [issue21427] installer not working In-Reply-To: <1399217925.98.0.594848268677.issue21427@psf.upfronthosting.co.za> Message-ID: <1399239626.07.0.984482037581.issue21427@psf.upfronthosting.co.za> Uwe added the comment: Of course, only official sources the file is named python-3.4.0.msi and 23,924KB the name is similar to that of earlier versions which worked fine So I am not sure, whether it is 32 or 64bit maybe it would be a good idea to use two different names such as x86 and x64? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 23:41:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 04 May 2014 21:41:49 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1399239709.49.0.542086593105.issue21430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: pending() shouldn't be necessary for this. See https://docs.python.org/dev/library/ssl.html#notes-on-non-blocking-sockets Generally, when using non-blocking sockets, you first try to read (or write) and then catch any exceptions that might be raised if the socket isn't ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 4 23:59:45 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 04 May 2014 21:59:45 +0000 Subject: [issue21428] Python suddenly cares about EOLs formats on windows In-Reply-To: <1399220400.65.0.0106414482581.issue21428@psf.upfronthosting.co.za> Message-ID: <1399240785.91.0.944803475984.issue21428@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 00:01:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 04 May 2014 22:01:25 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399240885.66.0.311585933098.issue21422@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Reduce the memory footprint in which actual workload? This looks rather gratuitous to me. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 00:03:15 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 04 May 2014 22:03:15 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n In-Reply-To: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> Message-ID: <1399240995.86.0.922188912197.issue21420@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Mark, there doesn't seem to be a strong point in favour of this optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 00:05:53 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 04 May 2014 22:05:53 +0000 Subject: [issue21424] Simplify and speed-up heaqp.nlargest() In-Reply-To: <1399183029.85.0.254812547035.issue21424@psf.upfronthosting.co.za> Message-ID: <1399241153.69.0.427311896075.issue21424@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 00:06:49 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 22:06:49 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1399241209.18.0.552738284886.issue21431@psf.upfronthosting.co.za> Ned Deily added the comment: The problem is in PydocTopicsBuilder in Doc/tools/sphinxext/pyspecific.py. It needs to be smarter so that ideally it should continue to work with any Python >= 2.5 and independent of the Python being built. ---------- assignee: larry -> georg.brandl nosy: +benjamin.peterson stage: -> needs patch versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 00:07:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 04 May 2014 22:07:48 +0000 Subject: [issue21418] Segv during call to super_init in application embedding Python interpreter. In-Reply-To: <1399058560.74.0.137672140336.issue21418@psf.upfronthosting.co.za> Message-ID: <1399241268.0.0.0832504612873.issue21418@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 01:15:04 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 04 May 2014 23:15:04 +0000 Subject: [issue21431] 3.4.1rc1 test_pydoc fails: pydoc_data.topics.topics values are type "bytes" not "str" In-Reply-To: <1399234251.1.0.221071278299.issue21431@psf.upfronthosting.co.za> Message-ID: <1399245304.8.0.607257161073.issue21431@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, surely working with the current python is sufficient? I'd be happy if it was only guaranteed to run with the python tree it's a part of. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 01:39:39 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 May 2014 23:39:39 +0000 Subject: [issue21427] installer not working In-Reply-To: <1399217925.98.0.594848268677.issue21427@psf.upfronthosting.co.za> Message-ID: <1399246779.39.0.411800013741.issue21427@psf.upfronthosting.co.za> Ned Deily added the comment: There are two different names: the 64-bit installer is python-3.4.0.amd64.msi. But I see now that the error refers to py.exe, which I believe is the Python launcher. I've nosyed the Windows experts. ---------- nosy: +tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 02:43:31 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 05 May 2014 00:43:31 +0000 Subject: [issue9850] obsolete macpath module dangerously broken and should be removed In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za> Message-ID: <1399250611.18.0.968441296421.issue9850@psf.upfronthosting.co.za> Ned Deily added the comment: The patch appears fine but it really doesn't have anything to do with the gist of this issue. The problem remains that much of macpath is fundamentally broken. In the intervening years since the issue was opened, I contend that any need for OS 9 style paths (aka HFS paths) has diminished even further so I would still support starting in Python 3.5 the deprecation and removal process for this module. But, as long as it remains, to address the current problems at a minimum a patch would be needed to remove or raise exceptions for all of the macpath functions that make file system calls and to update the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 02:55:53 2014 From: report at bugs.python.org (eryksun) Date: Mon, 05 May 2014 00:55:53 +0000 Subject: [issue21427] installer not working In-Reply-To: <1399217925.98.0.594848268677.issue21427@psf.upfronthosting.co.za> Message-ID: <1399251353.06.0.403901070894.issue21427@psf.upfronthosting.co.za> eryksun added the comment: This is the first time I've used msilib, but it does appear that the component is marked as 64-bit: >>> import msilib >>> msidbComponentAttributes64bit = 256 >>> sql = ("SELECT ComponentId,Attributes FROM Component " ... "WHERE Component='launcher'") >>> db = msilib.OpenDatabase('python-3.4.0.msi', msilib.MSIDBOPEN_READONLY) >>> v = db.OpenView(sql) >>> v.Execute(None) >>> r = v.Fetch() >>> r.GetString(1) '{BE22BD81-ECE5-45BD-83B8-84BA45846A2D}' >>> attr = r.GetInteger(2) >>> attr 264 >>> attr & msidbComponentAttributes64bit 256 As it should be according to Tools/msi/msi.py: http://hg.python.org/cpython/file/04f714765c13/Tools/msi/msi.py#l990 Here's the comment regarding this: # msidbComponentAttributes64bit = 256; this disables registry redirection # to allow setting the SharedDLLs key in the 64-bit portion even for a # 32-bit installer. # XXX does this still allow to install the component on a 32-bit system? # Pick up 32-bit binary always For reference, the Component table: http://msdn.microsoft.com/en-us/library/aa368007%28v=vs.85%29.aspx ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 05:48:33 2014 From: report at bugs.python.org (Joshua Knights) Date: Mon, 05 May 2014 03:48:33 +0000 Subject: [issue21432] samba.git from git://git.samba.org/samba.git samba.netcmd.main not found Message-ID: <1399261713.46.0.185971866408.issue21432@psf.upfronthosting.co.za> New submission from Joshua Knights: This is a Python Path Issue: /root/samba-master/bin/samba-tool domain join AAF.ECPI DC -Uadministrator --realm=AAF.ECPI I get the following Error: Traceback (most recent call last): File "/root/samba-master/bin/samba-tool", line 33, in from samba.netcmd.main import cmd_sambatool ImportError: No module named samba.netcmd.main Here is the following Scenario of the above: I am running a CentosOS Release 6.5 (Final) Kernel Linux 2.632-431.11.2.el6.x86_64 GNOME 2.28.2 Both my Domain and Relm are AAF.ECPI; My Directory Path for Samba Version is /root/samba-master/ I did a Yum Update before starting anything Then I did a: yum install glibc glibc-devel gcc python* libacl-devel krb5-workstation krb5-libs pam_krb5 and then I removed the older samba packages before starting via the command: yum remove samba-winbind-client samba-common samba-client Then I installed git core using the command: yum install git-core Then I downloaded Samba with the following command: git clone git://git.samba.org/samba.git samba-master Then I installed the additional openldap-devel Library then I did the ./configure --enable-debug --enable-selftest then initiated the make command Then I successfully did a: kinit administrator and it prompted me for the Administrator Password of the Windows Domain Administrator. Then I ran klist and it successfully showed me I had a security token from the Windows Primary Domain Controller. Where I am currently Stuck is when I run the: /root/samba-master/bin/samba-tool domain join AAF.ECPI DC -Uadministrator --realm=AAF.ECPI I get the following Error: Traceback (most recent call last): File "/root/samba-master/bin/samba-tool", line 33, in from samba.netcmd.main import cmd_sambatool ImportError: No module named samba.netcmd.main When I do a find / - name samba.netcmd.main It pulls up: NOTHING!! If I pull up : find / -name netcmd I get: /root/samba-master/python/samba/netcmd /root/samba-master/bin/python/samba/netcmd /root/samba-master/bin/default/python/samba/netcmd In my research somebody said: to export the PYTHONPATH and to change it to the correct path of the netcmd command. if I wanted to fix it permanently then to update my bash.rc file. In other words Tell my samba tool where to look, and this look is only temporary till I close my terminal. Placing the command in the bash.rc file will run this script every time I open my terminal. Well, I tried all 3 and none of them worked. And if one of you has an answer, help me cause I need my domain member server to work ASAP. Like before 1pm on May 5th 2014 if at all possible. if one of your reps has an answer PLease call my Cell (425) 231-8472. My Absolute Deadline is May 7th by 8am, but that's pushing it. Thanks you, Joshua ---------- components: Extension Modules messages: 217903 nosy: SithKitty priority: normal severity: normal status: open title: samba.git from git://git.samba.org/samba.git samba.netcmd.main not found type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 05:54:23 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 May 2014 03:54:23 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1399262063.06.0.961486212105.issue14019@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that this issue wasn't about the formatter module - it relates to the str.format() method and the string.Formatter *class*. The formatter module is completely unrelated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 05:55:33 2014 From: report at bugs.python.org (Joshua Knights) Date: Mon, 05 May 2014 03:55:33 +0000 Subject: [issue21432] samba.git from git://git.samba.org/samba.git samba.netcmd.main not found In-Reply-To: <1399261713.46.0.185971866408.issue21432@psf.upfronthosting.co.za> Message-ID: <1399262133.5.0.372765173257.issue21432@psf.upfronthosting.co.za> Joshua Knights added the comment: Correction, this Might be a python path issue and I am not sure what version of python the samba.git is using. ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 07:07:03 2014 From: report at bugs.python.org (Samuel Ainsworth) Date: Mon, 05 May 2014 05:07:03 +0000 Subject: [issue21433] "False = True" produces segfault Message-ID: <1399266423.37.0.119235751148.issue21433@psf.upfronthosting.co.za> New submission from Samuel Ainsworth: Running this: >>> False = True Segmentation fault: 11 gives me this: Process: Python [17911] Path: /Library/Frameworks/Python.framework/Versions/3.3/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: 3.3.1 (3.3.1) Code Type: X86-64 (Native) Parent Process: bash [5092] Responsible: Terminal [298] User ID: 501 Date/Time: 2014-05-05 00:55:57.270 -0400 OS Version: Mac OS X 10.9.2 (13C1021) Report Version: 11 Anonymous UUID: B5997910-F526-88BB-2135-BD6152A81709 Sleep/Wake UUID: 88A9925C-46FC-488E-B7A5-EBB1AAE6BAC1 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 VM Regions Near 0: --> __TEXT 0000000100000000-0000000100001000 [ 4K] r-x/rwx SM=COW /Library/Frameworks/Python.framework/Versions/3.3/Resources/Python.app/Contents/MacOS/Python Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 readline.so 0x00000001006e1f57 call_readline + 647 1 org.python.python 0x0000000100008182 PyOS_Readline + 274 2 org.python.python 0x000000010000a048 tok_nextc + 104 3 org.python.python 0x000000010000a6f1 tok_get + 97 4 org.python.python 0x000000010000bb61 PyTokenizer_Get + 17 5 org.python.python 0x0000000100008294 parsetok + 212 6 org.python.python 0x0000000100105253 PyParser_ASTFromFile + 131 7 org.python.python 0x0000000100105459 PyRun_InteractiveOneFlags + 281 8 org.python.python 0x00000001001057ce PyRun_InteractiveLoopFlags + 78 9 org.python.python 0x00000001001070e1 PyRun_AnyFileExFlags + 161 10 org.python.python 0x000000010011dade Py_Main + 3454 11 org.python.python 0x0000000100000e1c 0x100000000 + 3612 12 org.python.python 0x0000000100000c74 0x100000000 + 3188 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x0000000102200000 rcx: 0x0000000102200000 rdx: 0x0000000000000a00 rdi: 0x0000000000000000 rsi: 0x00000001006e221c rbp: 0x00007fff5fbff210 rsp: 0x00007fff5fbff140 r8: 0x0000000102200000 r9: 0x0000000000000000 r10: 0x0000000000000001 r11: 0x0000000000000001 r12: 0x0000000000000001 r13: 0x000000000000000c r14: 0x00000001001fb678 r15: 0x00007fff5fbff1d0 rip: 0x00000001006e1f57 rfl: 0x0000000000010206 cr2: 0x0000000000000000 Logical CPU: 1 Error Code: 0x00000004 Trap Number: 14 Binary Images: 0x100000000 - 0x100000ff7 +org.python.python (3.3.1 - 3.3.1) <152E1B23-6F4F-E37A-CB7A-862C4D3D1FBD> /Library/Frameworks/Python.framework/Versions/3.3/Resources/Python.app/Contents/MacOS/Python 0x100003000 - 0x1001cbff7 +org.python.python (3.3.1, [c] 2004-2013 Python Software Foundation. - 3.3.1) <0328F41B-A30B-2BBA-D4C3-FA2E5DE4FCA1> /Library/Frameworks/Python.framework/Versions/3.3/Python 0x1003f3000 - 0x1003f4ff7 +_heapq.so (???) <1C40E27A-FBFA-6B43-9AA9-9FCDF1961459> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_heapq.so 0x1006e0000 - 0x1006e2ff7 +readline.so (???) <5D0B15E6-1E61-AA6F-3915-27BBA7D83F4C> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/readline.so 0x1020f1000 - 0x10210fffb libedit.2.dylib (39) <1B0596DB-F336-32E7-BB9F-51BF70DB5305> /usr/lib/libedit.2.dylib 0x102120000 - 0x102174fe7 +libncursesw.5.dylib (5) /Library/Frameworks/Python.framework/Versions/3.3/lib/libncursesw.5.dylib 0x7fff6343f000 - 0x7fff63472817 dyld (239.4) <2B17750C-ED1B-3060-B64E-21897D08B28B> /usr/lib/dyld 0x7fff894f4000 - 0x7fff894faff7 libsystem_platform.dylib (24.90.1) <3C3D3DA8-32B9-3243-98EC-D89B9A1670B3> /usr/lib/system/libsystem_platform.dylib 0x7fff89931000 - 0x7fff89958ff7 libsystem_network.dylib (241.3) <8B1E1F1D-A5CC-3BAE-8B1E-ABC84337A364> /usr/lib/system/libsystem_network.dylib 0x7fff89b7f000 - 0x7fff89b80ff7 libsystem_blocks.dylib (63) /usr/lib/system/libsystem_blocks.dylib 0x7fff89fd5000 - 0x7fff89fd9ff7 libcache.dylib (62) /usr/lib/system/libcache.dylib 0x7fff8a21f000 - 0x7fff8a228ff3 libsystem_notify.dylib (121) <52571EC3-6894-37E4-946E-064B021ED44E> /usr/lib/system/libsystem_notify.dylib 0x7fff8a52f000 - 0x7fff8a536fff libcompiler_rt.dylib (35) <4CD916B2-1B17-362A-B403-EF24A1DAC141> /usr/lib/system/libcompiler_rt.dylib 0x7fff8b144000 - 0x7fff8b146ff3 libsystem_configuration.dylib (596.13) /usr/lib/system/libsystem_configuration.dylib 0x7fff8c3b4000 - 0x7fff8c3ddff7 libc++abi.dylib (49.1) <21A807D3-6732-3455-B77F-743E9F916DF0> /usr/lib/libc++abi.dylib 0x7fff8c44c000 - 0x7fff8c44dfff libunc.dylib (28) <62682455-1862-36FE-8A04-7A6B91256438> /usr/lib/system/libunc.dylib 0x7fff8d55a000 - 0x7fff8d55eff7 libsystem_stats.dylib (93.90.3) <1A55AF8A-B6C4-3163-B557-3AD25DA643A8> /usr/lib/system/libsystem_stats.dylib 0x7fff8d55f000 - 0x7fff8d57aff7 libsystem_malloc.dylib (23.10.1) /usr/lib/system/libsystem_malloc.dylib 0x7fff8e58a000 - 0x7fff8e76ffff com.apple.CoreFoundation (6.9 - 855.16) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8ed53000 - 0x7fff8ed5aff3 libcopyfile.dylib (103) <5A881779-D0D6-3029-B371-E3021C2DDA5E> /usr/lib/system/libcopyfile.dylib 0x7fff8f1df000 - 0x7fff8f1fbff7 libsystem_kernel.dylib (2422.92.1) <3F649963-7FA1-3201-8FF6-8438A52B9973> /usr/lib/system/libsystem_kernel.dylib 0x7fff8fb2e000 - 0x7fff8fb48fff libdispatch.dylib (339.90.1) /usr/lib/system/libdispatch.dylib 0x7fff8fdf5000 - 0x7fff8fe06ff7 libz.1.dylib (53) <42E0C8C6-CA38-3CA4-8619-D24ED5DD492E> /usr/lib/libz.1.dylib 0x7fff90084000 - 0x7fff90087ff7 libdyld.dylib (239.4) /usr/lib/system/libdyld.dylib 0x7fff91ae8000 - 0x7fff91b71ff7 libsystem_c.dylib (997.90.3) <6FD3A400-4BB2-3B95-B90C-BE6E9D0D78FA> /usr/lib/system/libsystem_c.dylib 0x7fff922af000 - 0x7fff922defd2 libsystem_m.dylib (3047.16) /usr/lib/system/libsystem_m.dylib 0x7fff922df000 - 0x7fff922e6ff7 libsystem_pthread.dylib (53.1.4) /usr/lib/system/libsystem_pthread.dylib 0x7fff92563000 - 0x7fff9256bfff libsystem_dnssd.dylib (522.90.2) /usr/lib/system/libsystem_dnssd.dylib 0x7fff9256c000 - 0x7fff92724ff3 libicucore.A.dylib (511.31) <167DDD0A-A935-31AF-B5B9-940268EC3A3C> /usr/lib/libicucore.A.dylib 0x7fff92825000 - 0x7fff92826ff7 libDiagnosticMessagesClient.dylib (100) <4CDB0F7B-C0AF-3424-BC39-495696F0DB1E> /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff92a3e000 - 0x7fff92a3fff7 libsystem_sandbox.dylib (278.11) <5E5A6E09-33A9-391A-AB34-E57D93BB1551> /usr/lib/system/libsystem_sandbox.dylib 0x7fff92cf9000 - 0x7fff92ea6f27 libobjc.A.dylib (551.1) /usr/lib/libobjc.A.dylib 0x7fff934b5000 - 0x7fff934f7ff7 libauto.dylib (185.5) /usr/lib/libauto.dylib 0x7fff935bc000 - 0x7fff935ecfff libncurses.5.4.dylib (42) /usr/lib/libncurses.5.4.dylib 0x7fff93ddc000 - 0x7fff93de3ff8 liblaunch.dylib (842.90.1) <38D1AB2C-A476-385F-8EA8-7AB604CA1F89> /usr/lib/system/liblaunch.dylib 0x7fff93df6000 - 0x7fff93dfbff7 libunwind.dylib (35.3) <78DCC358-2FC1-302E-B395-0155B47CB547> /usr/lib/system/libunwind.dylib 0x7fff94f82000 - 0x7fff94f82ff7 libkeymgr.dylib (28) <3AA8D85D-CF00-3BD3-A5A0-E28E1A32A6D8> /usr/lib/system/libkeymgr.dylib 0x7fff9566d000 - 0x7fff956bffff libc++.1.dylib (120) <4F68DFC5-2077-39A8-A449-CAC5FDEE7BDE> /usr/lib/libc++.1.dylib 0x7fff95aa5000 - 0x7fff95ab6ff7 libsystem_asl.dylib (217.1.4) <655FB343-52CF-3E2F-B14D-BEBF5AAEF94D> /usr/lib/system/libsystem_asl.dylib 0x7fff962e0000 - 0x7fff962e5fff libmacho.dylib (845) <1D2910DF-C036-3A82-A3FD-44FF73B5FF9B> /usr/lib/system/libmacho.dylib 0x7fff962fe000 - 0x7fff96308fff libcommonCrypto.dylib (60049) <8C4F0CA0-389C-3EDC-B155-E62DD2187E1D> /usr/lib/system/libcommonCrypto.dylib 0x7fff96339000 - 0x7fff9635dfff libxpc.dylib (300.90.2) /usr/lib/system/libxpc.dylib 0x7fff96d82000 - 0x7fff96d83ffb libremovefile.dylib (33) <3543F917-928E-3DB2-A2F4-7AB73B4970EF> /usr/lib/system/libremovefile.dylib 0x7fff96d84000 - 0x7fff96dd2fff libcorecrypto.dylib (161.1) /usr/lib/system/libcorecrypto.dylib 0x7fff96dd3000 - 0x7fff96dd4ff7 libSystem.B.dylib (1197.1.1) /usr/lib/libSystem.B.dylib 0x7fff971d4000 - 0x7fff971d6ff7 libquarantine.dylib (71) <7A1A2BCB-C03D-3A25-BFA4-3E569B2D2C38> /usr/lib/system/libquarantine.dylib 0x7fff971d7000 - 0x7fff971feffb libsystem_info.dylib (449.1.3) <7D41A156-D285-3849-A2C3-C04ADE797D98> /usr/lib/system/libsystem_info.dylib External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 48730 thread_create: 1 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=77.4M resident=14.1M(18%) swapped_out_or_unallocated=63.3M(82%) Writable regions: Total=39.2M written=3348K(8%) resident=3872K(10%) swapped_out=0K(0%) unallocated=35.4M(90%) REGION TYPE VIRTUAL =========== ======= Kernel Alloc Once 4K MALLOC 30.5M MALLOC (admin) 16K MALLOC_LARGE (reserved) 384K reserved VM address space (unallocated) STACK GUARD 56.0M Stack 8192K VM_ALLOCATE 8K __DATA 1616K __LINKEDIT 66.3M __TEXT 11.1M __UNICODE 544K shared memory 4K =========== ======= TOTAL 174.4M TOTAL, minus reserved VM space 174.0M Model: MacBookAir5,2, BootROM MBA51.00EF.B02, 2 processors, Intel Core i7, 2 GHz, 8 GB, SMC 2.5f9 Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 1024 MB Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434353153364D465238412D50422020 Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434353153364D465238412D50422020 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xE9), Broadcom BCM43xx 1.0 (5.106.98.100.22) Bluetooth: Version 4.2.3f10 13477, 3 services, 15 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en0 Serial ATA Device: APPLE SSD SM256E, 251 GB USB Device: Hub USB Device: Hub USB Device: Internal Memory Card Reader USB Device: Apple Internal Keyboard / Trackpad USB Device: BRCM20702 Hub USB Device: Bluetooth USB Host Controller USB Device: Hub USB Device: FaceTime HD Camera (Built-in) Thunderbolt Bus: MacBook Air, Apple Inc., 23.4 ---------- messages: 217906 nosy: Samuel.Ainsworth priority: normal severity: normal status: open title: "False = True" produces segfault versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 07:08:43 2014 From: report at bugs.python.org (Samuel Ainsworth) Date: Mon, 05 May 2014 05:08:43 +0000 Subject: [issue21433] "False = True" produces segfault In-Reply-To: <1399266423.37.0.119235751148.issue21433@psf.upfronthosting.co.za> Message-ID: <1399266523.32.0.128718239478.issue21433@psf.upfronthosting.co.za> Changes by Samuel Ainsworth : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 07:29:25 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 05 May 2014 05:29:25 +0000 Subject: [issue21433] "False = True" produces segfault In-Reply-To: <1399266423.37.0.119235751148.issue21433@psf.upfronthosting.co.za> Message-ID: <1399267765.06.0.541197219988.issue21433@psf.upfronthosting.co.za> Ned Deily added the comment: See Issue18458. Update to the latest Python 3.3.5 or 3.4.x. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 08:42:21 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 05 May 2014 06:42:21 +0000 Subject: [issue21432] samba.git from git://git.samba.org/samba.git samba.netcmd.main not found In-Reply-To: <1399261713.46.0.185971866408.issue21432@psf.upfronthosting.co.za> Message-ID: <1399272141.13.0.775147920439.issue21432@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, this is a tracker for bugs in Python, not a help forum. Suggest you ask your question on a user forum, like Python list (https://mail.python.org/mailman/listinfo/python-list) or a samba group or perhaps http://superuser.com. ---------- nosy: +ned.deily resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 08:42:41 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 05 May 2014 06:42:41 +0000 Subject: [issue21432] samba.git from git://git.samba.org/samba.git samba.netcmd.main not found In-Reply-To: <1399261713.46.0.185971866408.issue21432@psf.upfronthosting.co.za> Message-ID: <1399272161.43.0.528507204125.issue21432@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 09:13:36 2014 From: report at bugs.python.org (akira) Date: Mon, 05 May 2014 07:13:36 +0000 Subject: [issue20866] segfailt with os.popen and SIGPIPE In-Reply-To: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za> Message-ID: <1399274016.54.0.0889183899235.issue20866@psf.upfronthosting.co.za> akira added the comment: Victor, where can you reproduce it (OS, python version, what C lib)? I don't receive segfault, only sigpipe (see msg217818 ). Here's gdb backtrace after the signal: Program received signal SIGPIPE, Broken pipe. 0x00007ffff71e1040 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82 82 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) backtrace #0 0x00007ffff71e1040 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82 #1 0x00007ffff7173883 in _IO_new_file_write (f=0x7e1f10, data=0x7ffff66cb034, n=1097728) at fileops.c:1289 #2 0x00007ffff717374a in new_do_write (fp=0x7e1f10, data=0x7ffff66cb034 "0123456789\n...01"..., to_do=1097728) at fileops.c:543 #3 0x00007ffff71741fe in _IO_new_file_xsputn (n=1100000, data=, f=0x7e1f10) at fileops.c:1383 #4 _IO_new_file_xsputn (f=0x7e1f10, data=, n=1100000) at fileops.c:1305 #5 0x00007ffff7169cdd in _IO_fwrite (buf=, size=1, count=1100000, fp=0x7e1f10) at iofwrite.c:45 #6 0x000000000042c23c in file_write (f=0x7ffff7f16540, args=) at Objects/fileobject.c:1851 Note: the line is 1851, not 1852 (as in the latest 2.7 version [1]) as in your traceback. And the calls inside _IO_new_file_xsputn() are also different. [1]: http://hg.python.org/cpython/file/b768d41dec0a/Objects/fileobject.c#l1852 python2.7.6 is installed using `pythonz install 2.7.6` command. Just to make sure that python2.7.6 *can* segfault: $ python2.7.6 -c'import ctypes; ctypes.memset(0,0,1)' Segmentation fault (core dumped) core file is not written on my system: $ cat /proc/sys/kernel/core_pattern |/usr/share/apport/apport %p %s %c But I can see in the log when a process segfaults e.g., the segfault due to memset is logged: $ tail -F /var/log/apport.log ERROR: apport (pid 8501) ... executable: ~/.pythonz/pythons/CPython-2.7.6/bin/python2.7 \ (command line "python2.7.6 -cimport\ ctypes;\ ctypes.memset(0,0,1)") To find out where `fwrite` come from, I've done: $ nm $(which python2.7.6) | grep fwrite U fwrite@@GLIBC_2.2.5 $ cat $(gcc -print-file-name=libc.so) /* GNU ld script ... */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/x86_64-linux-gnu/libc.so.6 ... ) $ ldd $(which python2.7.6) ... libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 ... $ /lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Ubuntu EGLIBC 2.15-0ubuntu10.5) stable release version 2.15, by Roland McGrath et al. Copyright (C) 2012 Free Software Foundation, Inc. ... Compiled by GNU CC version 4.6.3. Compiled on a Linux 3.2.50 system on 2013-09-30. ... /usr/bin/python behaves similar -- it just has version that is not mentioned by the OP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 09:48:01 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 05 May 2014 07:48:01 +0000 Subject: [issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX In-Reply-To: <1265236812.59.0.190434450591.issue7850@psf.upfronthosting.co.za> Message-ID: <1399276081.41.0.310525036648.issue7850@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Caelyn: Thanks for the patch. Some comments: * Please use aliased=False instead of aliased=0 in the patch. * It would be great if you could enhance the test a bit to actually check the return value. This would need a mock of the os.uname API for the test. * Doc string "if "aliased" is true" should read "If aliased is true" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 09:49:29 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 05 May 2014 07:49:29 +0000 Subject: [issue7850] platform.system() should be "macosx" instead of "Darwin" on OSX In-Reply-To: <1265236812.59.0.190434450591.issue7850@psf.upfronthosting.co.za> Message-ID: <1399276169.53.0.89526189186.issue7850@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Removing 2.7 as target, since this is a new feature. ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 10:46:24 2014 From: report at bugs.python.org (David Woakes) Date: Mon, 05 May 2014 08:46:24 +0000 Subject: [issue21132] Failure to import win32api In-Reply-To: <1396440853.53.0.482865580463.issue21132@psf.upfronthosting.co.za> Message-ID: <1399279584.36.0.168112362163.issue21132@psf.upfronthosting.co.za> David Woakes added the comment: This issue is not related to anything in the Python 3.4 release. It's a problem with the installer not asking to be installed as administrator. Running C:\Python34\Scripts\pywin32_postinstall.py as administrator after installing fixes this. ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 10:54:21 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 05 May 2014 08:54:21 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399280061.98.0.117577001691.issue21422@psf.upfronthosting.co.za> Mark Dickinson added the comment: BTW, there's also a behaviour change here. Before the patch: >>> True << 0 1 After the patch: >>> True << 0 True Which demonstrates another good reason to avoid trivial-looking optimisations: it's far too easy to accidentally change behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 11:20:58 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 05 May 2014 09:20:58 +0000 Subject: [issue21434] python -3 documentation is outdated Message-ID: <1399281658.38.0.402381658113.issue21434@psf.upfronthosting.co.za> New submission from Berker Peksag: https://docs.python.org/2.7/using/cmdline.html#cmdoption-3 Currently, lib2to3 provides fixers for dict.has_key(), apply(), callable(), execfile() and reduce() functions. The "reload" fixer was added to Python 3.4 in issue 11797, but not backported to 2.7. ---------- assignee: docs at python components: Documentation files: cmdline-3.diff keywords: patch messages: 217914 nosy: berker.peksag, docs at python priority: normal severity: normal stage: patch review status: open title: python -3 documentation is outdated versions: Python 2.7 Added file: http://bugs.python.org/file35151/cmdline-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 11:31:21 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 05 May 2014 09:31:21 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399282281.24.0.224597070043.issue21121@psf.upfronthosting.co.za> Stefan Krah added the comment: The current patch allows the user to specify e.g.: CFLAGS_NODIST="-march=core2" ./configure So it would be surprising to get: >>> import sysconfig >>> sysconfig.get_config_var('CFLAGS_NODIST') '' Now, we could restrict ourselves entirely to internal PY_CFLAGS_NODIST, but I think exposing the feature is really useful if users or distributors want to specify optimizations, FPU behavior or other things that should not generally show up in distutils. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 13:01:29 2014 From: report at bugs.python.org (Uwe) Date: Mon, 05 May 2014 11:01:29 +0000 Subject: [issue21427] installer not working In-Reply-To: <1399217925.98.0.594848268677.issue21427@psf.upfronthosting.co.za> Message-ID: <1399287689.15.0.0222218739804.issue21427@psf.upfronthosting.co.za> Uwe added the comment: I guess this is merely describing the problem and not the solution? (by the way I had no difficulties with the 64bit version on a 64bit win7 system) Would it be possible to produce the binairies myself using the mingw compiler? The readme says visual c++ is required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 13:58:54 2014 From: report at bugs.python.org (Matthias Klose) Date: Mon, 05 May 2014 11:58:54 +0000 Subject: [issue17756] test_syntax_error fails when run in the installed location In-Reply-To: <1366111959.84.0.955866306047.issue17756@psf.upfronthosting.co.za> Message-ID: <1399291134.17.0.741704355444.issue17756@psf.upfronthosting.co.za> Matthias Klose added the comment: seen this again in our autopkg tester https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-python3.4/12/ however now I can't reproduce this locally, and the test succeeds during the build. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 13:59:59 2014 From: report at bugs.python.org (Peter Inglesby) Date: Mon, 05 May 2014 11:59:59 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future Message-ID: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> New submission from Peter Inglesby: The following code causes a segfault when run under Python3.4+ on OSX10.9. # segfaulter.py import asyncio class A: pass class B: def __init__(self, future): self.future = future def __del__(self): self.a = None @asyncio.coroutine def do_work(future): a = A() b = B(asyncio.Future()) a.b = b b.a = a future.set_result(None) future = asyncio.Future() asyncio.Task(do_work(future)) loop = asyncio.get_event_loop() loop.run_until_complete(future) It does matter that the Future is passed to b's __init__ method. It doesn't matter whether the Future has been resolved. Attached is the problem report generated by OSX on the crash. ---------- files: problemreport.txt messages: 217918 nosy: inglesp priority: normal severity: normal status: open title: Segfault with cyclic reference and asyncio.Future type: crash versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35152/problemreport.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 14:00:08 2014 From: report at bugs.python.org (Sebastian Rittau) Date: Mon, 05 May 2014 12:00:08 +0000 Subject: [issue21436] bring back importlib.load_source() et al. Message-ID: <1399291208.69.0.802643633069.issue21436@psf.upfronthosting.co.za> New submission from Sebastian Rittau: It was very easy to load plugin files in Python 2: import imp my_module = imp.load_source("what.ever", "foo.py") Unfortunately, this became much more obscure in Python 3.3: import importlib.machinery loader = importlib.machinery.SourceFileLoader("what.ever", "foo.py") my_module = loader.load_module("what.ever") In Python 3.4 even this has been deprecated. There should be a way (preferable an easy-to-use one) to load a Python module by filename or by stream. ---------- components: Library (Lib) messages: 217919 nosy: srittau priority: normal severity: normal status: open title: bring back importlib.load_source() et al. type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 14:08:29 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Mon, 05 May 2014 12:08:29 +0000 Subject: [issue21436] bring back importlib.load_source() et al. In-Reply-To: <1399291208.69.0.802643633069.issue21436@psf.upfronthosting.co.za> Message-ID: <1399291709.7.0.00135833629367.issue21436@psf.upfronthosting.co.za> Changes by Claudiu.Popa : ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 14:21:32 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 05 May 2014 12:21:32 +0000 Subject: [issue21436] bring back importlib.load_source() et al. In-Reply-To: <1399291208.69.0.802643633069.issue21436@psf.upfronthosting.co.za> Message-ID: <1399292492.26.0.273114776703.issue21436@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +brett.cannon, eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 14:29:37 2014 From: report at bugs.python.org (dellair jie) Date: Mon, 05 May 2014 12:29:37 +0000 Subject: [issue21392] Python on Cygwin: subprocess.call BlockingIOError: [Errno 11] Resource temporarily unavailable In-Reply-To: <1398849344.37.0.135899033278.issue21392@psf.upfronthosting.co.za> Message-ID: <1399292977.02.0.334450338612.issue21392@psf.upfronthosting.co.za> dellair jie added the comment: Eric, Very much appreciated for your offer to help. This issue is with Cygwin fork(), documented here: http://cygwin.com/faq.html#faq.using.fixing-fork-failures I am closing the issue. Have a great day! ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 15:32:12 2014 From: report at bugs.python.org (akira) Date: Mon, 05 May 2014 13:32:12 +0000 Subject: [issue21437] document that asyncio.ProactorEventLoop doesn't support SSL Message-ID: <1399296732.42.0.791038898639.issue21437@psf.upfronthosting.co.za> New submission from akira: In Lib/asyncio/proactor_events.py:419 [1]: def _start_serving(self, protocol_factory, sock, ssl=None, server=None): if ssl: raise ValueError('IocpEventLoop is incompatible with SSL.') [1]: http://hg.python.org/cpython/file/4f26430b03fd/Lib/asyncio/proactor_events.py#l419 ProactorEventLoop is mentioned in the docs that it should be used to run subprocesses on Windows. [2] [2]: http://hg.python.org/cpython/file/4f26430b03fd/Doc/library/asyncio-subprocess.rst It might be a good example to demonstrate the idiomatic way how two different event loops could be used (to support both subprocesses and ssl connections in the same program). ---------- assignee: docs at python components: Documentation messages: 217921 nosy: akira, docs at python priority: normal severity: normal status: open title: document that asyncio.ProactorEventLoop doesn't support SSL type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 15:38:42 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 05 May 2014 13:38:42 +0000 Subject: [issue21438] Document which importlib.machinery loaders don't require an argument for load_module() Message-ID: <1399297122.37.0.213732682658.issue21438@psf.upfronthosting.co.za> New submission from Brett Cannon: Multiple loaders don't require an argument for load_module() because the module name is provided as part of instance initialization. As such it doesn't hurt to document this fact to help shorten manual calls to the instances as when people do when transitioning off of the imp module. ---------- assignee: brett.cannon components: Documentation messages: 217922 nosy: brett.cannon priority: normal severity: normal status: open title: Document which importlib.machinery loaders don't require an argument for load_module() versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 15:46:59 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 05 May 2014 13:46:59 +0000 Subject: [issue21436] Consider leaving importlib.abc.Loader.load_module() In-Reply-To: <1399291208.69.0.802643633069.issue21436@psf.upfronthosting.co.za> Message-ID: <1399297619.95.0.360502888267.issue21436@psf.upfronthosting.co.za> Brett Cannon added the comment: So it's not quite as bad as you think as SourceFileLoader.load_module() doesn't need an argument (I've opened http://bugs.python.org/issue21438 to fix the documentation). Admittedly it is a longer command than imp.load_source() to type, but there is no extra information required or a necessity that you break the command up into multiple lines. Plus imp.load_source() is just plain bad. The reason the imp module is deprecated in Python 3.4 is because it does not expose the low-level details of import in a way that makes any sense since Python 2.3 (and yes, I meant to write 2.3 instead of 3.3; the problem has persisted _that_ long). That being said, talks are just starting to consider undoing the documented deprecation of load_module() such that you can continue to use that as a substitute for imp.load_source()/imp.load_module(). I'm going to leave this bug open, hijack its title, and refocus this as to consider leaving importlib.abc.Loader.load_module() in importlib as the all-powerful fallback API which also simplifies transitioning from imp. ---------- assignee: -> brett.cannon nosy: +ncoghlan title: bring back importlib.load_source() et al. -> Consider leaving importlib.abc.Loader.load_module() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 15:50:45 2014 From: report at bugs.python.org (Martin Pitt) Date: Mon, 05 May 2014 13:50:45 +0000 Subject: [issue17756] test_syntax_error fails when run in the installed location In-Reply-To: <1366111959.84.0.955866306047.issue17756@psf.upfronthosting.co.za> Message-ID: <1399297845.21.0.187664797935.issue17756@psf.upfronthosting.co.za> Martin Pitt added the comment: I can reproduce this here. In that test, I added the following: with open('/tmp/debug', 'w') as f: for call in self.stderr.method_calls: f.write('call: %s\n' % str(call)) This gives: =========== 8< ============ call: call.write('Python on \nType "help", "copyright", "credits" or "license" for more information.\n(InteractiveConsole)\n') call: call.write('Traceback (most recent call last):\n') call: call.write(' File "/usr/lib/python3.4/code.py", line 90, in runcode\n') call: call.write(' ') call: call.write('exec(code, self.locals)') call: call.write('\n') call: call.write(' File "", line 1, in \n') call: call.write('NameError') call: call.write(': ') call: call.write("name 'undefined' is not defined") call: call.write('\n') call: call.write('\n') =========== 8< ============ Observe that the test checks if 'NameError:' in ''.join(call[1]): but the "NameError" and the ":" are in two different call lines. I don't know how self.stderr.method_calls is built, but this sounds like a race condition/timing or a stdin/out buffering issue? I. e. the original print that produces the "NameError:" certainly does that in two steps; perhaps the testsuite thing that repeatedly read()s on stderr catches these two as separate write()s then? ---------- nosy: +pitti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 15:54:14 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 05 May 2014 13:54:14 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1399298054.2.0.547217947437.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: My current thinking on this it to introduce in importlib.util: def module_from_spec(spec, module=None): """Create/initialize a module based on the provided spec. If a module is provided then spec.loader.create_module() will not be consulted. """ This serves two purposes. One is that it abstracts the loader.create_module() dance out so that's no longer a worry. But more crucially it also means that if you have the function create the module for you then it will be returned with all of its attributes set without having to worry about forgetting that step. The module argument is just for convenience in those instances where you truly only want to override the module creation dance for some reason and really just want the attribute setting bit. ---------- nosy: +aronacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 16:34:11 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 May 2014 14:34:11 +0000 Subject: [issue21439] Numerous minor issues in Language Reference Message-ID: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> New submission from Zachary Ware: Reported by Feliks Kluzniak on docs@: """ Hello! I have been reading the Language Reference Manual in order to teach myself Python 3. I noticed several minor errors, and a much larger number of linguistic or editorial infelicities. I have listed them all in the enclosed document: I hope it will be useful. Sincerely, ? Feliks Kluzniak P.S. My apologies for not having the time to weed out those remarks which might already have been entered into the list of ?documentation bugs?. """ ---------- assignee: zach.ware components: Documentation files: PythonRefmanual_3_4_0_Errata.rtf keywords: easy messages: 217926 nosy: zach.ware priority: normal severity: normal stage: test needed status: open title: Numerous minor issues in Language Reference type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35153/PythonRefmanual_3_4_0_Errata.rtf _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 16:35:20 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 May 2014 14:35:20 +0000 Subject: [issue21439] Numerous minor issues in Language Reference In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> Message-ID: <1399300520.71.0.542287339607.issue21439@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 17:10:16 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 05 May 2014 15:10:16 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1399302616.07.0.427183419774.issue14019@psf.upfronthosting.co.za> Eric V. Smith added the comment: The issue is about tests for str.format and string.Formatter, but in http://bugs.python.org/msg194709 and the associated patch there are tests for the formatter module to increase its coverage. I suggested on the mentorship list that we break this into two issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 17:17:51 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 May 2014 15:17:51 +0000 Subject: [issue21366] Document that return in finally overwrites prev value In-Reply-To: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za> Message-ID: <1399303071.08.0.083624637057.issue21366@psf.upfronthosting.co.za> Zachary Ware added the comment: How's this, or is it too much? ---------- keywords: +patch nosy: +zach.ware Added file: http://bugs.python.org/file35154/issue21366.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 17:18:34 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 May 2014 15:18:34 +0000 Subject: [issue21366] Document that return in finally overwrites prev value In-Reply-To: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za> Message-ID: <1399303114.42.0.817645430678.issue21366@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> patch review type: behavior -> enhancement versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 17:44:40 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 05 May 2014 15:44:40 +0000 Subject: [issue21366] Document that return in finally overwrites prev value In-Reply-To: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za> Message-ID: <1399304680.06.0.0125748844679.issue21366@psf.upfronthosting.co.za> R. David Murray added the comment: I would remove the parenthetical (it was so stated in immediately preceding paragraph and thus is redundant), and instead of "win", I would say "will always be the last one executed". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 18:07:30 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 May 2014 16:07:30 +0000 Subject: [issue18604] Consolidate gui available checks in test.support In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za> Message-ID: <1399306050.65.0.438560241928.issue18604@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks Ned. Unfortunately, I don't have a Mac to test on, so I can't help much with figuring out what's going on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 18:29:18 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 16:29:18 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399307358.27.0.808020029788.issue21435@psf.upfronthosting.co.za> Tim Golden added the comment: I can confirm that this crashes on Windows as well. Failure actually occurs in gcmodule.c:finalize_garbage. Adding Guido as it looks as it's tied to asyncio. ---------- nosy: +Guido.van.Rossum, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 18:35:24 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 05 May 2014 16:35:24 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1399307724.39.0.721992595282.issue6839@psf.upfronthosting.co.za> Ethan Furman added the comment: Ah, so when you (Adam) said "extraction works fine", what you meant was "extraction works fine *in other programs*". Okay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 18:40:07 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Mon, 05 May 2014 16:40:07 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1399308007.03.0.897848535334.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Both. Other programs, and in python scripts when raise() is removed in zipfile.py. Unless your results are different. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 18:51:20 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 16:51:20 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1399308680.04.0.0236250359478.issue21393@psf.upfronthosting.co.za> Tim Golden added the comment: Unfortunately it looks as though this wasn't the correct way to close a Crypto handle. It isn't a conventional handle and we be using CryptReleaseContext to "close" it. cf http://msdn.microsoft.com/en-us/library/windows/desktop/aa382041%28v=vs.85%29.aspx for example. At present it's giving a mismatched-pointer warning when building on Windows (because it's actually a pointer under the covers and not a simple numerical HANDLE). Simple patch attached ---------- Added file: http://bugs.python.org/file35155/issue21393.cryptreleasecontext.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 18:52:01 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 16:52:01 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1399308721.55.0.986568353358.issue21393@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 18:52:23 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 16:52:23 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1399308743.62.0.54073766652.issue21393@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 19:22:10 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 17:22:10 +0000 Subject: [issue21440] Use support.rmtree in test_zipfile Message-ID: <1399310530.32.0.0955350320497.issue21440@psf.upfronthosting.co.za> New submission from Tim Golden: At present test_zipfile uses shutil.rmtree to remove its test artefacts. This intermittently but frequently fails to remove cleanly on a Windows development box. Changing it to use the test.support helper functions should reduce the incidence. ---------- assignee: tim.golden components: Tests messages: 217935 nosy: tim.golden priority: normal severity: normal stage: patch review status: open title: Use support.rmtree in test_zipfile type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 19:23:04 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 May 2014 17:23:04 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399310584.24.0.738347347578.issue21435@psf.upfronthosting.co.za> Guido van Rossum added the comment: Confirmed too (OSX 10.9 again, CPython 3.4 or 3.5; but it doesn't crash with CPython 3.3). There is no C code in asyncio, so I'm not sure how asyncio can be directly responsible for this crash. Probably some of the GC improvements have an edge case that is triggered by the example program. Adding Antoine and Victor, they probably understand that code better. ---------- nosy: +gvanrossum, haypo, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 19:23:39 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 17:23:39 +0000 Subject: [issue21440] Use support.rmtree in test_zipfile In-Reply-To: <1399310530.32.0.0955350320497.issue21440@psf.upfronthosting.co.za> Message-ID: <1399310619.77.0.971377984295.issue21440@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- keywords: +patch Added file: http://bugs.python.org/file35156/issue21440.test_zipfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 19:34:57 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 17:34:57 +0000 Subject: [issue21440] Use support.rmtree in test_zipfile In-Reply-To: <1399310530.32.0.0955350320497.issue21440@psf.upfronthosting.co.za> Message-ID: <1399311297.18.0.69017867001.issue21440@psf.upfronthosting.co.za> Tim Golden added the comment: Same goes for test_tarfile (updated patch attached) ---------- Added file: http://bugs.python.org/file35157/issue21440.test_tarzipfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 19:35:22 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 17:35:22 +0000 Subject: [issue21440] Use support.rmtree in test_zipfile In-Reply-To: <1399310530.32.0.0955350320497.issue21440@psf.upfronthosting.co.za> Message-ID: <1399311322.95.0.31654473166.issue21440@psf.upfronthosting.co.za> Tim Golden added the comment: Adding Zach as another Windows dev ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 20:28:03 2014 From: report at bugs.python.org (Jake Vanderplas) Date: Mon, 05 May 2014 18:28:03 +0000 Subject: [issue21441] Buffer Protocol Documentation Error Message-ID: <1399314483.29.0.410069597608.issue21441@psf.upfronthosting.co.za> New submission from Jake Vanderplas: The ``obj`` and ``buf`` structure elements are switched in the documentation of the Buffer Protocol. Compare https://docs.python.org/3.3/c-api/buffer.html#Py_buffer to https://github.com/python/cpython/blob/master/Include/object.h#L179-180 ---------- assignee: docs at python components: Documentation files: bufferdoc.patch keywords: patch messages: 217939 nosy: Jake.Vanderplas, docs at python priority: normal severity: normal status: open title: Buffer Protocol Documentation Error versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35158/bufferdoc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 20:47:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 May 2014 18:47:52 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <3gMtNl5gPYz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset 5c1c14ff1f13 by Tim Golden in branch 'default': Issue18314 Allow unlink to remove junctions. Includes support for creating junctions. Patch by Kim Gr?sman http://hg.python.org/cpython/rev/5c1c14ff1f13 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 20:59:29 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 May 2014 18:59:29 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1399316369.6.0.337514651851.issue18314@psf.upfronthosting.co.za> Zachary Ware added the comment: Just skimming, I noticed something about replacing calloc() with PyMem_RawAlloc; note that there is now PyMem_Calloc or PyMem_RawCalloc that you should be able to use if you prefer. See #21233. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 21:16:52 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 May 2014 19:16:52 +0000 Subject: [issue21442] Win32 compiler warning in PyBytes_Concat Message-ID: <1399317412.48.0.97409893432.issue21442@psf.upfronthosting.co.za> New submission from Zachary Ware: Issue #21377 introduced a compiler warning on Windows: ..\Objects\bytesobject.c(2824): warning C4018: '>' : signed/unsigned mismatch [P:\ath\to\cpython\PCbuild\pythoncore.vcxproj] ---------- components: Build, Windows messages: 217942 nosy: haypo, nikratio, pitrou, zach.ware priority: normal severity: normal stage: needs patch status: open title: Win32 compiler warning in PyBytes_Concat type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 21:19:38 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 19:19:38 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1399316369.6.0.337514651851.issue18314@psf.upfronthosting.co.za> Message-ID: <5367E44A.40700@timgolden.me.uk> Tim Golden added the comment: Thanks, Zach. I was aware that calloc was in the air, but I wasn't sure if it had been committed and I'd delayed on this enough so I thought I'd push for now. We can always revisit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 21:27:15 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 May 2014 19:27:15 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1399318035.3.0.746335675817.issue21393@psf.upfronthosting.co.za> Zachary Ware added the comment: LGTM, Tim. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 21:32:21 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 May 2014 19:32:21 +0000 Subject: [issue21440] Use support.rmtree in test_zipfile In-Reply-To: <1399310530.32.0.0955350320497.issue21440@psf.upfronthosting.co.za> Message-ID: <1399318341.16.0.55447164796.issue21440@psf.upfronthosting.co.za> Zachary Ware added the comment: I don't see the intermittent failures (this machine may well just be too slow). The patch looks good and doesn't cause failures, though, so +1 from me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 21:33:33 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 19:33:33 +0000 Subject: [issue21440] Use support.rmtree in test_zipfile In-Reply-To: <1399318341.16.0.55447164796.issue21440@psf.upfronthosting.co.za> Message-ID: <5367E78D.9000907@timgolden.me.uk> Tim Golden added the comment: Thanks. I get them enough that it stops a test run being particularly useful, especially when I've just touched something (eg unlink) which might conceivably affect something like tarfile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 21:55:57 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 05 May 2014 19:55:57 +0000 Subject: [issue1628987] inspect trouble when source file changes Message-ID: <1399319757.58.0.348965802368.issue1628987@psf.upfronthosting.co.za> Jason R. Coombs added the comment: This issue appears implicated in https://bitbucket.org/pypa/setuptools/issue/201 ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 22:00:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 May 2014 20:00:02 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <3gMw016SQQz7LjR@mail.python.org> Roundup Robot added the comment: New changeset e791a36ab6a2 by Tim Golden in branch 'default': Issue18314 ACKS & NEWS http://hg.python.org/cpython/rev/e791a36ab6a2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 22:01:05 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 20:01:05 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1399320065.1.0.611580559502.issue18314@psf.upfronthosting.co.za> Tim Golden added the comment: Buildbots seem happy. Thanks very much for the patches! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 22:15:39 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 05 May 2014 20:15:39 +0000 Subject: [issue17735] inspect.findsource raises IndexError In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za> Message-ID: <1399320939.62.0.762986190122.issue17735@psf.upfronthosting.co.za> Jason R. Coombs added the comment: This issue appears implicated in https://bitbucket.org/pypa/setuptools/issue/201 ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 22:18:07 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 05 May 2014 20:18:07 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1399321087.85.0.478609720408.issue1218234@psf.upfronthosting.co.za> Jason R. Coombs added the comment: This issue appears implicated in https://bitbucket.org/pypa/setuptools/issue/201 ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 22:19:57 2014 From: report at bugs.python.org (steven Michalske) Date: Mon, 05 May 2014 20:19:57 +0000 Subject: [issue21443] asyncoio logging documentation clarifications. Message-ID: <1399321197.68.0.955361534546.issue21443@psf.upfronthosting.co.za> New submission from steven Michalske: The asyncio documentation should comment on how to mute and increase some of it's logging. 18.5.7.3. Logging The asyncio module logs information with the logging module in the logger 'asyncio'. Adding a bit of text that mentions the following line would be great. """ The default verbosity will include messages at logging.INFO level. To modify the verbosity of asyncio logging add a similar line to your application. `logging.getLogger('asyncio').setLevel(logging.WARNING)` """ Note: While this is clear to active users of the logging module, it is not clear to novices, who want INFO in their applications but not from asyncio. ---------- assignee: docs at python components: Documentation messages: 217952 nosy: docs at python, hardkrash priority: normal severity: normal status: open title: asyncoio logging documentation clarifications. type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 22:20:26 2014 From: report at bugs.python.org (eryksun) Date: Mon, 05 May 2014 20:20:26 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1399321226.11.0.914393934323.issue18314@psf.upfronthosting.co.za> eryksun added the comment: For a junction reparse point, Sysinternals junction.exe shows the "Print Name" and "Substitute Name" are the same and it's not an NT \?? path (i.e. \DosDevices, i.e. \Global??). OTOH, the substitute name does use an NT DosDevices path when I use cmd's mklink or os.symlink to create a directory symbolic link to an absolute path. I modified the patch in a test program to see whether it's really necessary to include the DosDevices path in the substitute name. FYI, it seems to work fine without it, but it also doesn't seem to hurt to include it. Sysinternals Junction http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 22:44:33 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 05 May 2014 20:44:33 +0000 Subject: [issue21316] mark test_devpoll to be meaningful only for Solaris In-Reply-To: <1398019012.76.0.381361357153.issue21316@psf.upfronthosting.co.za> Message-ID: <1399322673.89.0.739949164793.issue21316@psf.upfronthosting.co.za> R. David Murray added the comment: There's no pressing reason to revisit this, but...I think it would be better to say "works only on systems that support devpoll (ie: Solaris and derivatives)" Also, as long as you are changing the try/except, you could use skipUnless(hasattr(select, 'devpoll'), ...) instead of an if. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 5 22:58:01 2014 From: report at bugs.python.org (Tim Golden) Date: Mon, 05 May 2014 20:58:01 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1399321226.11.0.914393934323.issue18314@psf.upfronthosting.co.za> Message-ID: <5367FB59.1030105@timgolden.me.uk> Tim Golden added the comment: Thanks for the research, eryksun. As long as it doesn't hurt let's leave it as is for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 00:30:30 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 05 May 2014 22:30:30 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399329030.42.0.37224932721.issue21435@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is the gdb backtrace. The `gc` variable is equal to NULL. 0x000000000043d254 in finalize_garbage (collectable=0x7fffffffdc40, old=0x8fdae0 ) at Modules/gcmodule.c:788 788 if (!_PyGCHead_FINALIZED(gc) && (gdb) bt #0 0x000000000043d254 in finalize_garbage (collectable=0x7fffffffdc40, old=0x8fdae0 ) at Modules/gcmodule.c:788 #1 0x000000000043dac0 in collect (generation=2, n_collected=0x7fffffffdca8, n_uncollectable=0x7fffffffdcb0, nofail=0) at Modules/gcmodule.c:1009 #2 0x000000000043dffc in collect_with_callback (generation=2) at Modules/gcmodule.c:1128 #3 0x000000000043eda0 in PyGC_Collect () at Modules/gcmodule.c:1604 #4 0x000000000041f332 in Py_Finalize () at Python/pythonrun.c:607 #5 0x000000000043c401 in Py_Main (argc=2, argv=0x980020) at Modules/main.c:788 #6 0x000000000041af96 in main (argc=2, argv=0x7fffffffdfc8) at ./Modules/python.c:69 (gdb) p gc $1 = (PyGC_Head *) 0x0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 01:11:11 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 05 May 2014 23:11:11 +0000 Subject: [issue21444] __len__ can't return big numbers Message-ID: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> New submission from Ram Rachum: I want to use big numbers for length. >>> class A: ... __len__ = lambda self: 10 ** 20 >>> len(A()) Traceback (most recent call last): File "", line 1, in len(A()) OverflowError: cannot fit 'int' into an index-sized integer ---------- components: Interpreter Core messages: 217957 nosy: cool-RR priority: normal severity: normal status: open title: __len__ can't return big numbers versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 01:41:59 2014 From: report at bugs.python.org (Jean-Paul Calderone) Date: Mon, 05 May 2014 23:41:59 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1399333319.09.0.732021861571.issue1218234@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 02:37:12 2014 From: report at bugs.python.org (Christopher Heiny) Date: Tue, 06 May 2014 00:37:12 +0000 Subject: [issue11380] Improve reporting of broken stdout pipe during interpreter shutdown In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za> Message-ID: <1399336632.51.0.0543417887759.issue11380@psf.upfronthosting.co.za> Changes by Christopher Heiny : ---------- nosy: +Christopher.Heiny _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 02:47:34 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 May 2014 00:47:34 +0000 Subject: [issue21444] __len__ can't return big numbers In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399337254.29.0.509713038086.issue21444@psf.upfronthosting.co.za> R. David Murray added the comment: While this is classed as a CPython implementation detail (see issue 15718) it doesn't sound like it is likely to be changed (see issue 2723). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 03:06:15 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 May 2014 01:06:15 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399338375.86.0.223713776515.issue21435@psf.upfronthosting.co.za> Guido van Rossum added the comment: So should we just add if (!gc) break; at the top of the for-loop body? That prevents the crash for me. But why is it needed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 03:25:23 2014 From: report at bugs.python.org (Tim Peters) Date: Tue, 06 May 2014 01:25:23 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399339523.21.0.587590849404.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Guido, that's no good. The outer loop is traversing a doubly-linked circular list, and it should be flatly impossible for gc to ever be NULL - the list structure is insanely damaged if any gc_next or gc_prev field reachable from it is NULL (gc always comes from a gc_next or gc_prev field) I'd wonder whether the `collectable` argument passed in was NULL to begin with, but Antoine's traceback shows that it's not. So, like most crashes in gc, we're just seeing the end symptom of something that went wrong long before. Guarding against gc != NULL is just hiding this particular symptom. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 03:36:19 2014 From: report at bugs.python.org (Tim Peters) Date: Tue, 06 May 2014 01:36:19 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399340179.57.0.591618640093.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Thought question: suppose finalize_garbage() is called with a collectable list all of whose members are in fact going to be destroyed? I don't see how the loop iteration logic could reliably work then. For concreteness, suppose there's only object - A - in the list. It's a circular list so gc starts as A. A is finalized, we see it's refcount is 1, `gc = gc->gc.gc_prev` sets gc to A again, and A is destroyed by the Py_DECREF. We go back to the top of the loop, and then `gc = gc->gc.gc_next` reads up trash (free'd) memory. Or so it seems to me ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 03:49:39 2014 From: report at bugs.python.org (Tim Peters) Date: Tue, 06 May 2014 01:49:39 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399340979.39.0.631421403745.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Noting that in a Windows debug build, at death gc is 0xdbdbdbdb, so we are in reading up free'd memory (0xdb is pymalloc's "dead byte" marker). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 04:08:16 2014 From: report at bugs.python.org (Tim Peters) Date: Tue, 06 May 2014 02:08:16 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399342096.8.0.00217438242555.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Also noting that the loop "looks funny" because it appears never to process the first element in the input list (unless the input list contains only one element). That is, the loop starts by processing the second element in the list, and exits as soon as gc makes it back to the first element in the list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 04:15:31 2014 From: report at bugs.python.org (Tim Peters) Date: Tue, 06 May 2014 02:15:31 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399342531.51.0.275590513887.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Ah, fudge - I think I forgot that these circular lists also have dummy heads, in which case it's A Good Thing "the first element" is skipped, and it should be impossible for one to become physically empty (the dummy header should always survive intact). Never mind ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 04:18:56 2014 From: report at bugs.python.org (Luke Dunstan) Date: Tue, 06 May 2014 02:18:56 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1399342736.72.0.461851692197.issue17797@psf.upfronthosting.co.za> Changes by Luke Dunstan : ---------- nosy: +Luke.Dunstan versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 05:52:33 2014 From: report at bugs.python.org (Steven Barker) Date: Tue, 06 May 2014 03:52:33 +0000 Subject: [issue1234674] filecmp.cmp's "shallow" option Message-ID: <1399348353.21.0.464826829196.issue1234674@psf.upfronthosting.co.za> Steven Barker added the comment: Here's a patch against the default branch that fixes filecmp.cmp's behavior when "shallow" is True, including an update to the module's docs (correcting the previous ambiguity discussed in the 2011 python-dev thread mentioned by Sandro Tosi) and a couple of new tests of files where shallow comparisons should be expected get the answer wrong. The changed behavior is very simple. The lines from Lib/filecmp.py in the original code: if shallow and s1 == s2: return True are changed to: if shallow: return s1 == s2 This presumes answers to the questions asked by Georg Brandl back in 2005 of "No, shallow comparisons never read the file contents" and "No, non-shallow comparisons don't care about mtimes (except for avoiding out of date cache entries)". If we only applied the test changes (not the behavior change) from my patch, one of the new tests would fail, as the current filecmp.cmp code never gives false negatives on comparisons in shallow mode (only false positives). We probably don't want to commit the patch exactly as it stands, because the changed behavior causes several of the previously existing tests to fail. Almost all the dircmp tests fail for me, and the "test_matching" filecmp.cmp test does so intermittently (due to my system sometimes being fast enough at creating the files to beat my filesystem's mtime resolution). The test failures are all because of shallow comparisons between files with the same contents, but (slightly) different mtimes. The new shallow comparison behavior is to say those files are unequal while the old code would fall back on testing the file contents despite the shallow parameter, and so it would return True. The failing tests can probably be updated to either explicitly set the file mtimes with sys.utime (as I do with the files used in the new tests), or we could rewrite some of the setup code to use something like shutil.copy2 to make copies of files while preserving their mtimes. I'm not very familiar with the best practices when it comes to writing unit tests, so I pretty much copied the style of the existing tests in Lib/test/test_filecmp.py (though I've split mine up a bit more). I understand from reading other filecmp bug reports that that test style is considered to be pretty poor, so there's probably room to improve my code as well. I thought I'd post this patch before making an effort at fixing the older tests, in order to get some feedback. I'll be happy to incorporate any suggested improvements! This issue has been open for almost 9 years. Hopefully my patch can help get it moving again towards being fixed! ---------- keywords: +patch versions: +Python 3.5 Added file: http://bugs.python.org/file35159/filecmp_real_shallow.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 06:02:06 2014 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Tue, 06 May 2014 04:02:06 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1399348926.3.0.0496780034541.issue18314@psf.upfronthosting.co.za> Kim Gr?sman added the comment: Thanks for helping me land this! eryksun: interesting, thanks! I seem to remember having problems without the \??\ prefix, but it could have been something else causing it (filling the buffer to DeviceIoControl's satisfaction was... challenging.) I have some ideas for small improvements, and I could try to fold the removal of \??\ into that. Do I just open a new enhancement issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 06:42:33 2014 From: report at bugs.python.org (Chris Rose) Date: Tue, 06 May 2014 04:42:33 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1399351353.43.0.0493806924369.issue20752@psf.upfronthosting.co.za> Chris Rose added the comment: Ping? I'd like to know if the proposed solution passes muster, so that I can get this into ... well, whatever the right revision would be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 06:51:51 2014 From: report at bugs.python.org (Tim Peters) Date: Tue, 06 May 2014 04:51:51 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399351911.26.0.882247594837.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Sorry for the earlier noise. I'm fighting a flu and my head is mush :-( Anyway, this doesn't look obvious. We get to this point: if (Py_REFCNT(op) == 1) { /* op will be destroyed */ gc = gc->gc.gc_prev; } and op is the type object for class B. gc gets set to the previous object, a list. Everything looks fine at this point. But when we get back from: Py_DECREF(op); the list's gc.gc_next field has been overwritten with NULL. That's why gc gets set to NULL on the next trip through the loop. I spaced out stepping through all the type deallocation code, and didn't find exactly when the list's gc_next is overwritten. The list's gc_prev is still fine. Perhaps some code called _PyObject_GC_UNTRACK on the list object (which NULLs out the gc_next pointer but not the gc_prev pointer). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 07:54:48 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 06 May 2014 05:54:48 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1399355688.39.0.206663059452.issue1218234@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +yselivanov versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 08:08:29 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 06 May 2014 06:08:29 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1399356509.84.0.94913346245.issue18314@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yes, new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 09:43:14 2014 From: report at bugs.python.org (Steven Barker) Date: Tue, 06 May 2014 07:43:14 +0000 Subject: [issue21445] Some asserts in test_filecmp have the wrong messages Message-ID: <1399362194.49.0.4974401647.issue21445@psf.upfronthosting.co.za> New submission from Steven Barker: While working on a fix for issue 1234674, I found that the first test method in Lib/test/test_filecmp.py (FileCompareTestCase.test_matching) has switched up messages in its AssertEquals calls. The first two asserts have the message that should belong to the second two, and visa versa. I've prepared a very simple patch that switches around the AssertEquals arguments so that the messages match what is being tested. The behavior checked by the asserts remains exactly the same, only the message printed if an assert fails will be different. The test still passes. If you want to see the wrong message get displayed, the patch I uploaded for issue 1234674 may cause the test edited here to fail intermittently (it depend on whether two files are created in a shorter time than your filesystems's mtime resolution in the setup code). The failures are not affected by this patch, but with it you'll get the right message rather than a wrong one. ---------- components: Tests files: filecmp_test_messages.diff keywords: patch messages: 217970 nosy: Steven.Barker priority: normal severity: normal status: open title: Some asserts in test_filecmp have the wrong messages type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file35160/filecmp_test_messages.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 11:29:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 May 2014 09:29:29 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399368569.65.0.302540090486.issue21435@psf.upfronthosting.co.za> STINNER Victor added the comment: Similar(?) issue #20526: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 11:32:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 May 2014 09:32:48 +0000 Subject: [issue21233] Add *Calloc functions to CPython memory allocation API In-Reply-To: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za> Message-ID: <3gNG1q28fqz7Lmh@mail.python.org> Roundup Robot added the comment: New changeset 358a12f4d4bc by Victor Stinner in branch 'default': Issue #21233: Fix _PyObject_Alloc() when compiled with WITH_VALGRIND defined http://hg.python.org/cpython/rev/358a12f4d4bc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 11:51:40 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 06 May 2014 09:51:40 +0000 Subject: [issue21446] Update reload fixer to use importlib instead of imp Message-ID: <1399369899.96.0.959859751651.issue21446@psf.upfronthosting.co.za> New submission from Berker Peksag: Since imp.reload() was deprecated in issue 18193, the reload fixer (added in issue 11797) needs to be updated to use importlib.reload() instead of imp.reload(). ---------- components: 2to3 (2.x to 3.x conversion tool) files: reload-fixer.diff keywords: patch messages: 217973 nosy: benjamin.peterson, berker.peksag, brett.cannon priority: normal severity: normal stage: patch review status: open title: Update reload fixer to use importlib instead of imp versions: Python 3.5 Added file: http://bugs.python.org/file35161/reload-fixer.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 11:53:11 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 06 May 2014 09:53:11 +0000 Subject: [issue21444] __len__ can't return big numbers In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399369991.91.0.492485320145.issue21444@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 11:57:40 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 06 May 2014 09:57:40 +0000 Subject: [issue21444] __len__ In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399370260.64.0.503516553309.issue21444@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- title: __len__ can't return big numbers -> __len__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 11:57:56 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 06 May 2014 09:57:56 +0000 Subject: [issue21444] __len__ can't return big numbers In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399370276.22.0.88035399706.issue21444@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- title: __len__ -> __len__ can't return big numbers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 11:58:58 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 06 May 2014 09:58:58 +0000 Subject: [issue21444] __len__ can't return big numbers In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399370338.6.0.977204729322.issue21444@psf.upfronthosting.co.za> Mark Dickinson added the comment: Whoops; sorry -- accidental title change by typing `__len__` into something that wasn't the search box. Stupid fingers... (I suspect this issue is a duplicate of an existing issue.) ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 13:16:11 2014 From: report at bugs.python.org (eryksun) Date: Tue, 06 May 2014 11:16:11 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1399374971.86.0.621925095743.issue18314@psf.upfronthosting.co.za> eryksun added the comment: Nevermind, strike "seems to work"; it doesn't work without the \?? prefix. I stupidly assumed the DeviceIoControl call would validate the substitute name. Of course it doesn't; it happily creates a broken junction. Opening the junction with CreateFile fails with either ERROR_INVALID_REPARSE_DATA or ERROR_CANT_RESOLVE_FILENAME. Sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 13:24:20 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 11:24:20 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1399374971.86.0.621925095743.issue18314@psf.upfronthosting.co.za> Message-ID: <5368C660.2090406@timgolden.me.uk> Tim Golden added the comment: Thanks, eryksun: failed experiments are still useful data for future reference! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 14:28:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 May 2014 12:28:42 +0000 Subject: [issue21440] Use support.rmtree in test_zipfile In-Reply-To: <1399310530.32.0.0955350320497.issue21440@psf.upfronthosting.co.za> Message-ID: <3gNKwp17Q5z7Ljb@mail.python.org> Roundup Robot added the comment: New changeset 4ebf97299b18 by Tim Golden in branch 'default': Issue21440 Use support.rmtree in test_zipfile & test_tarfile http://hg.python.org/cpython/rev/4ebf97299b18 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 14:30:01 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 May 2014 12:30:01 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <3gNKyK0jMdz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset 2b18f6c37a68 by Tim Golden in branch 'default': Issue21393 Use CryptReleaseContext to release Crypt handle on Windows http://hg.python.org/cpython/rev/2b18f6c37a68 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 14:57:28 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 06 May 2014 12:57:28 +0000 Subject: [issue21264] test_compileall fails to build in the installed location In-Reply-To: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za> Message-ID: <1399381048.04.0.559283727709.issue21264@psf.upfronthosting.co.za> Matthias Klose added the comment: what happens here: PYTHONPATH=$(pwd) python3.4 -X faulthandler -S -m compileall Skipping current directory Listing '/home/packages/python/3.4/x'... Compiling '/home/packages/python/3.4/x/foo.py'... Listing '/usr/lib/python3.4/'... Listing '/usr/lib/python3.4/plat-x86_64-linux-gnu'... Listing '/usr/lib/python3.4/lib-dynload'... so even when overwriting PYTHONPATH, the standard locations are searched and tried to compile, which fails when these are read only. Is this behaviour expected? The tests itself can be fixed by passing the the test directory as an argument, as done in other tests too. ---------- components: +Tests keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file35162/issue21264.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 15:21:16 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 06 May 2014 13:21:16 +0000 Subject: [issue21442] Win32 compiler warning in PyBytes_Concat In-Reply-To: <1399317412.48.0.97409893432.issue21442@psf.upfronthosting.co.za> Message-ID: <1399382476.06.0.717453214443.issue21442@psf.upfronthosting.co.za> Zachary Ware added the comment: Declaring oldsize as Py_ssize_t instead of size_t at Objects/bytesobject.c:2812 takes care of the warning, but I'm not comfortable saying that's a correct change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 15:21:35 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 06 May 2014 13:21:35 +0000 Subject: [issue21442] Win32 compiler warning in PyBytes_Concat In-Reply-To: <1399317412.48.0.97409893432.issue21442@psf.upfronthosting.co.za> Message-ID: <1399382495.83.0.306657799621.issue21442@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 15:29:28 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 13:29:28 +0000 Subject: [issue21393] Python/random.c: close hCryptProv at exit In-Reply-To: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za> Message-ID: <1399382968.49.0.196216222673.issue21393@psf.upfronthosting.co.za> Tim Golden added the comment: Use CryptReleaseContext to release Crypt handle on Windows ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 15:30:15 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 13:30:15 +0000 Subject: [issue21440] Use support.rmtree in test_zipfile In-Reply-To: <1399310530.32.0.0955350320497.issue21440@psf.upfronthosting.co.za> Message-ID: <1399383015.22.0.355203620639.issue21440@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 15:44:37 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 May 2014 13:44:37 +0000 Subject: [issue20752] Difflib should provide the option of overriding the SequenceMatcher In-Reply-To: <1393193816.17.0.662615840954.issue20752@psf.upfronthosting.co.za> Message-ID: <1399383877.47.0.128118712609.issue20752@psf.upfronthosting.co.za> R. David Murray added the comment: Well, it would be 3.5, so there's plenty of time yet. We are hoping for an answer from Tim Peters, but if we don't get one someone else will review it as time allows. Pinging the issue like this was good; do it again in another month if there's no further action before then. (NB: we're working on improving our workflow so that issues like this don't get lost, but it will take time for those improvements to show up...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 15:46:34 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 May 2014 13:46:34 +0000 Subject: [issue21444] __len__ can't return big numbers In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399383994.49.0.853028851669.issue21444@psf.upfronthosting.co.za> R. David Murray added the comment: Mark: I thought it was too, but the two I noted were the closest I could find. Maybe you'll find something even more on point :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 16:08:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 May 2014 14:08:21 +0000 Subject: [issue21366] Document that return in finally overwrites prev value In-Reply-To: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za> Message-ID: <3gNN7n0d3Wz7LtY@mail.python.org> Roundup Robot added the comment: New changeset faaa8d569664 by Zachary Ware in branch '3.4': Issue #21366: Document the fact that ``return`` in a ``finally`` clause http://hg.python.org/cpython/rev/faaa8d569664 New changeset 685f92aad1dc by Zachary Ware in branch 'default': Issue #21366: Document the fact that ``return`` in a ``finally`` clause http://hg.python.org/cpython/rev/685f92aad1dc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 16:10:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 May 2014 14:10:28 +0000 Subject: [issue21366] Document that return in finally overwrites prev value In-Reply-To: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za> Message-ID: <3gNNBC4tZlzRGY@mail.python.org> Roundup Robot added the comment: New changeset 7fabe3652ee0 by Zachary Ware in branch '2.7': Issue #21366: Document the fact that ``return`` in a ``finally`` clause http://hg.python.org/cpython/rev/7fabe3652ee0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 16:12:14 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 06 May 2014 14:12:14 +0000 Subject: [issue21366] Document that return in finally overwrites prev value In-Reply-To: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za> Message-ID: <1399385534.7.0.731432491091.issue21366@psf.upfronthosting.co.za> Zachary Ware added the comment: Done. Thanks pointing out just how redundant that parenthetical was (I don't know how that slipped through my brain...), David. And thank you Jon for the report! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 16:24:18 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 May 2014 14:24:18 +0000 Subject: [issue21446] Update reload fixer to use importlib instead of imp In-Reply-To: <1399369899.96.0.959859751651.issue21446@psf.upfronthosting.co.za> Message-ID: <1399386258.64.0.767578515389.issue21446@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't think that's necessarily obvious since that will make your code tied to Python 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 16:59:41 2014 From: report at bugs.python.org (akira) Date: Tue, 06 May 2014 14:59:41 +0000 Subject: [issue21444] __len__ can't return big numbers In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399388381.19.0.867279887192.issue21444@psf.upfronthosting.co.za> akira added the comment: If `len()` signature can't be changed to return Python int objects (unlimited) then the OverflowError may contain the actual `.length` property instead (based on msg66459 by Antoine Pitrou) operator.length(): def length(sized): """Return the true (possibly large) length of `sized` object. It is equivalent to len(sized) if len doesn't raise OverflowError i.e., if the length is less than sys.maxsize on CPython; otherwise return OverflowError.length attribute """ try: return len(sized) except OverflowError as e: return e.length ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 17:20:16 2014 From: report at bugs.python.org (=?utf-8?q?Andreas_G=C3=A4er?=) Date: Tue, 06 May 2014 15:20:16 +0000 Subject: [issue13702] relative symlinks in tarfile.extract broken (windows) In-Reply-To: <1325608963.69.0.695216553795.issue13702@psf.upfronthosting.co.za> Message-ID: <1399389616.09.0.375078108813.issue13702@psf.upfronthosting.co.za> Andreas G?er added the comment: Is there any progress to the question if the problem should be fixed in os.symlink or in tarfile? Because this currently seems to break installing source packages that contain symlinks with pip under Windows. Try: "pip install networkx==1.8.1" for example ---------- nosy: +Andreas.G?er _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 17:33:58 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 06 May 2014 15:33:58 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1399390438.24.0.363346408692.issue1218234@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, I'll take a look at the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 17:57:13 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 May 2014 15:57:13 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1399391833.14.0.20703347136.issue1218234@psf.upfronthosting.co.za> R. David Murray added the comment: Note that there has never been a strict correspondence between linecache/getsource, the module in memory, and the code on disk. If the file is changed before a traceback is generated, for example, you will get the new source. That doesn't mean fixing the reload case is wrong, it's just something to keep in mind. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 18:11:58 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 16:11:58 +0000 Subject: [issue21442] Win32 compiler warning in PyBytes_Concat In-Reply-To: <1399317412.48.0.97409893432.issue21442@psf.upfronthosting.co.za> Message-ID: <1399392718.35.0.614014714768.issue21442@psf.upfronthosting.co.za> Tim Golden added the comment: Well PyBytes_GET_SIZE is documented as returning a Py_ssize_t so I'd say it's perfectly valid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 18:43:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 May 2014 16:43:11 +0000 Subject: [issue21442] Win32 compiler warning in PyBytes_Concat In-Reply-To: <1399317412.48.0.97409893432.issue21442@psf.upfronthosting.co.za> Message-ID: <3gNRZQ41Kpz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset 6234f4caba57 by Zachary Ware in branch 'default': Issue #21442: Fix MSVC compiler warning introduced by issue21377. http://hg.python.org/cpython/rev/6234f4caba57 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 18:43:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 May 2014 16:43:11 +0000 Subject: [issue21377] PyBytes_Concat could try to concat in-place In-Reply-To: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za> Message-ID: <3gNRZR242Gz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset 6234f4caba57 by Zachary Ware in branch 'default': Issue #21442: Fix MSVC compiler warning introduced by issue21377. http://hg.python.org/cpython/rev/6234f4caba57 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 18:45:01 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 06 May 2014 16:45:01 +0000 Subject: [issue21442] Win32 compiler warning in PyBytes_Concat In-Reply-To: <1399317412.48.0.97409893432.issue21442@psf.upfronthosting.co.za> Message-ID: <1399394701.06.0.227409481502.issue21442@psf.upfronthosting.co.za> Zachary Ware added the comment: I should have looked a little harder, thanks Tim! ---------- assignee: -> zach.ware resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 18:59:17 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 16:59:17 +0000 Subject: [issue21382] Signal module doesnt raises ValueError Exception In-Reply-To: <1398759436.39.0.420418396293.issue21382@psf.upfronthosting.co.za> Message-ID: <1399395557.07.0.990988116158.issue21382@psf.upfronthosting.co.za> Tim Golden added the comment: To be honest I can't get excited about this one. The only sensible change is to remove the rather specific comment about ValueError and just leave the fact that only certain signals are valid. Because the C code defines module-level constants on the basis of whether the platform C-lib defines them, different platforms will have different module attributes. It would be unusual for us to list all the combinations. Adding Brian Curtin as he made the original change. ---------- nosy: +brian.curtin, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 19:13:04 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 17:13:04 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1399396384.82.0.627105548498.issue19643@psf.upfronthosting.co.za> Tim Golden added the comment: Ok, so to move this forward we have essentially two proposals: 1) Add a remove_readonly flag 2) Add a doc example which shows how to use the onerror handler to remove a recalcitrant file. I'm -0.5 on (1) because it feels like Windows-specific clutter; and +0 on (2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 19:19:58 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 17:19:58 +0000 Subject: [issue20758] mimetypes initialization order In-Reply-To: <1393233038.02.0.945903372957.issue20758@psf.upfronthosting.co.za> Message-ID: <1399396798.11.0.148216157517.issue20758@psf.upfronthosting.co.za> Tim Golden added the comment: Fixed by issue9291 ---------- resolution: -> duplicate stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 19:22:51 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 17:22:51 +0000 Subject: [issue1528593] Printing: No print dialog or page setup Message-ID: <1399396971.47.0.742122279336.issue1528593@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- nosy: -tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 20:19:18 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 06 May 2014 18:19:18 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1399400358.81.0.728710738857.issue21423@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +bquinlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 20:28:19 2014 From: report at bugs.python.org (Ryder Lewis) Date: Tue, 06 May 2014 18:28:19 +0000 Subject: [issue21447] Intermittent asyncio.open_connection / futures.InvalidStateError Message-ID: <1399400899.35.0.6772968076.issue21447@psf.upfronthosting.co.za> New submission from Ryder Lewis: Intermittently, when using asyncio.wait_for() with asyncio.open_connection() to cancel the open_connection() task after a timeout period, an asyncio.futures.InvalidStateError is raised. It seems to be a race condition, if the open_connection() call succeeds roughly at the same time as the timeout. In order to recreate this issue, I used a slightly-modified version of the example at https://docs.python.org/3.4/library/asyncio-stream.html?highlight=open_connection#example ==== example.py ==== import asyncio import urllib.parse import sys @asyncio.coroutine def print_http_headers(url, timeout): url = urllib.parse.urlsplit(url) try: reader, writer = yield from asyncio.wait_for(asyncio.open_connection(url.hostname, 80), timeout) except asyncio.TimeoutError: print('Timed out with {}-second timeout'.format(timeout)) return query = ('HEAD {url.path} HTTP/1.0\r\n' 'Host: {url.hostname}\r\n' '\r\n').format(url=url) writer.write(query.encode('latin-1')) while True: line = yield from reader.readline() if not line: break line = line.decode('latin1').rstrip() if line: print('HTTP header> %s' % line) print('Success with {}-second timeout'.format(timeout)) url = sys.argv[1] loop = asyncio.get_event_loop() for timeout in range(5, 0, -1): task = asyncio.async(print_http_headers(url, timeout/100)) loop.run_until_complete(task) loop.close() ==== Output of "./example.py http://www.yahoo.com/" after running multiple times ==== HTTP header> HTTP/1.0 301 Redirect HTTP header> Date: Tue, 06 May 2014 18:07:43 GMT HTTP header> Connection: close HTTP header> Via: http/1.1 ir12.fp.ne1.yahoo.com (ApacheTrafficServer/4.0.2) HTTP header> Server: ATS HTTP header> Cache-Control: no-store HTTP header> Content-Type: text/html; charset=utf-8 HTTP header> Content-Language: en HTTP header> Location: https://www.yahoo.com/ HTTP header> Content-Length: 214 Success with 0.04-second timeout Timed out with 0.03-second timeout Timed out with 0.02-second timeout Exception in callback >(None,) handle: Handle(>, (None,)) Traceback (most recent call last): File "/opt/python3/lib/python3.4/asyncio/events.py", line 39, in _run self._callback(*self._args) File "/opt/python3/lib/python3.4/asyncio/futures.py", line 298, in set_result raise InvalidStateError('{}: {!r}'.format(self._state, self)) asyncio.futures.InvalidStateError: CANCELLED: Future Timed out with 0.01-second timeout ---------- components: IO messages: 217999 nosy: ryder.lewis priority: normal severity: normal status: open title: Intermittent asyncio.open_connection / futures.InvalidStateError type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 20:29:15 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 06 May 2014 18:29:15 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399400955.86.0.0721727630214.issue21121@psf.upfronthosting.co.za> Ned Deily added the comment: I don't have a *really* strong opinion against it. It's just that I find the current plethora of configuration flags to be non-intuitive and confusing (and there are plenty of open issues agreeing with that sentiment) and adding another with the name CFLAGS_NODIST doesn't help. But, again, short of someone going in and doing a radical simplification of the whole configure.ac, Makefile.pre.in, and setup.py tangle, I guess exposing one more variable isn't going to make matters that much worse than they already are and it does solve a real problem. (Sorry to vent on your patch, Stefan.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 20:42:24 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 06 May 2014 18:42:24 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399401744.25.0.401557450377.issue21121@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I share Ned's sentiment on this. The amount of information exposed through sysconfig is too large as it is because a lot of that information is only useful during the built of python itself. I'm pretty sure that have been patches in the past where users tried to use some of those variables and were surprised they didn't work for an installed python. Anyways, the patch looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 20:44:53 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 06 May 2014 18:44:53 +0000 Subject: [issue21444] __len__ can't return big numbers In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399401893.1.0.0470532842839.issue21444@psf.upfronthosting.co.za> Mark Dickinson added the comment: That's pretty evil. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:00:33 2014 From: report at bugs.python.org (Ryder Lewis) Date: Tue, 06 May 2014 19:00:33 +0000 Subject: [issue21447] Intermittent asyncio.open_connection / futures.InvalidStateError In-Reply-To: <1399400899.35.0.6772968076.issue21447@psf.upfronthosting.co.za> Message-ID: <1399402833.08.0.205811412868.issue21447@psf.upfronthosting.co.za> Ryder Lewis added the comment: Another run raised a different exception, again running ./example.py http://www.yahoo.com/ Timed out with 0.05-second timeout HTTP header> HTTP/1.0 301 Redirect HTTP header> Date: Tue, 06 May 2014 18:58:53 GMT HTTP header> Connection: close HTTP header> Via: http/1.1 ir38.fp.bf1.yahoo.com (ApacheTrafficServer/4.0.2) HTTP header> Server: ATS HTTP header> Cache-Control: no-store HTTP header> Content-Type: text/html; charset=utf-8 HTTP header> Content-Language: en HTTP header> Location: https://www.yahoo.com/ HTTP header> Content-Length: 214 Success with 0.04-second timeout HTTP header> HTTP/1.0 301 Redirect HTTP header> Date: Tue, 06 May 2014 18:58:53 GMT HTTP header> Connection: close HTTP header> Via: http/1.1 ir45.fp.bf1.yahoo.com (ApacheTrafficServer/4.0.2) HTTP header> Server: ATS HTTP header> Cache-Control: no-store HTTP header> Content-Type: text/html; charset=utf-8 HTTP header> Content-Language: en HTTP header> Location: https://www.yahoo.com/ HTTP header> Content-Length: 214 Success with 0.03-second timeout Timed out with 0.02-second timeout Timed out with 0.01-second timeout exception calling callback for Traceback (most recent call last): File "/opt/python3/lib/python3.4/concurrent/futures/_base.py", line 297, in _invoke_callbacks callback(self) File "/opt/python3/lib/python3.4/asyncio/futures.py", line 370, in new_future._copy_state, fut)) File "/opt/python3/lib/python3.4/asyncio/base_events.py", line 285, in call_soon_threadsafe self._write_to_self() File "/opt/python3/lib/python3.4/asyncio/selector_events.py", line 91, in _write_to_self self._csock.send(b'x') AttributeError: 'NoneType' object has no attribute 'send' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:04:20 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 19:04:20 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399403060.42.0.00168177223749.issue20737@psf.upfronthosting.co.za> Tim Golden added the comment: In thread_nt.h:EnterNonRecursiveMutex the millisecond version (here: 2148000) of the seconds you passed in are converted to microseconds (so: 2148000000). This is then passed to condvar.h:PyCOND_TIMEDWAIT which expects a long, whose 32-bit limit is 2147483647. So it wraps around and becomes -2146967296. That value is then divided by 1000 once again to become milliseconds (-2146967) and passed to condvar.h:_PyCOND_WAIT_MS which expects a DWORD, which is a synonym for an unsigned long. Thus the signed value becomes an unsigned 4292820329. Which then passed in as the millisecond timeout to WaitForSingleObjectEx. So that's what's happening; but I'm really not sure at what stage a change should be made. It looks to me as if PyCOND_TIMEDWAIT should be accepting something more than a long, but I'm really not competent to assess the impact of such a change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:09:47 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 19:09:47 +0000 Subject: [issue20384] os.open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1399403387.36.0.216383768121.issue20384@psf.upfronthosting.co.za> Tim Golden added the comment: Fixed in 3.4 and later; 3.3 is no longer accepting patches ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:15:01 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 19:15:01 +0000 Subject: [issue5717] os.defpath includes unix /bin on windows In-Reply-To: <1239116630.78.0.64068842306.issue5717@psf.upfronthosting.co.za> Message-ID: <1399403701.45.0.830075188333.issue5717@psf.upfronthosting.co.za> Tim Golden added the comment: Closing, as no-one's come back after my -0 for 6 months. ---------- resolution: -> wont fix stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:18:26 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 19:18:26 +0000 Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of os.popen In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za> Message-ID: <1399403906.57.0.170339458622.issue10752@psf.upfronthosting.co.za> Tim Golden added the comment: Zach -- you've done most of the work on the VS projects lately. Would you mind having a look at this one to see if it's still relevant, please? ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:20:13 2014 From: report at bugs.python.org (jader fabiano) Date: Tue, 06 May 2014 19:20:13 +0000 Subject: [issue21448] Email Parser use 100% CPU Message-ID: <1399404013.42.0.0957567548326.issue21448@psf.upfronthosting.co.za> New submission from jader fabiano: Use email.parser to catch the mime's header,when a mime has attachments the process is consuming 100% of the CPU. And It can take until four minutes to finish the header parser. ---------- components: email messages: 218008 nosy: barry, jader.fabiano, r.david.murray priority: normal severity: normal status: open title: Email Parser use 100% CPU type: performance versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:30:39 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 06 May 2014 19:30:39 +0000 Subject: [issue13030] Be more generic when identifying the Windows main dir in installation doc In-Reply-To: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za> Message-ID: <1399404639.22.0.163709916471.issue13030@psf.upfronthosting.co.za> Tim Golden added the comment: This is essentially superseded now by the work done over on distutils-sig and by the PyPA. (Which has included considering the differeng terminology of installation vs other paths on Windows vs Unix). ---------- resolution: -> wont fix stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:31:23 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 May 2014 19:31:23 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399404013.42.0.0957567548326.issue21448@psf.upfronthosting.co.za> Message-ID: <1399404683.91.0.30453729315.issue21448@psf.upfronthosting.co.za> R. David Murray added the comment: Can you provide more details on how to reproduce the problem, please? For example, a sample message and the sequence of python calls you use to parse it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:45:51 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 06 May 2014 19:45:51 +0000 Subject: [issue21443] asyncio logging documentation clarifications In-Reply-To: <1399321197.68.0.955361534546.issue21443@psf.upfronthosting.co.za> Message-ID: <1399405551.75.0.92976166408.issue21443@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: -> needs patch title: asyncoio logging documentation clarifications. -> asyncio logging documentation clarifications _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:51:02 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 06 May 2014 19:51:02 +0000 Subject: [issue21447] Intermittent asyncio.open_connection / futures.InvalidStateError In-Reply-To: <1399400899.35.0.6772968076.issue21447@psf.upfronthosting.co.za> Message-ID: <1399405862.56.0.31035534202.issue21447@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:51:14 2014 From: report at bugs.python.org (jader fabiano) Date: Tue, 06 May 2014 19:51:14 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399404683.91.0.30453729315.issue21448@psf.upfronthosting.co.za> Message-ID: jader fabiano added the comment: I am openning a file and I am passing the File Descriptor to this function Parse().parse( fp ): This file has two attachments Example: self.fileDescriptor( file, 'rb') headers = Parser().parse(self.fileDescriptor ) #Here the process starts to consume 100% of the CPU and It takes around four minutes to go the next line. print 'Headers OK' The File's size is 12M Thanks. 2014-05-06 16:31 GMT-03:00 R. David Murray : > > R. David Murray added the comment: > > Can you provide more details on how to reproduce the problem, please? For > example, a sample message and the sequence of python calls you use to parse > it. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 21:53:49 2014 From: report at bugs.python.org (jader fabiano) Date: Tue, 06 May 2014 19:53:49 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: Message-ID: jader fabiano added the comment: Sorry! Correct line self.fileDescriptor = open( file, 'rb') 2014-05-06 16:51 GMT-03:00 jader fabiano : > > jader fabiano added the comment: > > I am openning a file and I am passing the File Descriptor to this function > Parse().parse( fp ): > This file has two attachments > Example: > self.fileDescriptor( file, 'rb') > headers = Parser().parse(self.fileDescriptor ) > #Here the process starts to consume 100% of the CPU and It takes around > four minutes to go the next line. > print 'Headers OK' > > The File's size is 12M > > Thanks. > > 2014-05-06 16:31 GMT-03:00 R. David Murray : > > > > > R. David Murray added the comment: > > > > Can you provide more details on how to reproduce the problem, please? > For > > example, a sample message and the sequence of python calls you use to > parse > > it. > > > > ---------- > > > > _______________________________________ > > Python tracker > > > > _______________________________________ > > > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 22:03:51 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 May 2014 20:03:51 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399404013.42.0.0957567548326.issue21448@psf.upfronthosting.co.za> Message-ID: <1399406631.38.0.640618573571.issue21448@psf.upfronthosting.co.za> R. David Murray added the comment: We'll need the data file as well. This is going to be a data-dependent issue. With a 12MB body, I'm guessing there's some decoding pathology involved, which may or may not have been already fixed in python3. To confirm this you could use HeaderParser instead of Parser, which won't try to decode the body. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 22:15:43 2014 From: report at bugs.python.org (jader fabiano) Date: Tue, 06 May 2014 20:15:43 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399406631.38.0.640618573571.issue21448@psf.upfronthosting.co.za> Message-ID: jader fabiano added the comment: No, The file has 12Mb, because It has attachments. I am going to show an example. You can use a file thus: Date: Tue, May 10:27:17 6 -0300 (BRT) From: email at email.com.br MIME-Version: 1.0 To: example at example.com Subject:example Content-Type: multipart/mixed; boundary=24f59adc-d522-11e3-a531-00265a0f1361 --24f59adc-d522-11e3-a531-00265a0f1361 Content-Type: multipart/alternative; boundary=24f59a28-d522-11e3-a531-00265a0f1361 --24f59a28-d522-11e3-a531-00265a0f1361^M Content-Type: text/html; charset="iso-8859-1" ^M Content-Transfer-Encoding: 7bit
Test example --24f59a28-d522-11e3-a531-00265a0f1361-- --24f59adc-d522-11e3-a531-00265a0f1361 Content-Type: application/pdf; name=Example.pdf Content-Disposition: attachment; filename=Example.pdf Content-Transfer-Encoding: base64 attachment content in base64...... --24f59adc-d522-11e3-a531-00265a0f1361-- 2014-05-06 17:03 GMT-03:00 R. David Murray : > > R. David Murray added the comment: > > We'll need the data file as well. This is going to be a data-dependent > issue. With a 12MB body, I'm guessing there's some decoding pathology > involved, which may or may not have been already fixed in python3. > > To confirm this you could use HeaderParser instead of Parser, which won't > try to decode the body. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 22:23:14 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 May 2014 20:23:14 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399404013.42.0.0957567548326.issue21448@psf.upfronthosting.co.za> Message-ID: <1399407794.19.0.998076700988.issue21448@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I was using RFC-speak. A message is divided into 'headers' and 'body', and all of the attachments are part of the body in RFC terms. But think of it as 'initial headers' and 'everything else'. Please either attach the full file, and/or try your test using HeaderParser and report the results. However, it occurs to me that the attachments aren't decoded until you retrieve them, so whatever is going on it must be something other than a decoding issue. Nevertheless, Parser actually parses the whole message, attachments included, so we'll need the actual message in order to reproduce this (unless you can reproduce it with a smaller message). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 22:25:31 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 May 2014 20:25:31 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399404013.42.0.0957567548326.issue21448@psf.upfronthosting.co.za> Message-ID: <1399407931.08.0.102958118766.issue21448@psf.upfronthosting.co.za> R. David Murray added the comment: Also to clarify: HeaderParser will *also* read the entire message, it just won't look for MIME attachments in the 'everything else', it will just treat the 'everything else' as arbitrary data and record it as the payload of the top level Message object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 22:29:55 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 06 May 2014 20:29:55 +0000 Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of os.popen In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za> Message-ID: <1399408195.91.0.612109341827.issue10752@psf.upfronthosting.co.za> Zachary Ware added the comment: Still relevant, insofar as having Perl available is relevant. That is, you only need Perl available if you're using vanilla OpenSSL sources, not if you're using sources pulled from svn.python.org (which most people should do, I would think). I have never had a problem with build_ssl.py finding Perl, though. That said, I don't see any harm in properly updating from os.popen to subprocess. See also issue21141, which aims to make explicit that Perl is only needed to doctor up vanilla OpenSSL source. ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 22:53:53 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 May 2014 20:53:53 +0000 Subject: [issue21447] Intermittent asyncio.open_connection / futures.InvalidStateError In-Reply-To: <1399400899.35.0.6772968076.issue21447@psf.upfronthosting.co.za> Message-ID: <1399409633.14.0.593693411625.issue21447@psf.upfronthosting.co.za> Guido van Rossum added the comment: The second error is easy to explain and fix: it's a race condition between the OS thread used to call getaddrinfo() and the main thread. The method _write_to_self() in selector_events.py is hopelessly naive. It should probably become something like this: def _write_to_self(self): csock = self._csock if csock is not None: try: self._csock.send(b'x') except OSError: pass It is possible that the main thread closes csock at any time, and calling send() on a closed socket will raise OSError with errno=9 (EBADF). Fortunately this is because close() sets the fd to -1; so there is no worry about reuse of the fd. I will investigate the first traceback next. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 23:07:20 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 06 May 2014 21:07:20 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1399410440.78.0.380990049989.issue21423@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Do you mean ProcessPoolExecutor? Thread based pools don't involve serialization. It would be good for ThreadPoolExecutor to have it as well, to make it easier to switch between executors, but only ProcessPoolExecutor is suffering from serialization overhead. Threads share the same memory space after all; references to data get passed directly, though you might choose to copy.copy or copy.deepcopy a root data "template" so each thread has its own unique copy that it can mutate. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 23:17:01 2014 From: report at bugs.python.org (Andreas van Cranenburgh) Date: Tue, 06 May 2014 21:17:01 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1399411021.81.0.840194239824.issue21423@psf.upfronthosting.co.za> Andreas van Cranenburgh added the comment: Yes I did mean ProcessPoolExecutor, but indeed, it's good to have for threads as well. I could try to make a patch if it is likely that it would be accepted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 23:17:30 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 06 May 2014 21:17:30 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1399411050.19.0.827833827845.issue19643@psf.upfronthosting.co.za> Zachary Ware added the comment: I'm good with just adding an example to the docs, along the lines of Paul's del_rw. I think it would be better to use a more conservative example though, something like: def readonly_handler(rm_func, path, exc_info): if issubclass(exc_info[0], PermissionError) and exc_info[1].winerror == 5: os.chmod(path, stat.S_IWRITE) return rm_func(path) raise exc_info[1] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 23:35:24 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 06 May 2014 21:35:24 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual Message-ID: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> New submission from Josh Rosenberg: _PyUnicode_CompareWithId is used exclusively for equality comparisons (after all, identifiers aren't really sortable in a meaningful way; they're isolated values, not a continuum). But because _PyUnicode_CompareWithId maintains the general comparison behavior, not just ==/!=, it serves little purpose; while it checks the return of _PyUnicode_FromId, none of its callers check for failure anyway, so every use could just as well have been: PyUnicode_Compare(left, _PyUnicode_FromId(right)); I've attached a patch that replaces _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual, that: 1. Only check equality vs. inequality 2. Can optimize for the case where left is an interned string by performing direct pointer comparison 3. Even when left is not interned, it can use the optimized unicode_compare_eq worker function instead of the slower generalized unicode_compare function I've replaced all the uses of the old function I could find, and all unit tests pass. I don't expect to see any meaningful speed ups as a result of the change (the most commonly traversed code that would benefit appears to be the code that creates new classes, and the code that creates reprs for objects), but the goal here is not immediate speed ups, but enabling future speed ups. I am looking into writing a PyDict_GetItem fastpath for looking up identifiers (that would remove the need to perform memory comparisons when the dictionary, as in keyword argument passing, is usually composed of interned keys), possibly in combination with making an identifier based version of PyArg_ParseTupleAndKeywords; with ArgumentClinic, it might become practical to swap in a new argument parser without having to manually change thousands of lines of code, and one of the simplest ways to improve speed would be to remove the overhead of constantly constructing, hashing, and comparing the same keyword strings every time a C function is called. Adding haypo as nosy since he created the original function in #19512. ---------- files: comparewithidequals.patch keywords: patch messages: 218022 nosy: haypo, josh.rosenberg priority: normal severity: normal status: open title: Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual Added file: http://bugs.python.org/file35163/comparewithidequals.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 23:45:01 2014 From: report at bugs.python.org (Paul Moore) Date: Tue, 06 May 2014 21:45:01 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1399412701.27.0.286119607174.issue19643@psf.upfronthosting.co.za> Paul Moore added the comment: Checking the exact error could be a bit fragile. I have a feeling I recently saw an issue somewhere with code that stopped working on Python 3.4 because the precise error raised for a read-only file changed. I don't recall where the issue was, unfortunately. It's also worth noting that trapping too broad a set of errors won't actually matter much, because the retry will simply fail again if the actual problem wasn't a read-only file... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 23:45:03 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 06 May 2014 21:45:03 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1399412703.2.0.51726848158.issue21423@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I'm not a core developer, but writing the patch is usually considered helpful. Two notes: 1. Make sure to write unit tests for any new behavior 2. I'd suggest making any such argument keyword-only; if we move closer to the Java executor model, that means having a lot of options, the majority of which would be left as the default by users. Binding the API to a particular argument order is sub-optimal (it makes it even harder to deprecate arguments for instance), so enforcing keyword only behavior ensures users can't write call lines that take dependencies on argument ordering. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 6 23:47:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 May 2014 21:47:23 +0000 Subject: [issue21447] Intermittent asyncio.open_connection / futures.InvalidStateError In-Reply-To: <1399400899.35.0.6772968076.issue21447@psf.upfronthosting.co.za> Message-ID: <3gNZKR0gmbz7LjM@mail.python.org> Roundup Robot added the comment: New changeset afe8c4bd3230 by Guido van Rossum in branch '3.4': asyncio: Fix the second half of issue #21447: race in _write_to_self(). http://hg.python.org/cpython/rev/afe8c4bd3230 New changeset c0538334f4df by Guido van Rossum in branch 'default': Merge 3.4->default: asyncio: Fix the second half of issue #21447: race in _write_to_self(). http://hg.python.org/cpython/rev/c0538334f4df ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 00:01:28 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 06 May 2014 22:01:28 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <1399413688.96.0.767839386604.issue17752@psf.upfronthosting.co.za> Matthias Klose added the comment: so the issue here is that -L -o is passed to the compiler, and -o is interpreted as the library dir, and as an input file. To robustify, change distutils/tests/support.py to not include empty directory names. To fix, change configure.ac (RUNPATH) not to unconditionally end the environment variables with an empty directory. adding Ronald, Darwin is the only platform having quotes around this. Is this really needed/wanted? ---------- keywords: +patch nosy: +hynek, ned.deily, ronaldoussoren Added file: http://bugs.python.org/file35164/issue17752.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 00:02:24 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 06 May 2014 22:02:24 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <1399413744.0.0.0797538051622.issue17752@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 00:13:27 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 May 2014 22:13:27 +0000 Subject: [issue21447] Intermittent asyncio.open_connection / futures.InvalidStateError In-Reply-To: <1399400899.35.0.6772968076.issue21447@psf.upfronthosting.co.za> Message-ID: <1399414407.22.0.211747679168.issue21447@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm a little closer to understanding the first (more common) traceback. I can repro it by running your demo program in a loop -- it may take a while but occasionally I do get the same InvalidStateError. This appears to be an example of the problem speculated about in message #5 of https://code.google.com/p/tulip/issues/detail?id=58. In order to find out which occurrence of call_later(future.set_result, None) is causing this, I replaced all of them (about half a dozen) with an equivalent lambda -- the lambda shows up in the traceback, unlike the location where call_soon() is called. In this particular example, it is the last line of _SelectorSocketTransport.__init__() in selector_events.py (line 446). I suspect there are other places where a similar problem can occur. I still have to think more about how to fix this (without changing set_result() to always ignore a cancelled Future -- such a change would mask certain errors that I find important to catch). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 01:22:19 2014 From: report at bugs.python.org (Tim Peters) Date: Tue, 06 May 2014 23:22:19 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399418539.12.0.327646203749.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: A bit more info: recall that, when deleting a type object (for class B), the previous (list) object's gc_next got overwritten with NULL. The new info: its (the list object's) gc_refs also changed from GC_TENTATIVELY_UNREACHABLE to GC_UNTRACKED, That the object became untracked is wholly consistent with that its gc_next became NULL but not its gc_prev. I haven't tracked it down all the way to the offending code, but I wonder whether that's worth the bother. What reason do we have to believe that Py_DECREF(op); CANNOT cause other objects in the `collectable` list to become recognized as trash too? We're in cyclic trash, and one decref can trigger an arbitrary number of other objects to become trash. So I'll attach a patch that doesn't assume the Py_DECREF is harmless, by moving `collectable` objects one at a time to a temporary list, and then - at the end - moves all survivors back to `collectable`. That makes the error go away, but I can't be certain it's address the real problem (since I stopped looking for the code that messed with the list as a side effect of doing a decref on the type object for class B). ---------- keywords: +patch Added file: http://bugs.python.org/file35165/finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 01:52:18 2014 From: report at bugs.python.org (eryksun) Date: Tue, 06 May 2014 23:52:18 +0000 Subject: [issue13702] relative symlinks in tarfile.extract broken (windows) In-Reply-To: <1325608963.69.0.695216553795.issue13702@psf.upfronthosting.co.za> Message-ID: <1399420338.75.0.937885849681.issue13702@psf.upfronthosting.co.za> eryksun added the comment: This should be fixed in os.symlink. The Windows CreateSymbolicLink function can't be relied on to translate slash to backslash. It only normalizes an absolute link, or a path that's relative to the current working directory on a drive (e.g. "R:../crypto") since that's stored as an absolute link. For example: >>> os.symlink('C:/Program Files/Python34', 'Python34') >>> os.system('fsutil reparsepoint query Python34') Reparse Tag Value : 0xa000000c Tag value: Microsoft Tag value: Name Surrogate Tag value: Symbolic Link Reparse Data Length: 0x00000078 Reparse Data: 0000: 32 00 3a 00 00 00 32 00 00 00 00 00 43 00 3a 00 2.:...2.....C.:. 0010: 2f 00 50 00 72 00 6f 00 67 00 72 00 61 00 6d 00 /.P.r.o.g.r.a.m. 0020: 20 00 46 00 69 00 6c 00 65 00 73 00 2f 00 50 00 .F.i.l.e.s./.P. 0030: 79 00 74 00 68 00 6f 00 6e 00 33 00 34 00 5c 00 y.t.h.o.n.3.4.\. 0040: 3f 00 3f 00 5c 00 43 00 3a 00 5c 00 50 00 72 00 ?.?.\.C.:.\.P.r. 0050: 6f 00 67 00 72 00 61 00 6d 00 20 00 46 00 69 00 o.g.r.a.m. .F.i. 0060: 6c 00 65 00 73 00 5c 00 50 00 79 00 74 00 68 00 l.e.s.\.P.y.t.h. 0070: 6f 00 6e 00 33 00 34 00 o.n.3.4. The print name uses forward slash, but the NT substitute name uses backslash. In this case, GetFinalPathNameByHandle works fine ("\??" is the NT DosDevices directory in which "C:" is a symbolic link to something like "\Device\HarddiskVolume1"): >>> print(os.path._getfinalpathname('Python34')) \\?\C:\Program Files\Python34 OTOH, forward slashes aren't translated in a relative link: >>> os.remove('Python34') >>> os.symlink('/Program Files/Python34', 'Python34') >>> os.system('fsutil reparsepoint query Python34') Reparse Tag Value : 0xa000000c Tag value: Microsoft Tag value: Name Surrogate Tag value: Symbolic Link Reparse Data Length: 0x00000068 Reparse Data: 0000: 2e 00 2e 00 00 00 2e 00 01 00 00 00 2f 00 50 00 ............/.P. 0010: 72 00 6f 00 67 00 72 00 61 00 6d 00 20 00 46 00 r.o.g.r.a.m. .F. 0020: 69 00 6c 00 65 00 73 00 2f 00 50 00 79 00 74 00 i.l.e.s./.P.y.t. 0030: 68 00 6f 00 6e 00 33 00 34 00 2f 00 50 00 72 00 h.o.n.3.4./.P.r. 0040: 6f 00 67 00 72 00 61 00 6d 00 20 00 46 00 69 00 o.g.r.a.m. .F.i. 0050: 6c 00 65 00 73 00 2f 00 50 00 79 00 74 00 68 00 l.e.s./.P.y.t.h. 0060: 6f 00 6e 00 33 00 34 00 o.n.3.4. In this case GetFinalPathNameByHandle fails because the NT executive doesn't interpret forward slash as a path delimiter: >>> os.path._getfinalpathname('Python34') Traceback (most recent call last): File "", line 1, in OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: 'Python34' I think this is a bug in CreateSymbolicLink, but os.symlink should work around it by first normalizing the target path to use os.sep. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 02:33:11 2014 From: report at bugs.python.org (eryksun) Date: Wed, 07 May 2014 00:33:11 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1399422791.14.0.161801568243.issue18314@psf.upfronthosting.co.za> eryksun added the comment: For some read Sysinternals junction utility doesn't show the raw substitute name. Microsoft's fsutil shows the actual reparse data: C:\>mklink /J Python34 "C:\Program Files\Python34" Junction created for Python34 <<===>> C:\Program Files\Python34 C:\>fsutil reparsepoint query Python34 Reparse Tag Value : 0xa0000003 Tag value: Microsoft Tag value: Name Surrogate Tag value: Mount Point Substitue Name offset: 0 Substitue Name length: 58 Print Name offset: 60 Print Name Length: 50 Substitute Name: \??\C:\Program Files\Python34 Print Name: C:\Program Files\Python34 Reparse Data Length: 0x00000078 Reparse Data: 0000: 00 00 3a 00 3c 00 32 00 5c 00 3f 00 3f 00 5c 00 ..:.<.2.\.?.?.\. 0010: 43 00 3a 00 5c 00 50 00 72 00 6f 00 67 00 72 00 C.:.\.P.r.o.g.r. 0020: 61 00 6d 00 20 00 46 00 69 00 6c 00 65 00 73 00 a.m. .F.i.l.e.s. 0030: 5c 00 50 00 79 00 74 00 68 00 6f 00 6e 00 33 00 \.P.y.t.h.o.n.3. 0040: 34 00 00 00 43 00 3a 00 5c 00 50 00 72 00 6f 00 4...C.:.\.P.r.o. 0050: 67 00 72 00 61 00 6d 00 20 00 46 00 69 00 6c 00 g.r.a.m. .F.i.l. 0060: 65 00 73 00 5c 00 50 00 79 00 74 00 68 00 6f 00 e.s.\.P.y.t.h.o. 0070: 6e 00 33 00 34 00 00 00 n.3.4... fsutil reparsepoint: http://technet.microsoft.com/en-us/library/cc785451.aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 03:12:12 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 07 May 2014 01:12:12 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <1399425131.99.0.348234920461.issue17752@psf.upfronthosting.co.za> Ned Deily added the comment: The quotes that you removed around the DYLD_FRAMEWORK_PATH step are not needed, at least until the rest of configure.ac and Makefile.pre.in support paths with spaces et al. However, you missed removing the single quotes around the DYLD_LIBRARY_PATH step here: RUNSHARED='DYLD_LIBRARY_PATH=`pwd`${DYLD_LIBRARY_PATH:+:${DYLD_LIBRARY_PATH}}' Otherwise, the patch LGTM; I tested it with --enable-framework and --enable-shared configs on OS X. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 03:29:35 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 01:29:35 +0000 Subject: [issue21300] Docs (incorrectly) suggest email.policy.default is the default policy In-Reply-To: <1397829088.9.0.524887326408.issue21300@psf.upfronthosting.co.za> Message-ID: <1399426175.22.0.740277198833.issue21300@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 03:33:12 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 07 May 2014 01:33:12 +0000 Subject: [issue21415] Python __new__ method doc typo (it's a class and not a static method) In-Reply-To: <1399026596.96.0.389694886975.issue21415@psf.upfronthosting.co.za> Message-ID: <1399426392.05.0.119810030241.issue21415@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 03:34:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 07 May 2014 01:34:17 +0000 Subject: [issue21300] Docs (incorrectly) suggest email.policy.default is the default policy In-Reply-To: <1397829088.9.0.524887326408.issue21300@psf.upfronthosting.co.za> Message-ID: <3gNgMD6qJnz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset d994d75cce95 by R David Murray in branch '3.4': #21300: Clean up the docs for the email "policy" arguments. http://hg.python.org/cpython/rev/d994d75cce95 New changeset 63fa945119cb by R David Murray in branch 'default': Merge: #21300: Clean up the docs for the email "policy" arguments. http://hg.python.org/cpython/rev/63fa945119cb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 03:35:21 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 01:35:21 +0000 Subject: [issue21300] Docs (incorrectly) suggest email.policy.default is the default policy In-Reply-To: <1397829088.9.0.524887326408.issue21300@psf.upfronthosting.co.za> Message-ID: <1399426521.0.0.490419899381.issue21300@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the heads up. policy.default will become the default policy eventually, but first the new stuff has to get out of provisional status (which I expect will happen in 3.5). I did a pass over the documentation of all of the policy arguments and cleaned things up. The policy args got added at different points during development and this is the first time I looked at all of them together. There were a number of inconsistencies (and a couple more errors). ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 04:42:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 07 May 2014 02:42:03 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <3gNhsQ378Lz7LjX@mail.python.org> Roundup Robot added the comment: New changeset faef1da30c6d by doko in branch '2.7': - Issue #17752: Fix distutils tests when run from the installed location. http://hg.python.org/cpython/rev/faef1da30c6d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 05:29:00 2014 From: report at bugs.python.org (Tim Peters) Date: Wed, 07 May 2014 03:29:00 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399433340.81.0.562850861122.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Attaching a marginally cleaner version of the patch, with comments. I think it's clear this addresses _some_ real fatal problems, but they're rare: for a problem to show up, it has to be the case that finalize() reduces the refcount of the current object to 0, and that this also causes "the immediately previous" object in the gc list to become free'd, or at least untracked from gc. Then the next "current object" will be taken from an insane gc_next member, and all bets are off. ---------- Added file: http://bugs.python.org/file35166/finalize2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 05:33:52 2014 From: report at bugs.python.org (Tim Peters) Date: Wed, 07 May 2014 03:33:52 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399433632.98.0.0377968287938.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Oh, fudge. There are other failure modes in the test suite after I took out the seemingly redundant incref/decref pair. Adding it back in finalize3.patch. ---------- Added file: http://bugs.python.org/file35167/finalize3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 05:36:33 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 May 2014 03:36:33 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399433793.85.0.371577229964.issue21435@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks Tim! I'm not sure who should review the patch, but it's not me. :-) I've verified that the patch stops the example program from segfaulting on OSX, and I assume you've verified it on Windows -- that's good enough for me. We don't see this happening much in asyncio, so it's a likely story that the demo program happens to arrange for the refcounts to be just so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 05:55:07 2014 From: report at bugs.python.org (Tim Peters) Date: Wed, 07 May 2014 03:55:07 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399434907.73.0.833969859305.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Guido, it's best if Antoine reviewed it - he wrote the relevant PEP, and the code I'm changing. I'm sure he'll agree it's a necessary change. About the rarity of the bug, not only do the refcounts and cyclic structure have to be just right, we also need exactly the right parts of the cyclic trash to appear in exactly the right order in gc's generation list. It really has nothing to do with asyncio. But it's hard to provoke! Even knowing the cause, I have yet to create a simple failing test case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 07:55:13 2014 From: report at bugs.python.org (Palm Kevin) Date: Wed, 07 May 2014 05:55:13 +0000 Subject: [issue18154] make install failed on solaris In-Reply-To: <1370592517.54.0.994664040442.issue18154@psf.upfronthosting.co.za> Message-ID: <1399442113.21.0.365490572973.issue18154@psf.upfronthosting.co.za> Palm Kevin added the comment: Issue can be closed. I am not able to reproduce this any more... ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 09:55:59 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 May 2014 07:55:59 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1399449359.24.0.468066833647.issue21423@psf.upfronthosting.co.za> Mark Dickinson added the comment: BTW, I think there's a design mistake in the EnhancedThreadPoolExecutor that's worth avoiding in any std. lib. implementation: the initialiser and uninitialiser for the EnhancedThreadPoolExecutor accept no arguments. In retrospect, it would have been better to have them take the thread itself as a single argument. We often found ourselves needing this - it's not hard to work around with a threading.current_thread() call, but it's mildly annoying to have to do so. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 10:37:27 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 07 May 2014 08:37:27 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399451847.14.0.78202350999.issue21435@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Tim's analysis is spot on, and finalize3.patch looks good to me (there's some strange commenting style there - do the carets "^" mean something special?). Still, I hope we can find a way to write a test case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 10:39:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 07 May 2014 08:39:31 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399451971.98.0.813070087506.issue21435@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The new info: its (the list object's) gc_refs also changed from > GC_TENTATIVELY_UNREACHABLE to GC_UNTRACKED, That the object became > untracked is wholly consistent with that its gc_next became NULL but > not its gc_prev. Could that be the trashcan mecanism? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 10:42:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 07 May 2014 08:42:57 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399452177.5.0.907602576145.issue21435@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Larry, once this patch is finalized, I think it is a good candidate for 3.4.1. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 12:17:08 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 10:17:08 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1399457828.21.0.187509874819.issue19643@psf.upfronthosting.co.za> Tim Golden added the comment: The attached patch adds an example to the shutil documentation showing how to use an onerror handler to reattempt the removal of a read-only file. It's deliberately low-tech and simply removes the attribute and retries. If there's some other obstacle, it will continue to fail as it would have done in any case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 12:17:21 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 10:17:21 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1399457841.36.0.848076802282.issue19643@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- keywords: +patch Added file: http://bugs.python.org/file35168/issue19643-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 12:20:18 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 10:20:18 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399458018.28.0.885456461265.issue20737@psf.upfronthosting.co.za> Tim Golden added the comment: The attached patch uses DWORD (essentially: unsigned long) in condvar.h:PyCOND_TIMEDWAIT. Adding Kristjan as it was his code. ---------- keywords: +patch nosy: +kristjan.jonsson Added file: http://bugs.python.org/file35169/issue20737.condvar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 12:20:31 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 10:20:31 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399458031.94.0.145949676865.issue20737@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 12:29:06 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 10:29:06 +0000 Subject: [issue21411] Enable Treat Warning as Error on 32-bit Windows In-Reply-To: <1398976216.25.0.391009605761.issue21411@psf.upfronthosting.co.za> Message-ID: <1399458546.3.0.127580795811.issue21411@psf.upfronthosting.co.za> Tim Golden added the comment: I'm at least +0.5 on this: I rather like the idea of forcing these things out into the open. The reason I'm not +1 is the danger of relatively benign or trivial warnings-turned-errors getting in the way of real, possibly critical, development. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 13:06:20 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 07 May 2014 11:06:20 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399460780.98.0.01905856966.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: changing long to DWORD doesn't really fix the overflow issue. The fundamental problem is that some of the apis, e.g. WaitForSingleObject have a DWORD maximum. so, we cannot support sleep times longer than some particular time. Microseconds was chosen in the api because that is the resolution of the api in pthreads. IMHO, I think it is okay to have an implicit ceiling on the timeout, e.g. some 4000 seconds. We can add a caveat somewhere that anyone intending to sleep for extended periods of time should be prepared for a timeout occurring early, and should have his own timing logic to deal with that. My suggestion then is to a) change the apis to DWORD b) add a macro something like PyCOND_MAX_WAIT set to 2^32-1 c) properly clip the argument where we call this cunfion, e.g. in lock.acquire. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 13:09:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 07 May 2014 11:09:14 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <3gNw6d4T91z7LjR@mail.python.org> Roundup Robot added the comment: New changeset 7d1929cc08dd by doko in branch '3.3': - Issue #17752: Fix distutils tests when run from the installed location. http://hg.python.org/cpython/rev/7d1929cc08dd New changeset 01e933cb1de9 by doko in branch '3.4': - Issue #17752: Fix distutils tests when run from the installed location. http://hg.python.org/cpython/rev/01e933cb1de9 New changeset c0bcf1383d77 by doko in branch 'default': - Issue #17752: Fix distutils tests when run from the installed location. http://hg.python.org/cpython/rev/c0bcf1383d77 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 13:49:09 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 11:49:09 +0000 Subject: [issue13702] relative symlinks in tarfile.extract broken (windows) In-Reply-To: <1325608963.69.0.695216553795.issue13702@psf.upfronthosting.co.za> Message-ID: <1399463349.55.0.353820617566.issue13702@psf.upfronthosting.co.za> Tim Golden added the comment: eryksun: could you essay a patch? I'd be happy to review & apply it. ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 15:40:24 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 07 May 2014 13:40:24 +0000 Subject: [issue21447] Intermittent asyncio.open_connection / futures.InvalidStateError In-Reply-To: <1399400899.35.0.6772968076.issue21447@psf.upfronthosting.co.za> Message-ID: <1399470024.23.0.746150554369.issue21447@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 15:49:42 2014 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 07 May 2014 13:49:42 +0000 Subject: [issue21428] Python suddenly cares about EOLs formats on windows In-Reply-To: <1399220400.65.0.0106414482581.issue21428@psf.upfronthosting.co.za> Message-ID: <1399470582.9.0.0689248996222.issue21428@psf.upfronthosting.co.za> Eric V. Smith added the comment: Can you describe what command you ran and what you saw at the "executing with python-3.4.0 make the execution stop" step? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 15:50:36 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 07 May 2014 13:50:36 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1399470636.28.0.572809407247.issue19643@psf.upfronthosting.co.za> Zachary Ware added the comment: Fair point, Paul. Patch looks good to me, Tim, barring a couple of nits pointed out on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 15:59:30 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 13:59:30 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1399471170.24.0.172996782274.issue19643@psf.upfronthosting.co.za> Tim Golden added the comment: Thanks, Zach. Updated patch. ---------- assignee: -> tim.golden Added file: http://bugs.python.org/file35170/issue19643-doc.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 16:00:24 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 07 May 2014 14:00:24 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1399471224.32.0.25268309018.issue19643@psf.upfronthosting.co.za> Zachary Ware added the comment: LGTM! ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 16:05:42 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 14:05:42 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1399471224.32.0.25268309018.issue19643@psf.upfronthosting.co.za> Message-ID: <536A3DB2.90902@timgolden.me.uk> Tim Golden added the comment: Thanks. I'll hold off pushing until I've had a chance to run it on a Unix system. I'm not 100% whether it will operate in the same way there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 16:14:34 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 14:14:34 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1399460780.98.0.01905856966.issue20737@psf.upfronthosting.co.za> Message-ID: <536A3FC6.8000003@timgolden.me.uk> Tim Golden added the comment: Thanks for the feedback, Kristjan. You're obviously correct in that we can't account for timeouts greater than DWORD-size milliseconds and your proposed solution looks reasonable. However, I'd like to close off *this* particular issue which turns on the implicit and, presumably unintended, conversion between unsigned and signed long in the condition variable code. Can you see any adverse effect from moving to DWORD parameters per my patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 16:24:31 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 14:24:31 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399472671.94.0.302977488483.issue20737@psf.upfronthosting.co.za> R. David Murray added the comment: An implicit ceiling of 4000 seconds on the timeout? I routinely use timeouts of approximately 24 hours in calls to Event().wait(). What am I misunderstanding? If I'm not misunderstanding, then no, I don't think that change would be acceptable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 16:36:07 2014 From: report at bugs.python.org (Francisco Gracia) Date: Wed, 07 May 2014 14:36:07 +0000 Subject: [issue21450] [Issue 13630] IDLE: Find(ed) text is not highlighted while dialog box is open Message-ID: New submission from Francisco Gracia: I was delighted with the behaviour of IDLE in version 3.4 until I noticed the problem of the matches with the non highlighted background in the modified (and in this sense improved) iterative text search operations. I was wondering how could this be possible at all in the present luxuriant stage of Python's evolution when now I see that this is a very old and probably cronic problem! What a pity! I have tried to test your *SearchBar* extension, Tal, but, after following the installation instructions of the *README* file, no bar appears at all in the editor window as well in version 3.3 as in 3.4 (WIndows7). As the process is not that difficult, I think that I am performing it correctly. Any idea of what can be wrong in spite of it? Thanks. ---------- messages: 218057 nosy: fgracia priority: normal severity: normal status: open title: [Issue 13630] IDLE: Find(ed) text is not highlighted while dialog box is open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 16:41:47 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 07 May 2014 14:41:47 +0000 Subject: [issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open In-Reply-To: <1324260829.97.0.644849663035.issue13630@psf.upfronthosting.co.za> Message-ID: <1399473707.53.0.0942160985639.issue13630@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +fgracia _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 16:42:32 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 07 May 2014 14:42:32 +0000 Subject: [issue21450] [Issue 13630] IDLE: Find(ed) text is not highlighted while dialog box is open In-Reply-To: Message-ID: <1399473752.4.0.502042984483.issue21450@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> IDLE: Find(ed) text is not highlighted while dialog box is open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 17:15:06 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 07 May 2014 15:15:06 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399475706.91.0.476290581006.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Tim, how about changing the variable to "unsigned long"? I'd like the signature of the function to be the same for all platforms. This will change the code and allow waits for up to 4000 seconds. There is still an overflow problem present, though.+ David, in general the maximum wait times of these primitives are platform specific. If you don't want any ceiling, then we would have to add code all over the place (in C) to do looping timeouts. Not sure which is better, to do it in c, or to accept in python that waits may timeout earlier than specified. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 18:02:48 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 16:02:48 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399478568.02.0.495743597157.issue20737@psf.upfronthosting.co.za> R. David Murray added the comment: I have production code on Windows using python2.7 that calls Event().wait() with a timeout of approximately 24 hours, and it works just fine. Having that no longer work is, IMO, an unacceptable regression. (I'm ready to move this code to python3 as soon as cx_Freeze supports Windows services under python3). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 18:20:54 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 16:20:54 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1399478568.02.0.495743597157.issue20737@psf.upfronthosting.co.za> Message-ID: <536A5D6F.4070207@timgolden.me.uk> Tim Golden added the comment: Just to be clear: the change *I'm* proposing for this issue has nothing to do with limiting the wait, artificially or otherwise. It's simply undoing an unintended conversion from unsigned to signed and back again, whicih currently causes any wait of more than 2147 seconds to hang pretty much indefinitely. It looks to me as though Kristjan's "4000" is off by an order of magnitude: the parameter to WaitFor... is a DWORD number of milliseconds. That allows for 2**31 -1 milliseconds which is something short of 50 days, I believe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 18:29:36 2014 From: report at bugs.python.org (Brian Kearns) Date: Wed, 07 May 2014 16:29:36 +0000 Subject: [issue21350] bug in file.writelines accepting buffers In-Reply-To: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za> Message-ID: <1399480176.79.0.569407095052.issue21350@psf.upfronthosting.co.za> Brian Kearns added the comment: So, for example: >>> f = open('blah', 'wb') >>> f.write(array.array('c', 'test')) >>> f.writelines([array.array('c', 'test')]) Traceback (most recent call last): File "", line 1, in TypeError: writelines() argument must be a sequence of strings While the comment in writelines says: Check that all entries are indeed strings. If not, apply the same rules as for file.write() and convert the results to strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 18:51:27 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 07 May 2014 16:51:27 +0000 Subject: [issue21451] Improve error messages for malformed JSON Message-ID: <1399481487.77.0.0608683542694.issue21451@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The error message for malformed JSON just tells you that the JSON is invalid, it doesn't say why (showing you which character bombed, what text is being read, what the pending openers are, or what allowable characters would have been expected). In the absence of this information, it is very difficult to debug hand-rolled JSON. json.loads('sample_file.json') # students find this hard to debug json.loads('''[ "boys": 10, "girls": 20, ]''') # hard to see trailing comma json.loads("['python', 'perl', 'ruby']") # needs double quotes json.loads("[[10, 20], [30, 40]]]") # unbalanced delimiters ---------- messages: 218062 nosy: rhettinger priority: normal severity: normal status: open title: Improve error messages for malformed JSON type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 19:08:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 07 May 2014 17:08:14 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <3gP44s3KcHz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 31d63ea5dffa by Tim Golden in branch 'default': Issue19643 Add an example of shutil.rmtree which shows how to cope with readonly files on Windows http://hg.python.org/cpython/rev/31d63ea5dffa New changeset a7560c8f38ee by Tim Golden in branch 'default': Issue19643 Fix whitespace http://hg.python.org/cpython/rev/a7560c8f38ee ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 19:29:40 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 07 May 2014 17:29:40 +0000 Subject: [issue18492] Allow all resources if not running under regrtest.py In-Reply-To: <1374161900.43.0.881425486921.issue18492@psf.upfronthosting.co.za> Message-ID: <1399483780.67.0.606816960677.issue18492@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a new and better patch. This patch keeps the regrtest_run global in support and moves the regrtest-or-not check into is_resource_enabled to make is_resource_enabled, requires, and requires_resource consistent with each other and in a way that still allows explicitly setting support.use_resources. The real change is confined to Lib/test/regrtest.py and Lib/test/support/__init__.py, the rest of the patch is cleanup allowed by the change (except for test_decimal, which has a minor change required to allow one of the command line options to that script to work). ---------- title: Add test.support.regrtest_run flag, simplify support.requires -> Allow all resources if not running under regrtest.py versions: +Python 2.7, Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file35171/issue18492.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 19:34:58 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 17:34:58 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1399484098.26.0.177640699694.issue19643@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 19:55:44 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 17:55:44 +0000 Subject: [issue21451] Improve error messages for malformed JSON In-Reply-To: <1399481487.77.0.0608683542694.issue21451@psf.upfronthosting.co.za> Message-ID: <1399485344.35.0.307037075455.issue21451@psf.upfronthosting.co.za> R. David Murray added the comment: Python 3.4.0+ (3.4:d994d75cce95, May 6 2014, 21:37:02) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.loads('''[ ... "boys": 10, ... "girls": 20, ... ]''') Traceback (most recent call last): ... ValueError: Expecting ',' delimiter: line 2 column 17 (char 18) >>> json.loads("['python', 'perl', 'ruby']") Traceback (most recent call last): ... ValueError: Expecting value: line 1 column 2 (char 1) >>> json.loads("[[10, 20], [30, 40]]]") Traceback (most recent call last): ... ValueError: Extra data: line 1 column 21 - line 1 column 22 (char 20 - 21) See issue 16009 for when this was added. Can you improve these? (The first one looks odd...) If so, you could reopen this. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Json error messages could provide more information about the error versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 20:00:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 07 May 2014 18:00:39 +0000 Subject: [issue21451] Improve error messages for malformed JSON In-Reply-To: <1399481487.77.0.0608683542694.issue21451@psf.upfronthosting.co.za> Message-ID: <1399485639.26.0.610132163214.issue21451@psf.upfronthosting.co.za> Raymond Hettinger added the comment: What do you think about backporting the improved error messages? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 20:06:16 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 07 May 2014 18:06:16 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <1399485976.5.0.479350947396.issue17752@psf.upfronthosting.co.za> ?ric Araujo added the comment: For future fixes, please note that 3.3 is in security mode. Can this issue be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 20:16:44 2014 From: report at bugs.python.org (Abhilash Raj) Date: Wed, 07 May 2014 18:16:44 +0000 Subject: [issue18854] is_multipart and walk should document their treatment of 'message' parts. In-Reply-To: <1377612312.75.0.466824716408.issue18854@psf.upfronthosting.co.za> Message-ID: <1399486604.38.0.276654842121.issue18854@psf.upfronthosting.co.za> Abhilash Raj added the comment: I have tried to document the issue in the patch as discussed. David: Do you think I should also add an example in walk() method to demonstrate that it does not iterate over a 'message/rfc822' part even though it is multipart? ---------- keywords: +patch nosy: +abhilash.raj Added file: http://bugs.python.org/file35172/email.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 20:28:08 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 18:28:08 +0000 Subject: [issue21451] Improve error messages for malformed JSON In-Reply-To: <1399481487.77.0.0608683542694.issue21451@psf.upfronthosting.co.za> Message-ID: <1399487288.31.0.943192514768.issue21451@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. I guess I don't have any objection in principle. It is hard to imagine why someone would depend on the exact format of the old low-information messages, though anything is possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 20:35:57 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 18:35:57 +0000 Subject: [issue18854] is_multipart and walk should document their treatment of 'message' parts. In-Reply-To: <1377612312.75.0.466824716408.issue18854@psf.upfronthosting.co.za> Message-ID: <1399487757.39.0.93988942486.issue18854@psf.upfronthosting.co.za> R. David Murray added the comment: Take a look at the source for msg_16.txt. The last part is a message/rfc822, which encapsulates a text/plain message. So it *does* iterate over it, even though it isn't a 'multipart' type (the opposite of what you say in the doc patch). Explicitly pointing out this aspect of the existing example would be a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 21:11:24 2014 From: report at bugs.python.org (Tim Golden) Date: Wed, 07 May 2014 19:11:24 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399489884.31.0.88073356164.issue20737@psf.upfronthosting.co.za> Tim Golden added the comment: Updated patch with unsigned long applied throughout ---------- Added file: http://bugs.python.org/file35173/issue20737.condvar.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 21:13:34 2014 From: report at bugs.python.org (Tim Peters) Date: Wed, 07 May 2014 19:13:34 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399490014.26.0.601975530995.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: Antoine, the carets are a symptom of my flu. My fingers jump on the keyboard from sneezing and coughing, and my eyes are watery so I don't see the typos. But I believe that can be fixed ;-) I doubt the trashcan cruft is responsible, for several reasons: I doubt the stack gets deep enough to trigger the trashcan in this little test; the trashcan xxx_deposit_object() functions assert-fail unless the object's state is _already_ untracked (trashcan does not itself untrack anything); and the trashcan list is linked via the gc_prev member, not the gc_next member (trashcan doesn't touch gc_next, so could not have set gc_next to NULL). Because of the second reason, even if the trashcan is involved the object must have gotten untracked earlier. I'll do another debugger session after a nap ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 22:19:23 2014 From: report at bugs.python.org (Abhilash Raj) Date: Wed, 07 May 2014 20:19:23 +0000 Subject: [issue18854] is_multipart and walk should document their treatment of 'message' parts. In-Reply-To: <1377612312.75.0.466824716408.issue18854@psf.upfronthosting.co.za> Message-ID: <1399493963.87.0.456779823082.issue18854@psf.upfronthosting.co.za> Abhilash Raj added the comment: Sorry, my bad. I was a little confused. I have updated the patch and also added the example explicitly. ---------- Added file: http://bugs.python.org/file35174/email-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 22:37:41 2014 From: report at bugs.python.org (Abhilash Raj) Date: Wed, 07 May 2014 20:37:41 +0000 Subject: [issue21083] Add get_content_disposition() to email.message.Message In-Reply-To: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za> Message-ID: <1399495061.15.0.92533630155.issue21083@psf.upfronthosting.co.za> Abhilash Raj added the comment: I read the discussion on issue #21079. Does this issue still needs a patch? If yes I am willing to write one. ---------- nosy: +abhilash.raj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 22:47:48 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 20:47:48 +0000 Subject: [issue18854] is_multipart and walk should document their treatment of 'message' parts. In-Reply-To: <1377612312.75.0.466824716408.issue18854@psf.upfronthosting.co.za> Message-ID: <1399495668.11.0.890799690697.issue18854@psf.upfronthosting.co.za> R. David Murray added the comment: Using _structure is a great idea. I'm not so fond of the full example, but I'll have to contemplate the text to decide what I'd rather do. Probably I'll take this patch of yours and tweak it, rather than try to tell you what I want :) Thanks for the patch! ---------- assignee: -> r.david.murray stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 22:48:55 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 20:48:55 +0000 Subject: [issue21083] Add get_content_disposition() to email.message.Message In-Reply-To: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za> Message-ID: <1399495735.05.0.549920700699.issue21083@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, that would be great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 23:11:51 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 07 May 2014 21:11:51 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399497111.5.0.958733944118.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Hi there. When I said "4000", that was because of the conversion to microseconds which happens early on. I'm not trying to be difficult here Tim, it's just that you've pointed out a problem and I'd like us to have a comprehensive fix. "unsigned long", I realized, is also not super, because on unix that can be either 32 or 64 bits :) The reason 24 hour waits work on 2.7 is that the conversion to microseconds is never done, rather it uses a DWORD of milliseconds. I agree that this is a regression that needs fixing. Even if there is a theroetical maximum, it should be higher than that :) My latest suggestion? Let's just go ahead and use a "double" for the argument in PyCOND_TIMEDWAIT(). We then have two conversion cases: 1) to a DWORD of milliseconds for both windows apis. Here we should truncate to the max size of a DWORD 2) to the timeval used on pthreads. for 1, that can be done like: if (ds*1e3 > (double)DWORD_MAX) ms = DWORD_MAX; else ms = (DWORD)(ds*1e3) for 2, modifying the PyCOND_ADD_MICROSECONDS macro into something like: #define PyCOND_ADD_MICROSECONDS(tv, ds) do { long oldsec, sec, usec; assert(ds >= 0.0); // truncate ds into theoretical maximum if (ds > (double)long_max) ds = (double)long_max; // whatever that may be sec = (long)ds; usec = (long)((ds - (double)sec) * 1e6)) oldsec = tv.tv_sec; tv.tv_usec += usec; tv.tv_sec += sec; if (usec >= 1000000) { tv.tv_usec -= 1000000; tv.tv_sec += 1; } if (tv.tv_sec < oldsec) /* detect overflow */ tv.sec = max_long; I'm not super experienced with integer arithmetic like this or the pitfalls of overflow, so this might need some pondering. Perhaps it is better to do the tv_sec and tv_usec arithmetic in doubles before converting them back. Does this sound ok? Let me see if I can cook up an alternative patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 23:15:05 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 21:15:05 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399497305.4.0.605259423316.issue20737@psf.upfronthosting.co.za> R. David Murray added the comment: I'm adding Mark Dickinson to nosy to see if our math expert has a comment on the arithmetic :) ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 23:40:21 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 07 May 2014 21:40:21 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399498821.29.0.45989833234.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Ah, I saw this code here in thread_nt.h: if ((DWORD) milliseconds != milliseconds) Py_FatalError("Timeout too large for a DWORD, " "please check PY_TIMEOUT_MAX"); the PyCOND_TIMEDWAIT is currently only used by the GIL code and by the locks on NT. The GIL code assumes microsecond resolution. So we need to stick to that, at least. But the locking code assumes at least DWORD worth of milliseconds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 23:41:23 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 07 May 2014 21:41:23 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399498883.94.0.36733003527.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: (cont.) so, I suggest that we modify the API to use "Py_LONG_LONG usec" Does that sound reasonable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 23:49:37 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 07 May 2014 21:49:37 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399499377.25.0.211947681643.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here is a proposed alternative patch. No additional checks, just a wider "Py_LONG_LONG us" wide enough to accommodate 32 bits of milliseconds as before. ---------- Added file: http://bugs.python.org/file35175/condwait.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 23:51:03 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 07 May 2014 21:51:03 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399499463.32.0.869502550571.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: fix patch, was using git format.... ---------- Added file: http://bugs.python.org/file35176/condwait.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 23:51:18 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 07 May 2014 21:51:18 +0000 Subject: [issue17752] many distutils tests fail when run from the installed location In-Reply-To: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za> Message-ID: <1399499478.05.0.268011037201.issue17752@psf.upfronthosting.co.za> Matthias Klose added the comment: yes, noted myself (too late), and informed Georg about it. Closing for now. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 7 23:59:39 2014 From: report at bugs.python.org (Abhilash Raj) Date: Wed, 07 May 2014 21:59:39 +0000 Subject: [issue21083] Add get_content_disposition() to email.message.Message In-Reply-To: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za> Message-ID: <1399499979.64.0.776205483347.issue21083@psf.upfronthosting.co.za> Abhilash Raj added the comment: I have attached my patch. Reviews? ---------- keywords: +patch Added file: http://bugs.python.org/file35177/c_d.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 00:01:04 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 07 May 2014 22:01:04 +0000 Subject: [issue21264] test_compileall fails to build in the installed location In-Reply-To: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za> Message-ID: <1399500064.67.0.940634252394.issue21264@psf.upfronthosting.co.za> Matthias Klose added the comment: adding unittest developers ---------- nosy: +ezio.melotti, michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 00:05:02 2014 From: report at bugs.python.org (Matthias Klose) Date: Wed, 07 May 2014 22:05:02 +0000 Subject: [issue17756] test_syntax_error fails when run in the installed location In-Reply-To: <1366111959.84.0.955866306047.issue17756@psf.upfronthosting.co.za> Message-ID: <1399500302.02.0.98341312816.issue17756@psf.upfronthosting.co.za> Matthias Klose added the comment: adding unittest developers ---------- nosy: +ezio.melotti, michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 00:09:37 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 22:09:37 +0000 Subject: [issue21083] Add get_content_disposition() to email.message.Message In-Reply-To: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za> Message-ID: <1399500577.37.0.932967894166.issue21083@psf.upfronthosting.co.za> R. David Murray added the comment: Looks pretty good. The docs should say that the value of header is returned, and should also mentioned that the value is lower cased. You should also add a 'versionadded' directive, and for bonus points an entry in the whatsnew document for 3.5. Also, all three possible values should be tested, and a mixed case version of at last one of them, as well as a header that mime parameters in addition to the header value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 00:35:18 2014 From: report at bugs.python.org (Abhilash Raj) Date: Wed, 07 May 2014 22:35:18 +0000 Subject: [issue21083] Add get_content_disposition() to email.message.Message In-Reply-To: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za> Message-ID: <1399502118.14.0.229913378425.issue21083@psf.upfronthosting.co.za> Abhilash Raj added the comment: I have updated the patch. The header with mime parameter 'filename' in addition to header value is already added, will that not be enough? ---------- Added file: http://bugs.python.org/file35178/c_d-revised.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 00:47:10 2014 From: report at bugs.python.org (Tim Peters) Date: Wed, 07 May 2014 22:47:10 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399502830.79.0.530722883563.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: OK! This has nothing to do with the trashcan mechanism. The list object whose gc_next gets stomped on is not itself in a cycle. It's an empty list, and just happens to be a value in a dict, which in turn is a value in another dict. Its refcount falls to 0 as an ordinary part of its containing dict getting deallocated, and that's why the list becomes untracked. This was confusing me because the memory for the list object was apparently not deallocated: if it had been, pymalloc would have sprayed 0xdb into most of it, and gc_next would have appeared to me as 0xdbdbdbdb, not as 0. But after calling PyObject_GC_UnTrack on it (which sets gc_next to NULL), list_dealloc() just pushed the list object onto a free list, so no other kind of list destruction got done. That pretty much explains everything. Cute: it so happens that the _entire_ `collectable` list gets cleared out as a side effect of a single finalize(op); call. The iteration approach in the patch is robust against that, but it's hard to imagine that anything simpler could be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 01:15:38 2014 From: report at bugs.python.org (Andreas van Cranenburgh) Date: Wed, 07 May 2014 23:15:38 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1399504538.12.0.586752797168.issue21423@psf.upfronthosting.co.za> Andreas van Cranenburgh added the comment: Here's a patch. I have added initializer and initargs keywords to both ThreadPoolExecutor and ProcessPoolExecutor, with the same semantics as multiprocessing.Pool. I couldn't figure out what to do if the initializer fails with a ProcessPoolExecutor: how to properly send the traceback back? I also haven't gotten around to figure out how to write tests. I haven't added unitializers, don't know if they would be useful. ---------- keywords: +patch Added file: http://bugs.python.org/file35179/pool_initializer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 01:25:15 2014 From: report at bugs.python.org (Tim Peters) Date: Wed, 07 May 2014 23:25:15 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399505115.03.0.0482505920731.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: finalize4.patch repairs the comment typos, adds a new comment, and removes the unused `old` argument. I think the code is ready to ship with this. I still don't have a reasonably simple fails-before-works-after test case. But that doesn't bother me much, since "the problem" is obvious once it's been seen, and the patch obviously fixes it, and any way of trying to provoke this from pure Python will rely on implementation accidents to get exactly the right pieces of cyclic trash in exactly the right order in gc's internal lists. Still, hope springs eternal ;-) ---------- Added file: http://bugs.python.org/file35180/finalize4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 01:39:51 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 May 2014 23:39:51 +0000 Subject: [issue21083] Add get_content_disposition() to email.message.Message In-Reply-To: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za> Message-ID: <1399505991.73.0.702498689376.issue21083@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 01:47:30 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 07 May 2014 23:47:30 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399506450.23.0.52570266367.issue21422@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 02:13:40 2014 From: report at bugs.python.org (Andreas van Cranenburgh) Date: Thu, 08 May 2014 00:13:40 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1399508020.96.0.439570349609.issue21423@psf.upfronthosting.co.za> Andreas van Cranenburgh added the comment: Here's a version with tests. Detecting an execption in the initializer works with ProcessPoolExecutor, but not with ThreadPoolExecutor. ---------- Added file: http://bugs.python.org/file35181/pool_initializer_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 02:56:46 2014 From: report at bugs.python.org (Tim Peters) Date: Thu, 08 May 2014 00:56:46 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399510606.85.0.337088639243.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: xxx.py provokes a closely related death on my box, in a debug build (where 0xdbdbdbdb happened to be an invalid memory address). There are no imports so asyncio is definitely off the hook ;-) The code is senseless, and changing just about anything makes the problem go away. As mentioned before, provoking this class of error relies on all sorts of implementation accidents to get the internal gc lists into just the right state to fail. ---------- Added file: http://bugs.python.org/file35182/xxx.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 05:36:10 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 08 May 2014 03:36:10 +0000 Subject: [issue19414] iter(ordered_dict) yields keys not in dict in some circumstances In-Reply-To: <1382844474.66.0.775956254592.issue19414@psf.upfronthosting.co.za> Message-ID: <1399520170.61.0.173203795714.issue19414@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Raymond, I think your patch does not really address the issue reported here. The dict documentation still guarantees that mutating a dict during iteration will raise a RuntimeError or may skip elements. The OrderedDict documentation still does not point out that OrderedDicts behave differently, yet they still raise a different exception than a regular dict in the same situation. I believe it should be possible to pass an OrderedDict to any function expecting a regular dict. This is still not possible. But even if you think this is not desirable (or not worth the cost), could we at least *document* that OrderedDicts behave differently? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 09:29:01 2014 From: report at bugs.python.org (Tim Golden) Date: Thu, 08 May 2014 07:29:01 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399534141.79.0.698626254423.issue20737@psf.upfronthosting.co.za> Tim Golden added the comment: +1 for Kristjan's latest patch. And thanks for working this through, Kristjan: I'd missed the fact that the microseconds conversion could itself overflow even an unsigned long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 11:03:42 2014 From: report at bugs.python.org (Mateusz Loskot) Date: Thu, 08 May 2014 09:03:42 +0000 Subject: [issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path Message-ID: <1399539822.8.0.0455279031899.issue21452@psf.upfronthosting.co.za> New submission from Mateusz Loskot: While building Python 3.2 or Python 3.4 with Visual Studio 2013 on Windows 8.1, pythoncore.vcxproj fails to build due to illformed pre-link event command. (FYI, I have upgraded all .vcxproj files to VS2013 locally.) Here is the command and the error: 
1>PreLinkEvent:
1>  Description: Generate build information...
1>  cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fo"D:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore" \getbuildinfo.o" -I..\Include -I..\PC
1>  getbuildinfo.c
1>..\Modules\getbuildinfo.c(1): fatal error C1083: Cannot open include file: 'Python.h': No such file or directory
Notice the superfluous double quote followed by whitespace in the following argument: 
-Fo"D:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore" \getbuildinfo.o"
The problem is somewhat known as there is related comment in the make_buildinfo.c file about the custom commands arguments parsing: 
/* Hack fix for bad command line:  If the command is issued like this:
 * $(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)"
 * we will get a trailing quote because IntDir ends with a backslash that then
 * escapes the final ".  To simplify the life for developers, catch that problem
 * here by cutting it off.
 * The proper command line, btw is:
 * $(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\"
 * Hooray for command line parsing on windows.
 */
There are two solutions possible: 1) Correct the PreLinkEvent command in make_buildinfo.vcxproj according to the comment above: 
$(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\"
2) Patch make_buildinfo.c (attached). Then, the cl.exe command is correct: 
1>  cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fo"F:\V81-VS2013.win32\Librarie
s\External\Source\Python\Debug\PCbuild\Win32-temp-Debug\pythoncore\getbuildinfo.o" -I..\Include -I..\PC
1>  getbuildinfo.c
I'm not sure why this problems leaks while building with VS2013. I have been building Python 3.2 with VS2012 for long time w/o any issues. Perhaps, it is related to combination of VS2013 and Windows 8.1. Although, I'm not observing this problem while building with VS2012 on Windows 8.1, it would be helpful if someone else who uses VS2012 or VS2013 could confirm my results. ---------- components: Build files: Python340-make_buildinfo-vs2013.patch keywords: patch messages: 218097 nosy: mloskot priority: normal severity: normal status: open title: make_buildinfo.exe with VS2013 fails due ill-formed IntDir path type: compile error versions: Python 3.2, Python 3.4 Added file: http://bugs.python.org/file35183/Python340-make_buildinfo-vs2013.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 11:12:08 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 08 May 2014 09:12:08 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399540328.7.0.720557342218.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Thanks. Can you confirm that it resolves the issue? I'll get it checked in once I get the regrtest suite run. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 11:32:12 2014 From: report at bugs.python.org (Tim Golden) Date: Thu, 08 May 2014 09:32:12 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1399540328.7.0.720557342218.issue20737@psf.upfronthosting.co.za> Message-ID: <536B4F17.4070506@timgolden.me.uk> Tim Golden added the comment: s/Py_LONG_LONG/PY_LONG_LONG/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 11:33:38 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 08 May 2014 09:33:38 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399541618.27.0.614851472765.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I see, I wasn't able to compile it yesterday when I did it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 11:37:45 2014 From: report at bugs.python.org (Francisco Gracia) Date: Thu, 08 May 2014 09:37:45 +0000 Subject: [issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open In-Reply-To: <1324260829.97.0.644849663035.issue13630@psf.upfronthosting.co.za> Message-ID: <1399541865.38.0.634603048219.issue13630@psf.upfronthosting.co.za> Francisco Gracia added the comment: I had problems for installing your *SearchBar*, Tal, in Python 33 and 34 until it downed onto me that in its present form it is only Python 2 compliant. This is then its first weakness, that of course can be easily remedied by applying *2to3.py* to it, as I did. I am using Windows 7. Another fault is that when IDLE's editor window is expanded to full screen the bar's widget fills half of it. I imagine that this should not be difficult to mend either. If you would be interested in suggestions for your revision, mine would be that the option controls of the *Find* searchbar be disposed in two rows. This would avoid a certain clutter and allow the addition of a new one that, if possible, I would find convenient. It would perform the toggling of the simultaneous highlighting of all the matches of the search, something that is handy in some situations but can be confusing in others. These are the only quirks that I have observed until now. I think that *SearchBar* is a must for anyone that uses IDLE's editor in 3.4 or in any previous version of Python (as I have discovered here that the problem is an old one) and am surprised that it does not belong to the standard distribution since it was available. Thanks and congratulations for your excellent job. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 11:48:48 2014 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 08 May 2014 09:48:48 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1398785682.37.0.0908919633838.issue12916@psf.upfronthosting.co.za> Message-ID: St?phane Wirtel added the comment: Hi all, No news about this issue, Do you have time for a feedback? Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 11:53:41 2014 From: report at bugs.python.org (Tim Golden) Date: Thu, 08 May 2014 09:53:41 +0000 Subject: [issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path In-Reply-To: <1399539822.8.0.0455279031899.issue21452@psf.upfronthosting.co.za> Message-ID: <1399542821.07.0.546448582628.issue21452@psf.upfronthosting.co.za> Tim Golden added the comment: What effect does your patch have on a VS2010 build? VS2010 is the official toolset for current Python 3.x versions so any changes we make must support that. Also: does the same problem occur on the development branch? (De-selecting 3.2 as it's in security-fix mode only) ---------- components: +Windows nosy: +tim.golden versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 12:15:38 2014 From: report at bugs.python.org (Tim Golden) Date: Thu, 08 May 2014 10:15:38 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1399541618.27.0.614851472765.issue20737@psf.upfronthosting.co.za> Message-ID: <536B5947.5060400@timgolden.me.uk> Tim Golden added the comment: I can confirm that the attached test.py times out after 2150 seconds (ie 30+ minutes) with your (tweaked) patch applied: python test.py 2150 Running Debug|Win32 interpreter... 2014-05-08 10:33:53.670091 Expected to time out by 2014-05-08 11:09:43.670091 Timed Out 2014-05-08 11:09:43.765079 I don't see us adding a test which would lengthen the test suite run by more than 30 minutes! ---------- Added file: http://bugs.python.org/file35184/test.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- import sys import threading import datetime now = datetime.datetime.now() print(now) seconds_to_wait = int(sys.argv[1]) expected_to_finish = now + datetime.timedelta(seconds=seconds_to_wait) print("Expected to time out by", expected_to_finish) print("Event Fired" if threading.Event().wait(seconds_to_wait) else "Timed Out") print(datetime.datetime.now()) From report at bugs.python.org Thu May 8 12:16:51 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 08 May 2014 10:16:51 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399544211.62.0.239166189013.issue20737@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: nope, let's not do that :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 12:37:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 08 May 2014 10:37:49 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <3gPWMw1rZkz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 80b76c6fad44 by Kristj?n Valur J?nsson in branch 'default': The PyCOND_TIMEDWAIT must use microseconds for the timeout argument http://hg.python.org/cpython/rev/80b76c6fad44 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 13:07:04 2014 From: report at bugs.python.org (Tal Einat) Date: Thu, 08 May 2014 11:07:04 +0000 Subject: [issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open In-Reply-To: <1324260829.97.0.644849663035.issue13630@psf.upfronthosting.co.za> Message-ID: <1399547224.78.0.151434791312.issue13630@psf.upfronthosting.co.za> Tal Einat added the comment: Thanks for the kind words, Francisco! And also for taking the time to get SearchBar working on Python3 and giving it a try. I agree that SearchBar is a huge improvement over IDLE's simple find and replace dialogs. And by now every potential user is used to such search interfaces, whereas search dialogs are a thing of the past. Regarding your suggestion to split the buttons into a separate line, that would make problems with the replace mode. In the replace mode there are two bars, the first of which is the regular search bar. By adding another bar for controls, that would mean having three bars, and it would be non-obvious to users whether the option refer to the find or replace bar. Also, we must be careful not to add many options and controls to the interface, and this is the first time someone has asked to be able to toggle search hit highlighting. If this comes up repeatedly I will consider it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 13:19:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 08 May 2014 11:19:31 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <3gPXJ21kYxz7LjP@mail.python.org> Roundup Robot added the comment: New changeset ab5e2b0fba15 by Kristj?n Valur J?nsson in branch '3.3': The PyCOND_TIMEDWAIT must use microseconds for the timeout argument http://hg.python.org/cpython/rev/ab5e2b0fba15 New changeset 7764bb7f2983 by Kristj?n Valur J?nsson in branch '3.4': Merging from 3.3: The PyCOND_TIMEDWAIT must use microseconds for the timeout argument http://hg.python.org/cpython/rev/7764bb7f2983 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 13:21:27 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 08 May 2014 11:21:27 +0000 Subject: [issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows In-Reply-To: <1393107626.95.0.76942760924.issue20737@psf.upfronthosting.co.za> Message-ID: <1399548087.1.0.999814619617.issue20737@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 14:05:40 2014 From: report at bugs.python.org (=?utf-8?q?Mateusz_=C5=81oskot?=) Date: Thu, 08 May 2014 12:05:40 +0000 Subject: [issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path In-Reply-To: <1399542821.07.0.546448582628.issue21452@psf.upfronthosting.co.za> Message-ID: Mateusz ?oskot added the comment: On 8 May 2014 11:53, Tim Golden wrote: > > What effect does your patch have on a VS2010 build? I don't know. I don't use VS2010. However, I suspect the option 1) fix should be applied anyway as it is suggested by the comment in make_buildinfo.c. Why the pythoncore.vc[x]proj project files do not use "$(IntDir)\" by default, no idea. > Also: does the same problem occur on the development branch? I haven't tested, I work with released Python sources now. I noticed though, that this issue is somewhat random. I'm building from VS2013 command prompt, and I've just successully built the non-patched make_buildinfo.{c|vcxproj}. This made me wonder if the problem is related to cmd.exe configuration, extensions enabled/disabled, and such. ---------- nosy: +Mateusz.?oskot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 15:37:54 2014 From: report at bugs.python.org (Merlijn van Deen) Date: Thu, 08 May 2014 13:37:54 +0000 Subject: [issue21300] Docs (incorrectly) suggest email.policy.default is the default policy In-Reply-To: <1397829088.9.0.524887326408.issue21300@psf.upfronthosting.co.za> Message-ID: <1399556274.87.0.57882916967.issue21300@psf.upfronthosting.co.za> Merlijn van Deen added the comment: Small typo that slipped in: 'udpate' instead of 'update' on the following lines: http://hg.python.org/cpython/rev/63fa945119cb#l2.18 http://hg.python.org/cpython/rev/63fa945119cb#l2.43 http://hg.python.org/cpython/rev/63fa945119cb#l2.66 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 15:53:48 2014 From: report at bugs.python.org (Tim Golden) Date: Thu, 08 May 2014 13:53:48 +0000 Subject: [issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path In-Reply-To: <1399539822.8.0.0455279031899.issue21452@psf.upfronthosting.co.za> Message-ID: <1399557228.66.0.393190089063.issue21452@psf.upfronthosting.co.za> Tim Golden added the comment: Attached project patch seems to build successfully on VS2010. It's possible that this failed in some way on VS2008; AFAICT it hasn't been touched since Brian first ported it two years ago. Adding Zach Ware for a second opinion. ---------- nosy: +zach.ware Added file: http://bugs.python.org/file35185/issue21452.pythoncore.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 16:06:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 08 May 2014 14:06:34 +0000 Subject: [issue21300] Docs (incorrectly) suggest email.policy.default is the default policy In-Reply-To: <1397829088.9.0.524887326408.issue21300@psf.upfronthosting.co.za> Message-ID: <3gPc0n01g7z7Ljr@mail.python.org> Roundup Robot added the comment: New changeset 9e55089aa505 by R David Murray in branch '3.4': #21300: fix typo http://hg.python.org/cpython/rev/9e55089aa505 New changeset 232938736a31 by R David Murray in branch 'default': Merge #21300: fix typo http://hg.python.org/cpython/rev/232938736a31 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 16:07:12 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 08 May 2014 14:07:12 +0000 Subject: [issue21300] Docs (incorrectly) suggest email.policy.default is the default policy In-Reply-To: <1397829088.9.0.524887326408.issue21300@psf.upfronthosting.co.za> Message-ID: <1399558032.67.0.568670050973.issue21300@psf.upfronthosting.co.za> R. David Murray added the comment: That was actually copy and paste of an existing typo, which I've also now fixed. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 16:46:39 2014 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 08 May 2014 14:46:39 +0000 Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}" In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za> Message-ID: <1399560399.45.0.797064809725.issue13598@psf.upfronthosting.co.za> Armin Ronacher added the comment: Is there any chance this will be fixed for 2.7 as well? ---------- nosy: +aronacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 17:02:52 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 May 2014 15:02:52 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399561372.44.0.683842666386.issue21435@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > finalize4.patch repairs the comment typos, adds a new comment, and > removes the unused `old` argument. I think the code is ready to ship > with this. Thanks! So do I. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 17:08:27 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 08 May 2014 15:08:27 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399561707.46.0.934813104755.issue21435@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm totally on board with you guys checking this in for 3.4.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 19:23:32 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 May 2014 17:23:32 +0000 Subject: [issue21350] bug in file.writelines accepting buffers In-Reply-To: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za> Message-ID: <1399569812.26.0.548130000875.issue21350@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report and the patch! For a bit of trivia, this code has been there since 2000 (63ea2a2df06f). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 19:26:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 08 May 2014 17:26:13 +0000 Subject: [issue21350] bug in file.writelines accepting buffers In-Reply-To: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za> Message-ID: <3gPhR80rZHz7LjP@mail.python.org> Roundup Robot added the comment: New changeset db842f730432 by Antoine Pitrou in branch '2.7': Issue #21350: Fix file.writelines() to accept arbitrary buffer objects, as advertised. http://hg.python.org/cpython/rev/db842f730432 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 19:26:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 May 2014 17:26:28 +0000 Subject: [issue21350] bug in file.writelines accepting buffers In-Reply-To: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za> Message-ID: <1399569988.13.0.0987312556336.issue21350@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 19:42:00 2014 From: report at bugs.python.org (Vitaly Isaev) Date: Thu, 08 May 2014 17:42:00 +0000 Subject: [issue21453] Support of RPM subpackages in distutils Message-ID: <1399570920.1.0.821068791606.issue21453@psf.upfronthosting.co.za> New submission from Vitaly Isaev: RPM Subpackages are very useful when you maintain the big project on the RHEL-kind Linux distro and you need to sparse the project into several differing packages (for instance - , -libs, -devel, -debuginfo). It would be convenient to do the same in a purely Pythonic projects (i mean to place something in setup.py and to obtain the output spec-file with a corresponding number of `%package ` sections). I didn't manage to find the code that matches these purposes in the most up-to-date release of the distutils (/usr/lib64/python2.7/distutils/command/bdist_rpm.py). So I would ask to implement this feature. Also I can try to do it on my own in case if the community considers it as a good offer. Thank you. ---------- components: Distutils messages: 218119 nosy: dstufft, eric.araujo, vitalyisaev2 priority: normal severity: normal status: open title: Support of RPM subpackages in distutils type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 21:05:06 2014 From: report at bugs.python.org (John Isidore) Date: Thu, 08 May 2014 19:05:06 +0000 Subject: [issue21454] asyncio's loop.connect_read_pipe makes pipes non-blocking contrary to the documentation Message-ID: <1399575906.07.0.344601032189.issue21454@psf.upfronthosting.co.za> New submission from John Isidore: the documentation for BaseEventLoop.connect_read_pipe says: > "pipe is file-like object **already switched** to nonblocking." http://hg.python.org/cpython/file/232938736a31/Doc/library/asyncio-eventloop.rst#l453 But it looks like connect_read_pipe() accepts blocking pipes and switches them to non-blocking mode: > "It looks like connect_read_pipe() (eventually) sets the fd to non-blocking. So it does work." https://code.google.com/p/tulip/source/detail?r=0a716436176993a12cf861b6cafffe8a31bc1127 If it is indeed the case then the documentation should mention that it accepts blocking pipes and makes them non-blocking. May it break other processes by making the file non-blocking if it is a pty that is shared between processes? Related: "Don't set shared file descriptors to non-blocking I/O mode." http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dont-set-shared-file-descriptors-to-non-blocking-mode.html ---------- assignee: docs at python components: Documentation messages: 218120 nosy: John Isidore, docs at python, gvanrossum priority: normal severity: normal status: open title: asyncio's loop.connect_read_pipe makes pipes non-blocking contrary to the documentation type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 21:13:27 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 08 May 2014 19:13:27 +0000 Subject: [issue21455] add default backlog to socket.listen() Message-ID: <1399576407.19.0.800132565912.issue21455@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: Having to pass an explicit backlog value to listen() is a pain: most people don't know which value to pass, and often end up using a value too small which can lead to connections being rejected. For example, if you search throughout the standard library, you'll see many different hard-coded values. The patch attached uses a default value of SOMAXCONN for socket.listen(): it should give a good default behavior (that's what golang does for example: in fact they go even further by checking the runtime value from net.core.somaxconn). A second step would be to update the codebase to remove explicit backlogs (unless specific case). ---------- components: Library (Lib) files: socket_listen.diff keywords: patch messages: 218121 nosy: haypo, neologix, pitrou, sbt priority: normal severity: normal stage: patch review status: open title: add default backlog to socket.listen() type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35186/socket_listen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 22:21:36 2014 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 08 May 2014 20:21:36 +0000 Subject: [issue21454] asyncio's loop.connect_read_pipe makes pipes non-blocking contrary to the documentation In-Reply-To: <1399575906.07.0.344601032189.issue21454@psf.upfronthosting.co.za> Message-ID: <1399580496.84.0.381200936639.issue21454@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks for the report, that should be easy to fix. Regarding PTYs, we're aware: https://code.google.com/p/tulip/issues/detail?id=147 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 22:23:26 2014 From: report at bugs.python.org (Tim Peters) Date: Thu, 08 May 2014 20:23:26 +0000 Subject: [issue21435] Segfault with cyclic reference and asyncio.Future In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399580606.56.0.48078010088.issue21435@psf.upfronthosting.co.za> Changes by Tim Peters : ---------- assignee: -> tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 22:38:38 2014 From: report at bugs.python.org (jader fabiano) Date: Thu, 08 May 2014 20:38:38 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399407931.08.0.102958118766.issue21448@psf.upfronthosting.co.za> Message-ID: jader fabiano added the comment: Hi. I undestood this problem that It was happening, I was writting the mime wrong in the attachments. I read a file with size 4M and I've converted to Base64, so I've written in the mime the content. But i wasn't put the lines with 76 ccharacters plus ""/r/n". I was writing the every in the only line. I think this did the Email Parser uses 100% of the CPU and It delay mora time. I packed up and I was sending email very fast. Thanks 2014-05-06 17:25 GMT-03:00 R. David Murray : > > R. David Murray added the comment: > > Also to clarify: HeaderParser will *also* read the entire message, it just > won't look for MIME attachments in the 'everything else', it will just > treat the 'everything else' as arbitrary data and record it as the payload > of the top level Message object. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 23:00:46 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 08 May 2014 21:00:46 +0000 Subject: [issue21444] __len__ can't return big numbers In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399582846.43.0.590861495856.issue21444@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I recommend this be closed: too much impact on existing code for too little benefit. CPython has historically imposed some artificial implementation specific details in order make the implementation cleaner and faster internally (i.e. a limit on the number of function arguments, sys.maxsize limits, etc.) ---------- nosy: +rhettinger priority: normal -> low type: -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 23:09:06 2014 From: report at bugs.python.org (Tim Peters) Date: Thu, 08 May 2014 21:09:06 +0000 Subject: [issue21435] Segfault in gc with cyclic trash In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399583346.44.0.398658005256.issue21435@psf.upfronthosting.co.za> Changes by Tim Peters : ---------- title: Segfault with cyclic reference and asyncio.Future -> Segfault in gc with cyclic trash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 23:17:54 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 08 May 2014 21:17:54 +0000 Subject: [issue21444] __len__ can't return big numbers In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za> Message-ID: <1399583874.46.0.341085973247.issue21444@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 8 23:35:25 2014 From: report at bugs.python.org (Tim Peters) Date: Thu, 08 May 2014 21:35:25 +0000 Subject: [issue21435] Segfault in gc with cyclic trash In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399584925.93.0.353417648756.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: finalize42.patch includes a test case. If nobody objects within a few hours, I'll commit it. ---------- Added file: http://bugs.python.org/file35187/finalize42.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:10:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 08 May 2014 22:10:21 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za> Message-ID: <3gPpl02dxcz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 17689e43839a by Charles-Fran?ois Natali in branch 'default': Issue #21037: Add a build option to enable AddressSanitizer support. http://hg.python.org/cpython/rev/17689e43839a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:12:27 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 May 2014 22:12:27 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: <1399576407.19.0.800132565912.issue21455@psf.upfronthosting.co.za> Message-ID: <1399587147.75.0.361825533101.issue21455@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is there a risk of SOMAXCONN being huge and therefore allocating a large amount of resources? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:15:36 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 May 2014 22:15:36 +0000 Subject: [issue18564] Integer overflow in socketmodule In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za> Message-ID: <1399587336.93.0.578573469155.issue18564@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I am thinking about patching it there and then open another ticket > here in order to adopt str2ba(). This way we can close this ticket for > now. Well, if some str2ba() versions are notoriously buggy, we should probably not use it, IMHO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:17:54 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 May 2014 22:17:54 +0000 Subject: [issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation In-Reply-To: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za> Message-ID: <1399587474.95.0.589258351305.issue21396@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch looks basically fine. I will make a few tweaks to the comments in the test case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:28:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 May 2014 22:28:47 +0000 Subject: [issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation In-Reply-To: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za> Message-ID: <1399588127.76.0.991017996702.issue21396@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, with the patch, the universal_newlines tests in test_subprocess hang (quite logically, since they lack a flush()). I will fix them as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:30:53 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 08 May 2014 22:30:53 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <3gPpl02dxcz7LjQ@mail.python.org> Message-ID: Charles-Fran?ois Natali added the comment: I just pushed the patch. Stefan, did you have time to setup a buildbot? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:33:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 08 May 2014 22:33:29 +0000 Subject: [issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation In-Reply-To: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za> Message-ID: <3gPqFh2hlnz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 39f2a78f4357 by Antoine Pitrou in branch '3.4': Issue #21396: Fix TextIOWrapper(..., write_through=True) to not force a flush() on the underlying binary stream. http://hg.python.org/cpython/rev/39f2a78f4357 New changeset 37d0c41ed8ad by Antoine Pitrou in branch 'default': Issue #21396: Fix TextIOWrapper(..., write_through=True) to not force a flush() on the underlying binary stream. http://hg.python.org/cpython/rev/37d0c41ed8ad ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:34:18 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 May 2014 22:34:18 +0000 Subject: [issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation In-Reply-To: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za> Message-ID: <1399588458.28.0.524908887922.issue21396@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you for the patch! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:43:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 08 May 2014 22:43:40 +0000 Subject: [issue21435] Segfault in gc with cyclic trash In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <3gPqTR4q9Vz7Lkn@mail.python.org> Roundup Robot added the comment: New changeset 64ba3f2de99c by Tim Peters in branch '3.4': Issue #21435: Segfault in gc with cyclic trash http://hg.python.org/cpython/rev/64ba3f2de99c New changeset cb9a3985df00 by Tim Peters in branch 'default': Merge from 3.4. http://hg.python.org/cpython/rev/cb9a3985df00 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 00:46:10 2014 From: report at bugs.python.org (Tim Peters) Date: Thu, 08 May 2014 22:46:10 +0000 Subject: [issue21435] Segfault in gc with cyclic trash In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399589170.95.0.303626070138.issue21435@psf.upfronthosting.co.za> Changes by Tim Peters : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 01:02:02 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 08 May 2014 23:02:02 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: <1399587147.75.0.361825533101.issue21455@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Is there a risk of SOMAXCONN being huge and therefore allocating a large amount of resources? On a sensible operating system, no, but better safe than sorry: the patch attached caps the value to 128 (a common SOMAXCONN value). It should be high enough to avoid connection drops in common workloads, and still guard against non-sensical SOMAXCONN values. ---------- Added file: http://bugs.python.org/file35188/socket_listen-1.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 17689e43839a Doc/library/socket.rst --- a/Doc/library/socket.rst Thu May 08 23:08:51 2014 +0100 +++ b/Doc/library/socket.rst Thu May 08 23:52:22 2014 +0100 @@ -906,12 +906,15 @@ On other platforms, the generic :func:`fcntl.fcntl` and :func:`fcntl.ioctl` functions may be used; they accept a socket object as their first argument. -.. method:: socket.listen(backlog) +.. method:: socket.listen([backlog]) - Listen for connections made to the socket. The *backlog* argument specifies the - maximum number of queued connections and should be at least 0; the maximum value - is system-dependent (usually 5), the minimum value is forced to 0. + Enable a server to accept connections. If *backlog* is specified, it must + be at least 0 (if it is lower, it is set to 0); it specifies the number of + unaccepted connections that the system will allow before refusing new + connections. If not specified, a default reasonable value is chosen. + .. versionchanged:: 3.5 + The *backlog* parameter is now optional. .. method:: socket.makefile(mode='r', buffering=None, *, encoding=None, \ errors=None, newline=None) diff -r 17689e43839a Lib/test/test_socket.py --- a/Lib/test/test_socket.py Thu May 08 23:08:51 2014 +0100 +++ b/Lib/test/test_socket.py Thu May 08 23:52:22 2014 +0100 @@ -1344,10 +1344,13 @@ def test_listen_backlog(self): for backlog in 0, -1: - srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as srv: + srv.bind((HOST, 0)) + srv.listen(backlog) + + with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as srv: srv.bind((HOST, 0)) - srv.listen(backlog) - srv.close() + srv.listen() @support.cpython_only def test_listen_backlog_overflow(self): diff -r 17689e43839a Modules/socketmodule.c --- a/Modules/socketmodule.c Thu May 08 23:08:51 2014 +0100 +++ b/Modules/socketmodule.c Thu May 08 23:52:22 2014 +0100 @@ -121,7 +121,7 @@ getsockname() -- return local address\n\ getsockopt(level, optname[, buflen]) -- get socket options\n\ gettimeout() -- return timeout or None\n\ -listen(n) -- start listening for incoming connections\n\ +listen([n]) -- start listening for incoming connections\n\ recv(buflen[, flags]) -- receive data\n\ recv_into(buffer[, nbytes[, flags]]) -- receive data (into a buffer)\n\ recvfrom(buflen[, flags]) -- receive data and sender\'s address\n\ @@ -2534,14 +2534,16 @@ /* s.listen(n) method */ static PyObject * -sock_listen(PySocketSockObject *s, PyObject *arg) +sock_listen(PySocketSockObject *s, PyObject *args) { - int backlog; + /* We try to choose a default backlog high enough to avoid connection drops + * for common workloads, yet not too high to limit resource usage. */ + int backlog = Py_MIN(SOMAXCONN, 128); int res; - backlog = _PyLong_AsInt(arg); - if (backlog == -1 && PyErr_Occurred()) + if (!PyArg_ParseTuple(args, "|i:listen", &backlog)) return NULL; + Py_BEGIN_ALLOW_THREADS /* To avoid problems on systems that don't allow a negative backlog * (which doesn't make sense anyway) we force a minimum value of 0. */ @@ -2556,12 +2558,12 @@ } PyDoc_STRVAR(listen_doc, -"listen(backlog)\n\ +"listen([backlog])\n\ \n\ -Enable a server to accept connections. The backlog argument must be at\n\ -least 0 (if it is lower, it is set to 0); it specifies the number of\n\ +Enable a server to accept connections. If backlog is specified, it must be\n\ +at least 0 (if it is lower, it is set to 0); it specifies the number of\n\ unaccepted connections that the system will allow before refusing new\n\ -connections."); +connections. If not specified, a default reasonable value is chosen."); /* @@ -3795,7 +3797,7 @@ {"share", (PyCFunction)sock_share, METH_VARARGS, sock_share_doc}, #endif - {"listen", (PyCFunction)sock_listen, METH_O, + {"listen", (PyCFunction)sock_listen, METH_VARARGS, listen_doc}, {"recv", (PyCFunction)sock_recv, METH_VARARGS, recv_doc}, From report at bugs.python.org Fri May 9 02:45:50 2014 From: report at bugs.python.org (akira) Date: Fri, 09 May 2014 00:45:50 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1399596350.94.0.568909428631.issue21332@psf.upfronthosting.co.za> akira added the comment: I've updated the patch to remove changes to test_universal_newlines test that was fixed in revision 37d0c41ed8ad that closes #21396 issue ---------- Added file: http://bugs.python.org/file35189/subprocess-line-buffering-issue21332-ps4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 05:19:06 2014 From: report at bugs.python.org (paul j3) Date: Fri, 09 May 2014 03:19:06 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1399605546.92.0.907565216614.issue14910@psf.upfronthosting.co.za> paul j3 added the comment: Update the patch - test_argparse.py - cleanup spaces argparse.rst - merging conflicts ---------- Added file: http://bugs.python.org/file35190/issue14910_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 06:35:22 2014 From: report at bugs.python.org (paul j3) Date: Fri, 09 May 2014 04:35:22 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1399610122.24.0.564257569259.issue14910@psf.upfronthosting.co.za> Changes by paul j3 : Removed file: http://bugs.python.org/file35190/issue14910_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 06:36:19 2014 From: report at bugs.python.org (paul j3) Date: Fri, 09 May 2014 04:36:19 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1399610179.32.0.407392418657.issue14910@psf.upfronthosting.co.za> Changes by paul j3 : Added file: http://bugs.python.org/file35191/issue14910_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 08:12:11 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 09 May 2014 06:12:11 +0000 Subject: [issue21435] Segfault in gc with cyclic trash In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399615931.09.0.385858956284.issue21435@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thanks a lot! The patch fixes crush dump issue with __del__ in aiohttp library tests also. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 09:03:50 2014 From: report at bugs.python.org (Remi Pointel) Date: Fri, 09 May 2014 07:03:50 +0000 Subject: [issue21456] skip 2 tests in test_urllib2net.py if _ssl module not present Message-ID: <1399619030.67.0.271075819996.issue21456@psf.upfronthosting.co.za> New submission from Remi Pointel: Hi, I tested the regress tests on a machine which does not have the ssl module, and I have 2 errors in Lib/test/test_urllib2net.py. I think it should skip the test instead. Attached is a diff I wrote, it's based on Lib/test/test_poplib.py. Don't hesitate if I miss a thing. Remi. ---------- components: Tests files: Lib_test_test_urllib2net_py.diff keywords: patch messages: 218139 nosy: rpointel priority: normal severity: normal status: open title: skip 2 tests in test_urllib2net.py if _ssl module not present versions: Python 3.5 Added file: http://bugs.python.org/file35192/Lib_test_test_urllib2net_py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 10:58:00 2014 From: report at bugs.python.org (Thomas Klausner) Date: Fri, 09 May 2014 08:58:00 +0000 Subject: [issue21457] NetBSD curses support improvements Message-ID: <1399625880.63.0.0407983839036.issue21457@psf.upfronthosting.co.za> New submission from Thomas Klausner: NetBSD's curses headers have different include guards than ncurses. Also, the NetBSD curses library has been improved and some workaround are no longer necessary. Diff against hg attached. ---------- components: Extension Modules files: curses.diff keywords: patch messages: 218140 nosy: wiz priority: normal severity: normal status: open title: NetBSD curses support improvements type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file35193/curses.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 11:04:55 2014 From: report at bugs.python.org (Thomas Klausner) Date: Fri, 09 May 2014 09:04:55 +0000 Subject: [issue21458] MirBSD support Message-ID: <1399626295.34.0.481178497239.issue21458@psf.upfronthosting.co.za> New submission from Thomas Klausner: configure needs to know about MirBSD -- it's quite similar to OpenBSD, so that's all that's needed. ---------- components: Build files: configure.diff keywords: patch messages: 218141 nosy: wiz priority: normal severity: normal status: open title: MirBSD support versions: Python 3.5 Added file: http://bugs.python.org/file35194/configure.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 11:07:28 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 09:07:28 +0000 Subject: [issue21458] MirBSD support In-Reply-To: <1399626295.34.0.481178497239.issue21458@psf.upfronthosting.co.za> Message-ID: <1399626448.03.0.591188333229.issue21458@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +skrah stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 11:08:14 2014 From: report at bugs.python.org (Thomas Klausner) Date: Fri, 09 May 2014 09:08:14 +0000 Subject: [issue21459] DragonFlyBSD support Message-ID: <1399626494.21.0.91219272779.issue21459@psf.upfronthosting.co.za> New submission from Thomas Klausner: DragonFlyBSD support needs some slight changes. ---------- components: Build files: dragonfly.diff keywords: patch messages: 218142 nosy: wiz priority: normal severity: normal status: open title: DragonFlyBSD support versions: Python 3.5 Added file: http://bugs.python.org/file35195/dragonfly.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 11:09:56 2014 From: report at bugs.python.org (Thomas Klausner) Date: Fri, 09 May 2014 09:09:56 +0000 Subject: [issue21460] distutils: use LDFLAGS Message-ID: <1399626596.81.0.202988998096.issue21460@psf.upfronthosting.co.za> New submission from Thomas Klausner: There are two possible sources for extra linker arguments: - 'extra_link_args' in Extension object - LDFLAGS environment variable The environment variable should take precedence, and any sensible compiler will give precedence to later command line args. ---------- components: Library (Lib) files: ldflags.diff keywords: patch messages: 218143 nosy: wiz priority: normal severity: normal status: open title: distutils: use LDFLAGS versions: Python 3.5 Added file: http://bugs.python.org/file35196/ldflags.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 11:10:43 2014 From: report at bugs.python.org (Thomas Klausner) Date: Fri, 09 May 2014 09:10:43 +0000 Subject: [issue21460] distutils: use LDFLAGS In-Reply-To: <1399626596.81.0.202988998096.issue21460@psf.upfronthosting.co.za> Message-ID: <1399626643.33.0.405469283933.issue21460@psf.upfronthosting.co.za> Changes by Thomas Klausner : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 11:16:03 2014 From: report at bugs.python.org (Thomas Klausner) Date: Fri, 09 May 2014 09:16:03 +0000 Subject: [issue21461] Recognize -pthread Message-ID: <1399626963.64.0.665177402844.issue21461@psf.upfronthosting.co.za> New submission from Thomas Klausner: makesetup should know about the "-pthread" compiler flag. ---------- components: Extension Modules files: pthread.diff keywords: patch messages: 218144 nosy: wiz priority: normal severity: normal status: open title: Recognize -pthread type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35197/pthread.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 11:56:10 2014 From: report at bugs.python.org (Tim Golden) Date: Fri, 09 May 2014 09:56:10 +0000 Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of os.popen In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za> Message-ID: <1399629370.5.0.567349111596.issue10752@psf.upfronthosting.co.za> Tim Golden added the comment: Here's a patch against build_ssl which uses subprocess.check_output and very slightly simplifies the output. It successfully finds ActivePerl and builds from source; and uses the svn export files when it's not. I've targetted the development branch; don't know if there's mileage in backporting. ---------- keywords: +patch Added file: http://bugs.python.org/file35198/issue10752.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 12:06:37 2014 From: report at bugs.python.org (Tim Golden) Date: Fri, 09 May 2014 10:06:37 +0000 Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of os.popen In-Reply-To: <1399629370.5.0.567349111596.issue10752@psf.upfronthosting.co.za> Message-ID: <536CA8A9.1080101@timgolden.me.uk> Tim Golden added the comment: I've just looked at issue21141 which is a substantial rework of this area. This change should be incorporated over there as well / instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 12:09:44 2014 From: report at bugs.python.org (Tim Golden) Date: Fri, 09 May 2014 10:09:44 +0000 Subject: [issue21141] Don't mention Perl in Windows build output In-Reply-To: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za> Message-ID: <1399630184.37.0.816855565967.issue21141@psf.upfronthosting.co.za> Tim Golden added the comment: I'm at least +0 on this, not because I've ever been that bothered by the Perl messages, but because it tidies things up a little smooths the way very slightly for people trying to build Python on Windows and I'm always ready to support that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 13:02:35 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 09 May 2014 11:02:35 +0000 Subject: [issue21459] DragonFlyBSD support In-Reply-To: <1399626494.21.0.91219272779.issue21459@psf.upfronthosting.co.za> Message-ID: <1399633355.05.0.9260132347.issue21459@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: What happens to Python 2.7?. Compilation fixes are OK to apply. Would be wonderful to have a DragonFlyBSD buildbot in our farm... ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 13:03:52 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 09 May 2014 11:03:52 +0000 Subject: [issue21458] MirBSD support In-Reply-To: <1399626295.34.0.481178497239.issue21458@psf.upfronthosting.co.za> Message-ID: <1399633432.11.0.181631791535.issue21458@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: What happens to Python 2.7?. Compilation fixes are OK to apply. Would be wonderful to have a MirBSD buildbot in our farm... ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 13:05:21 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 09 May 2014 11:05:21 +0000 Subject: [issue21457] NetBSD curses support improvements In-Reply-To: <1399625880.63.0.0407983839036.issue21457@psf.upfronthosting.co.za> Message-ID: <1399633521.19.0.281585518723.issue21457@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Thomas, What happens if Python is compiled in an old version of NetBSD? ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 13:27:53 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 11:27:53 +0000 Subject: [issue20745] test_statistics fails in refleak mode In-Reply-To: <1393175866.55.0.0751300817927.issue20745@psf.upfronthosting.co.za> Message-ID: <1399634873.89.0.387397009912.issue20745@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 13:53:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 09 May 2014 11:53:47 +0000 Subject: [issue21141] Don't mention Perl in Windows build output In-Reply-To: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za> Message-ID: <1399636427.69.0.866202926846.issue21141@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for this. The current messages are confusing, and I think I've already installed Perl because of them. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 13:55:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 09 May 2014 11:55:42 +0000 Subject: [issue21456] skip 2 tests in test_urllib2net.py if _ssl module not present In-Reply-To: <1399619030.67.0.271075819996.issue21456@psf.upfronthosting.co.za> Message-ID: <1399636542.41.0.466551299688.issue21456@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There isn't much point in introducing a variable named SUPPORTS_SSL, just use "ssl is not None". ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:10:04 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 09 May 2014 12:10:04 +0000 Subject: [issue21141] Don't mention Perl in Windows build output In-Reply-To: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za> Message-ID: <1399637404.79.0.234810063775.issue21141@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch looks fine to me, including the renaming. Please apply. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:12:07 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 09 May 2014 12:12:07 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL Message-ID: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> New submission from Nick Coghlan: PEP 466 includes updating to a newer version of OpenSSL. This may be needed for the ssl module feature backports in issue 21308. ---------- components: Windows messages: 218154 nosy: loewis, ncoghlan, steve.dower priority: normal severity: normal status: open title: PEP 466: upgrade OpenSSL type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:12:37 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 09 May 2014 12:12:37 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1399637557.17.0.67117586785.issue21462@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- components: +Build title: PEP 466: upgrade OpenSSL -> PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:17:43 2014 From: report at bugs.python.org (Francisco Gracia) Date: Fri, 09 May 2014 12:17:43 +0000 Subject: [issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open In-Reply-To: <1324260829.97.0.644849663035.issue13630@psf.upfronthosting.co.za> Message-ID: <1399637863.57.0.895735167454.issue13630@psf.upfronthosting.co.za> Francisco Gracia added the comment: The neat program *redemo.py* toggles between *Highlight first match* and *Highlight all matches*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:20:46 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:20:46 +0000 Subject: [issue20745] test_statistics fails in refleak mode In-Reply-To: <1393175866.55.0.0751300817927.issue20745@psf.upfronthosting.co.za> Message-ID: <1399638045.98.0.239385151.issue20745@psf.upfronthosting.co.za> Ezio Melotti added the comment: #20746 seems to have a patch for this. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:22:12 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:22:12 +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: <1399638132.6.0.163728132236.issue20780@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:27:55 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 12:27:55 +0000 Subject: [issue21459] DragonFlyBSD support In-Reply-To: <1399626494.21.0.91219272779.issue21459@psf.upfronthosting.co.za> Message-ID: <1399638475.22.0.499008074062.issue21459@psf.upfronthosting.co.za> Brett Cannon added the comment: We've actually moved away from maintaining OS support in Python itself except for major platforms. We prefer that people maintain a patch set on bitbucket, github, etc. and get the community to help support that platform. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:28:09 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 12:28:09 +0000 Subject: [issue21458] MirBSD support In-Reply-To: <1399626295.34.0.481178497239.issue21458@psf.upfronthosting.co.za> Message-ID: <1399638489.32.0.341085257889.issue21458@psf.upfronthosting.co.za> Brett Cannon added the comment: We've actually been moving away from maintaining OS support in Python itself except for major platforms. We prefer that people maintain a patch set on bitbucket, github, etc. and get the community to help support that platform. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:35:12 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 12:35:12 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1399638912.96.0.611537227577.issue14019@psf.upfronthosting.co.za> Brett Cannon added the comment: Francisco, can you sign the contributor agreement? https://www.python.org/psf/contrib/contrib-form/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:40:56 2014 From: report at bugs.python.org (Tal Einat) Date: Fri, 09 May 2014 12:40:56 +0000 Subject: [issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open In-Reply-To: <1324260829.97.0.644849663035.issue13630@psf.upfronthosting.co.za> Message-ID: <1399639256.31.0.838483026495.issue13630@psf.upfronthosting.co.za> Tal Einat added the comment: Indeed, redemo.py does include this feature. But it is a completely different application with a very specific goal - testing regular expressions. On the other hand, IDLE's search is meant to be used to find pieces of code in the editor, which is a significantly different use case. Since SearchBar always sets the pointer to the first match, as well as highlighting it, there would no real point to only mark the first match. As for disabling the marking of all other matches (besides the first), what is the point? Does marking all other hits really have any downsides? To me it seems like a useful feature that users will easily grow accustomed to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:41:29 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 12:41:29 +0000 Subject: [issue21226] PyImport_ExecCodeModuleObject not setting module attributes In-Reply-To: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za> Message-ID: <1399639289.6.0.00942605985105.issue21226@psf.upfronthosting.co.za> Brett Cannon added the comment: LGTM although you forgot to use a loader instance instead of the class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:45:58 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:45:58 +0000 Subject: [issue20815] ipaddress unit tests PEP8 In-Reply-To: <1393675292.33.0.0800271368289.issue20815@psf.upfronthosting.co.za> Message-ID: <1399639558.85.0.449189733728.issue20815@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> commit review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:48:04 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:48:04 +0000 Subject: [issue20826] Faster implementation to collapse consecutive ip-networks In-Reply-To: <1393771140.68.0.719869740699.issue20826@psf.upfronthosting.co.za> Message-ID: <1399639684.92.0.431313101043.issue20826@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:49:13 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:49:13 +0000 Subject: [issue20837] Ambiguity words in base64 documentation In-Reply-To: <1393803500.52.0.641070246037.issue20837@psf.upfronthosting.co.za> Message-ID: <1399639753.24.0.0382057306993.issue20837@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:51:21 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:51:21 +0000 Subject: [issue20840] AttributeError: 'module' object has no attribute 'ArgumentParser' In-Reply-To: <1393837548.4.0.445191461545.issue20840@psf.upfronthosting.co.za> Message-ID: <1399639881.67.0.80067553983.issue20840@psf.upfronthosting.co.za> Ezio Melotti added the comment: Closing for lack of feedback. Feel free to re-open if/when more info are available. ---------- nosy: +ezio.melotti status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:53:59 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:53:59 +0000 Subject: [issue20847] asyncio docs should call out that network logging is a no-no In-Reply-To: <1393877540.32.0.826428021059.issue20847@psf.upfronthosting.co.za> Message-ID: <1399640039.04.0.772789363431.issue20847@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Documentation stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:55:10 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:55:10 +0000 Subject: [issue20851] Update devguide to cover testing from a tarball In-Reply-To: <1393944432.91.0.924701829685.issue20851@psf.upfronthosting.co.za> Message-ID: <1399640110.43.0.105215234873.issue20851@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:55:31 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:55:31 +0000 Subject: [issue20853] pdb "args" crashes when an arg is not printable In-Reply-To: <1394016357.17.0.646134871451.issue20853@psf.upfronthosting.co.za> Message-ID: <1399640131.75.0.860176551791.issue20853@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 14:55:56 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 May 2014 12:55:56 +0000 Subject: [issue20859] Context of documentation for conditional expressions In-Reply-To: <1394131680.82.0.565875959506.issue20859@psf.upfronthosting.co.za> Message-ID: <1399640156.02.0.328387432438.issue20859@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 15:31:02 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 13:31:02 +0000 Subject: [issue21459] DragonFlyBSD support In-Reply-To: <1399626494.21.0.91219272779.issue21459@psf.upfronthosting.co.za> Message-ID: <1399642262.92.0.562205744126.issue21459@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 15:31:10 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 13:31:10 +0000 Subject: [issue21458] MirBSD support In-Reply-To: <1399626295.34.0.481178497239.issue21458@psf.upfronthosting.co.za> Message-ID: <1399642270.16.0.481068113129.issue21458@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 15:49:40 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 13:49:40 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1399643380.44.0.564375778302.issue14019@psf.upfronthosting.co.za> Brett Cannon added the comment: I added some review comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 16:10:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 May 2014 14:10:16 +0000 Subject: [issue21141] Don't mention Perl in Windows build output In-Reply-To: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za> Message-ID: <3gQD2Z6lHRz7LkD@mail.python.org> Roundup Robot added the comment: New changeset 9ef99fafaadd by Zachary Ware in branch 'default': Issue #21141: The Windows build process no longer attempts to find Perl, http://hg.python.org/cpython/rev/9ef99fafaadd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 16:12:11 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 09 May 2014 14:12:11 +0000 Subject: [issue21141] Don't mention Perl in Windows build output In-Reply-To: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za> Message-ID: <1399644731.75.0.86301895494.issue21141@psf.upfronthosting.co.za> Zachary Ware added the comment: Committed. Thanks for the review, Martin, and for the votes of confidence Tim and Antoine! ---------- assignee: -> zach.ware resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 16:23:22 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 09 May 2014 14:23:22 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za> Message-ID: <1399645402.41.0.659959483449.issue21037@psf.upfronthosting.co.za> Stefan Krah added the comment: The VM is set up. It's on an external unreliable host though. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 16:38:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 May 2014 14:38:07 +0000 Subject: [issue21157] Update imp docs for a PEP 451 world In-Reply-To: <1396636712.05.0.464506869774.issue21157@psf.upfronthosting.co.za> Message-ID: <3gQDfk54zqz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 9809a791436d by Brett Cannon in branch '3.4': Issue #21157: Touch up imp docs to be more explicit about importlib http://hg.python.org/cpython/rev/9809a791436d New changeset 418780d59502 by Brett Cannon in branch 'default': Merge for issue #21157 http://hg.python.org/cpython/rev/418780d59502 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 16:38:27 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 14:38:27 +0000 Subject: [issue21157] Update imp docs for a PEP 451 world In-Reply-To: <1396636712.05.0.464506869774.issue21157@psf.upfronthosting.co.za> Message-ID: <1399646307.97.0.52117371994.issue21157@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 16:48:15 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 09 May 2014 14:48:15 +0000 Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of os.popen In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za> Message-ID: <1399646895.69.0.0732690701451.issue10752@psf.upfronthosting.co.za> Zachary Ware added the comment: The patch looks good to me (only tested on a Perl-less machine, though). It applies cleanly on 3.4, which I think is worth committing. It still merges forward cleanly to default, post-#21141. I suspect it would even apply fairly cleanly to 2.7, but I'm not too worried about that backport. ---------- assignee: -> tim.golden stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 17:02:31 2014 From: report at bugs.python.org (Lukas Vacek) Date: Fri, 09 May 2014 15:02:31 +0000 Subject: [issue19186] expat symbols should be namespaced in pyexpat again In-Reply-To: <1381151097.4.0.844657685559.issue19186@psf.upfronthosting.co.za> Message-ID: <1399647751.85.0.65628687649.issue19186@psf.upfronthosting.co.za> Lukas Vacek added the comment: Hi Peter, Thanks for taking the time to report your issue. I just tried on fresh up-to-date CentOS 6 and I could not reproduce the issue. However, I think I figured out what went wrong. I can see you are supplying custom -I and -L paths (-I/apps/prod/releases/3.0/include ...) I suspect that when compiling pyexpat.c (in Modules/) the header file expat.h is picked up from this location before the bundled expat.h (in Modules/expat/) is found. But when compiling xmlparse.c (in Modules/expat/) the bundled header file expat.h *is* used this time. So we end up with our bundled expat compiled using namespacing and so defining symbols like PyExpat_XML_SetCommentHandler while pyexpat.c is looking for XML_SetCommentHandler because it is compiled *not* using our bundled expat.h. I am not sure yet why your custom "-I" comes before "-I/ae/data/soft/opensource/build/python3/master/Python-3.4.0/Modules/expat" as it certainly should not. So far I tried building with CPPFLAGS and CFLAGS and in both cases my custom paths come after "-I.../Modules/expat" as it should. Can you please provide your ./configure and make command lines and relevant environment variables? Thanks, Lucas ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 17:09:08 2014 From: report at bugs.python.org (Erik Bray) Date: Fri, 09 May 2014 15:09:08 +0000 Subject: [issue21463] RuntimeError when URLopener.ftpcache is full Message-ID: <1399648148.16.0.0636585278112.issue21463@psf.upfronthosting.co.za> New submission from Erik Bray: This is probably a pretty rare corner case, but a coworker reported this to me while testing code that does open several ftp connections to different files. ---------- components: Library (Lib) files: urllib-request-ftpcache-error.patch keywords: patch messages: 218170 nosy: erik.bray priority: normal severity: normal status: open title: RuntimeError when URLopener.ftpcache is full type: crash Added file: http://bugs.python.org/file35199/urllib-request-ftpcache-error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 17:16:57 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 09 May 2014 15:16:57 +0000 Subject: [issue21463] RuntimeError when URLopener.ftpcache is full In-Reply-To: <1399648148.16.0.0636585278112.issue21463@psf.upfronthosting.co.za> Message-ID: <1399648617.8.0.940282641791.issue21463@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 17:28:28 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 09 May 2014 15:28:28 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1399649308.94.0.282467129898.issue21462@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's all the patch that should be necessary to do the upgrade. Running test_ssl on 2.7 with 1.0.1g I do have a failure: ====================================================================== ERROR: test_socketserver (test.test_ssl.ThreadedTests) Using a SocketServer to create and manage SSL connections. ---------------------------------------------------------------------- Traceback (most recent call last): File "P:\ath\to\2.7\cpython\lib\test\test_ssl.py", line 1179, in test_socketserver f = urllib.urlopen(url) File "P:\ath\to\2.7\cpython\lib\urllib.py", line 87, in urlopen return opener.open(url) File "P:\ath\to\2.7\cpython\lib\urllib.py", line 208, in open return getattr(self, name)(url) File "P:\ath\to\2.7\cpython\lib\urllib.py", line 437, in open_https h.endheaders(data) File "P:\ath\to\2.7\cpython\lib\httplib.py", line 969, in endheaders self._send_output(message_body) File "P:\ath\to\2.7\cpython\lib\httplib.py", line 829, in _send_output self.send(msg) File "P:\ath\to\2.7\cpython\lib\httplib.py", line 791, in send self.connect() File "P:\ath\to\2.7\cpython\lib\httplib.py", line 1176, in connect self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file) File "P:\ath\to\2.7\cpython\lib\ssl.py", line 392, in wrap_socket ciphers=ciphers) File "P:\ath\to\2.7\cpython\lib\ssl.py", line 148, in __init__ self.do_handshake() File "P:\ath\to\2.7\cpython\lib\ssl.py", line 310, in do_handshake self._sslobj.do_handshake() IOError: [Errno socket error] [Errno 1] _ssl.c:510: error:140770FC:SSL routines: SSL23_GET_SERVER_HELLO:unknown protocol ---------------------------------------------------------------------- But this looks closely related to a failure that I have on this machine using 3.4 (which is probably the fault of the way this network is set up): ====================================================================== ERROR: test_socketserver (test.test_ssl.ThreadedTests) Using a SocketServer to create and manage SSL connections. ---------------------------------------------------------------------- Traceback (most recent call last): File "P:\ath\to\3.4\cpython\lib\urllib\request.py", line 1189, in do_open h.request(req.get_method(), req.selector, req.data, headers) File "P:\ath\to\3.4\cpython\lib\http\client.py", line 1090, in request self._send_request(method, url, body, headers) File "P:\ath\to\3.4\cpython\lib\http\client.py", line 1128, in _send_request self.endheaders(body) File "P:\ath\to\3.4\cpython\lib\http\client.py", line 1086, in endheaders self._send_output(message_body) File "P:\ath\to\3.4\cpython\lib\http\client.py", line 924, in _send_output self.send(msg) File "P:\ath\to\3.4\cpython\lib\http\client.py", line 859, in send self.connect() File "P:\ath\to\3.4\cpython\lib\http\client.py", line 1221, in connect super().connect() File "P:\ath\to\3.4\cpython\lib\http\client.py", line 839, in connect self._tunnel() File "P:\ath\to\3.4\cpython\lib\http\client.py", line 822, in _tunnel message.strip())) OSError: Tunnel connection failed: 403 Forbidden During handling of the above exception, another exception occurred: Traceback (most recent call last): File "P:\ath\to\3.4\cpython\lib\test\test_ssl.py",line 2315, in test_socketserver f = urllib.request.urlopen(url) File "P:\ath\to\3.4\cpython\lib\urllib\request.py", line 153, in urlopen return opener.open(url, data, timeout) File "P:\ath\to\3.4\cpython\lib\urllib\request.py", line 455, in open response = self._open(req, data) File "P:\ath\to\3.4\cpython\lib\urllib\request.py", line 473, in _open '_open', req) File "P:\ath\to\3.4\cpython\lib\urllib\request.py", line 433, in _call_chain result = func(*args) File "P:\ath\to\3.4\cpython\lib\urllib\request.py", line 1230, in https_open context=self._context, check_hostname=self._check_hostname) File "P:\ath\to\3.4\cpython\lib\urllib\request.py", line 1192, in do_open raise URLError(err) urllib.error.URLError: ---------------------------------------------------------------------- As such, I'll leave it to someone else to properly test this before committing. ---------- keywords: +patch nosy: +zach.ware Added file: http://bugs.python.org/file35200/issue21462.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 17:55:16 2014 From: report at bugs.python.org (Lukas Vacek) Date: Fri, 09 May 2014 15:55:16 +0000 Subject: [issue19186] expat symbols should be namespaced in pyexpat again In-Reply-To: <1381151097.4.0.844657685559.issue19186@psf.upfronthosting.co.za> Message-ID: <1399650916.13.0.323044295506.issue19186@psf.upfronthosting.co.za> Lukas Vacek added the comment: Actually CFLAGS do indeed come before any include directories. I can reproduce your problem: mkdir /tmp/extra_include cp /usr/include/expat.h /usr/include/expat_external.h /tmp/extra_include/ make CFLAGS="-I/tmp/extra_include" You should use CPPFLAGS for extra include directories. Not an issue in CPython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 17:56:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 May 2014 15:56:14 +0000 Subject: [issue21438] Document which importlib.machinery loaders don't require an argument for load_module() In-Reply-To: <1399297122.37.0.213732682658.issue21438@psf.upfronthosting.co.za> Message-ID: <3gQGNt1JXCz7LkW@mail.python.org> Roundup Robot added the comment: New changeset 86042348b38a by Brett Cannon in branch '3.4': Issue #21438: Document what loaders don't require a module name for http://hg.python.org/cpython/rev/86042348b38a New changeset e9453f6fa787 by Brett Cannon in branch 'default': Merge for issue #21438 http://hg.python.org/cpython/rev/e9453f6fa787 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 17:56:26 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 15:56:26 +0000 Subject: [issue21438] Document which importlib.machinery loaders don't require an argument for load_module() In-Reply-To: <1399297122.37.0.213732682658.issue21438@psf.upfronthosting.co.za> Message-ID: <1399650986.76.0.563926446865.issue21438@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 18:28:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 May 2014 16:28:29 +0000 Subject: [issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader In-Reply-To: <1396634360.22.0.98257221553.issue21156@psf.upfronthosting.co.za> Message-ID: <3gQH6500f5z7LjR@mail.python.org> Roundup Robot added the comment: New changeset 9bd844792b32 by Brett Cannon in branch 'default': Issue #21156: importlib.abc.InspectLoader.source_to_code() is now a http://hg.python.org/cpython/rev/9bd844792b32 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 18:29:21 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 16:29:21 +0000 Subject: [issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader In-Reply-To: <1396634360.22.0.98257221553.issue21156@psf.upfronthosting.co.za> Message-ID: <1399652961.57.0.283978179365.issue21156@psf.upfronthosting.co.za> Brett Cannon added the comment: I decided to make it a static method instead of relocating it. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 18:35:10 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 09 May 2014 16:35:10 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1399653310.74.0.800544844369.issue21462@psf.upfronthosting.co.za> Steve Dower added the comment: I just tried it and had no trouble building and running the ssl tests on Windows. > python Lib\test\regrtest.py -u network -v test_ssl > ... > Ran 38 tests in 7.700s > > OK (skipped=2) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:03:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 May 2014 17:03:20 +0000 Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of os.popen In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za> Message-ID: <3gQHtH4nt4z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 160f32753b0c by Tim Golden in branch '3.4': Issue10752 Be more robust when finding a PERL interpreter to build OpenSSL. Initial patch by Gabi Davar http://hg.python.org/cpython/rev/160f32753b0c New changeset e492d0ac9abb by Tim Golden in branch 'default': Issue10752 Be more robust when finding a PERL interpreter to build OpenSSL. Initial patch by Gabi Davar http://hg.python.org/cpython/rev/e492d0ac9abb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:05:02 2014 From: report at bugs.python.org (Tim Golden) Date: Fri, 09 May 2014 17:05:02 +0000 Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of os.popen In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za> Message-ID: <1399655102.31.0.718899085844.issue10752@psf.upfronthosting.co.za> Tim Golden added the comment: Thanks for the check. Committed to 3.4 & default ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:05:50 2014 From: report at bugs.python.org (Tim Golden) Date: Fri, 09 May 2014 17:05:50 +0000 Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of os.popen In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za> Message-ID: <1399655150.05.0.358320313373.issue10752@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:11:36 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 09 May 2014 17:11:36 +0000 Subject: [issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path In-Reply-To: <1399539822.8.0.0455279031899.issue21452@psf.upfronthosting.co.za> Message-ID: <1399655496.92.0.427837485185.issue21452@psf.upfronthosting.co.za> Zachary Ware added the comment: Your patch looks fine to me, Tim. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:16:30 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 09 May 2014 17:16:30 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1399655790.38.0.61514984392.issue21462@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks, Steve. Nick, I assume 1.0.1g is the target version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:19:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 May 2014 17:19:55 +0000 Subject: [issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path In-Reply-To: <1399539822.8.0.0455279031899.issue21452@psf.upfronthosting.co.za> Message-ID: <3gQJFQ0d53z7Ljv@mail.python.org> Roundup Robot added the comment: New changeset 469837abe5ca by Tim Golden in branch '3.4': Issue21452 Add missing backslash to build path for make_buildinfo http://hg.python.org/cpython/rev/469837abe5ca New changeset a14420d8b556 by Tim Golden in branch 'default': Issue21452 Add missing backslash to build path for make_buildinfo http://hg.python.org/cpython/rev/a14420d8b556 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:20:18 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 09 May 2014 17:20:18 +0000 Subject: [issue21458] MirBSD support In-Reply-To: <1399626295.34.0.481178497239.issue21458@psf.upfronthosting.co.za> Message-ID: <1399656018.08.0.786838471151.issue21458@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Brett, where is the list of "major platforms", and how to get in/out of that list? :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:21:16 2014 From: report at bugs.python.org (Tim Golden) Date: Fri, 09 May 2014 17:21:16 +0000 Subject: [issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path In-Reply-To: <1399539822.8.0.0455279031899.issue21452@psf.upfronthosting.co.za> Message-ID: <1399656076.64.0.0504024076762.issue21452@psf.upfronthosting.co.za> Tim Golden added the comment: Fixed. Thanks for the report ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:25:31 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Fri, 09 May 2014 17:25:31 +0000 Subject: [issue20934] test_multiprocessing is broken by design In-Reply-To: <1394872735.24.0.583669310043.issue20934@psf.upfronthosting.co.za> Message-ID: <1399656331.79.0.657794049612.issue20934@psf.upfronthosting.co.za> Changes by ddvento at ucar.edu : ---------- nosy: +ddvento at ucar.edu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:27:03 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 09 May 2014 17:27:03 +0000 Subject: [issue21434] python -3 documentation is outdated In-Reply-To: <1399281658.38.0.402381658113.issue21434@psf.upfronthosting.co.za> Message-ID: <1399656423.17.0.234322684401.issue21434@psf.upfronthosting.co.za> ?ric Araujo added the comment: Aside: callable was added back in 3.2; warnings for that are now obsolete, and people often replaced it with bogus alternatives (like using hasattr on the object instead of its type). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:31:42 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 09 May 2014 17:31:42 +0000 Subject: [issue21439] Numerous minor issues in Language Reference In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> Message-ID: <1399656702.83.0.164562970403.issue21439@psf.upfronthosting.co.za> ?ric Araujo added the comment: Attaching plain text version. ---------- nosy: +eric.araujo Added file: http://bugs.python.org/file35201/PythonRefmanual_3_4_0_Errata.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:36:21 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 09 May 2014 17:36:21 +0000 Subject: [issue21439] Numerous minor issues in Language Reference In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> Message-ID: <1399656981.5.0.469928291148.issue21439@psf.upfronthosting.co.za> ?ric Araujo added the comment: BTW my opinion of the proposed changes is that many of them are good (obvious typos, reports of things unclear to a beginner, etc) but I don?t agree with some typographic changes, I find that some grammar changes are pedantic, and there are even a few misunderstandings of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:38:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 May 2014 17:38:20 +0000 Subject: [issue20776] Add tests for importlib.machinery.PathFinder In-Reply-To: <1393373351.13.0.19162591832.issue20776@psf.upfronthosting.co.za> Message-ID: <3gQJfg28jtz7LjR@mail.python.org> Roundup Robot added the comment: New changeset fa439bb9d705 by Brett Cannon in branch 'default': Issue #20776: Flesh out tests for importlib.machinery.PathFinder. http://hg.python.org/cpython/rev/fa439bb9d705 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:38:40 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 09 May 2014 17:38:40 +0000 Subject: [issue21463] RuntimeError when URLopener.ftpcache is full In-Reply-To: <1399648148.16.0.0636585278112.issue21463@psf.upfronthosting.co.za> Message-ID: <1399657120.16.0.553664165039.issue21463@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report and patch. Would you mind adding a unit test? (Note that the ?crash? type is for segfaults, not Python exceptions.) ---------- nosy: +eric.araujo stage: -> test needed type: crash -> behavior versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:38:54 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 17:38:54 +0000 Subject: [issue20776] Add tests for importlib.machinery.PathFinder In-Reply-To: <1393373351.13.0.19162591832.issue20776@psf.upfronthosting.co.za> Message-ID: <1399657134.24.0.274720917727.issue20776@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 19:57:12 2014 From: report at bugs.python.org (Erik Bray) Date: Fri, 09 May 2014 17:57:12 +0000 Subject: [issue21463] RuntimeError when URLopener.ftpcache is full In-Reply-To: <1399648148.16.0.0636585278112.issue21463@psf.upfronthosting.co.za> Message-ID: <1399658232.1.0.524811217848.issue21463@psf.upfronthosting.co.za> Erik Bray added the comment: Ah, didn't know that about "crash". I wanted to add a test but hesitated only because that code is not well tested to begin with (perhaps, hence, this going unnoticed for so long). But I guess it could be done by mocking the ftpwrapper class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 20:33:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 May 2014 18:33:04 +0000 Subject: [issue19721] Move all test_importlib utility code into test_importlib.util In-Reply-To: <1385147457.8.0.6225076975.issue19721@psf.upfronthosting.co.za> Message-ID: <3gQKsq753rz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 4e243b399307 by Brett Cannon in branch 'default': Issue #19721: Consolidate test_importlib utility code into a single http://hg.python.org/cpython/rev/4e243b399307 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 20:33:16 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 18:33:16 +0000 Subject: [issue19721] Move all test_importlib utility code into test_importlib.util In-Reply-To: <1385147457.8.0.6225076975.issue19721@psf.upfronthosting.co.za> Message-ID: <1399660396.42.0.0901769035815.issue19721@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 20:35:11 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 May 2014 18:35:11 +0000 Subject: [issue21237] Update Python 2/3 porting HOWTO's suggestion for dealing with map() In-Reply-To: <1397576750.55.0.0117658136784.issue21237@psf.upfronthosting.co.za> Message-ID: <1399660511.57.0.337031300796.issue21237@psf.upfronthosting.co.za> Brett Cannon added the comment: I never bothered to mention the iter* methods in the HOWTO, and since it becomes very obvious very fast to tweak them I'm not going to worry about it and add more complexity to the doc. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 20:49:54 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 09 May 2014 18:49:54 +0000 Subject: [issue21037] add an AddressSanitizer build option In-Reply-To: <1395581927.59.0.22052744693.issue21037@psf.upfronthosting.co.za> Message-ID: <1399661394.2.0.593904065934.issue21037@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: OK, great, let's see what happens! ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 20:55:42 2014 From: report at bugs.python.org (Tim Golden) Date: Fri, 09 May 2014 18:55:42 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1399661742.57.0.939712859555.issue21462@psf.upfronthosting.co.za> Tim Golden added the comment: Builds & tests ok here on a fresh checkout (of cpython & openssl-1.0.1g) ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 20:57:29 2014 From: report at bugs.python.org (Tim Peters) Date: Fri, 09 May 2014 18:57:29 +0000 Subject: [issue21435] Segfault in gc with cyclic trash In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399661849.3.0.618014335872.issue21435@psf.upfronthosting.co.za> Tim Peters added the comment: @asvetlov, glad this fixes crashes in aiohttp library tests too, but I hadn't heard about that before. Is there an open bug report about it on this tracker (so we can close it)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 21:48:52 2014 From: report at bugs.python.org (ddvento@ucar.edu) Date: Fri, 09 May 2014 19:48:52 +0000 Subject: [issue21278] Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed In-Reply-To: <53581CC1.8010705@ucar.edu> Message-ID: <536D312A.5050503@ucar.edu> ddvento at ucar.edu added the comment: This bug is extremely hard to reproduce in a controlled manner. I mean, if I run EXTRATESTOPTS='-x test_gdb -uall -v' make testall it appears 100% of the times (whereas the same command without the -v works just fine, as I initially mentioned). But I do not want to run the whole thing, so I resorted to EXTRATESTOPTS='-uall -v -f ctypes_and_zipimport' make testall where the ctypes_and_zipimport file contains test_ctypes, test_zipimport and a handful of other tests. For all the tries I did, this always succeeded. So I can't debug this issue, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 22:15:29 2014 From: report at bugs.python.org (Steven Barker) Date: Fri, 09 May 2014 20:15:29 +0000 Subject: [issue21389] The repr of BoundMethod objects sometimes incorrectly identifies the bound function In-Reply-To: <1398824801.68.0.416059453762.issue21389@psf.upfronthosting.co.za> Message-ID: <1399666529.37.0.607805115427.issue21389@psf.upfronthosting.co.za> Steven Barker added the comment: Here's a patch that changes the behavior of method_repr in Objects/classobject.c . It first tries to use __func__.__qualname__, then tries __func__.__name__ as a fallback and finally uses "?" if neither of those attributes are available. I'm not sure if the __name__ fallback is tested (as it seems that pretty much all callables have __qualname__ these days). The last "?" case actually does get tested by Lib/test/test_descr.py which creates a messed up method with classmethod(1).__get__(1) (which oddly does not raise an error immediately upon creation, but rather only when it is called). I've not written C in several years, so please let me know if you see I've done something obviously wrong, or any places the patch could be improved. It is mostly a copy-and-paste of existing code with a few modifications and deletions, so hopefully I can't have messed up anything too badly! I'm currently ignoring a comment in the code that says we "shouldn't use repr()/%R" to format __self__. I don't really understand that, so I've stick with the existing behavior on that front. If that is something that should change, I'd be happy to try reworking it in some other way, just let me know what the concern is. Here are some examples of the new repr output in a build with the patch: >>> class A(): ... def foo(self): ... pass ... >>> class B(A): ... def foo(self): ... pass ... >>> class C(A): ... pass ... >>> class D(): ... @classmethod ... def bar(): ... pass ... >>> A().foo > >>> B().foo > >>> C().foo > >>> super(B, B()).foo > >>> D.bar > ---------- keywords: +patch versions: +Python 3.5 Added file: http://bugs.python.org/file35202/method_repr.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 22:29:21 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 09 May 2014 20:29:21 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399404013.42.0.0957567548326.issue21448@psf.upfronthosting.co.za> Message-ID: <1399667361.42.0.934984161015.issue21448@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 23:02:16 2014 From: report at bugs.python.org (Cybjit) Date: Fri, 09 May 2014 21:02:16 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1399669336.51.0.808023904281.issue7776@psf.upfronthosting.co.za> Cybjit added the comment: I get errors when using pip with a proxy in 3.4.1rc1 on Windows, that does not happen on 3.4.0. I tracked it down to this change to client.py. OK with client.py from fd2c69cedb25, but not with client.py from 39ee3286d187. C:\Python34\Scripts>set HTTP_PROXY=http://openwrt.lan:8888 C:\Python34\Scripts>set HTTPS_PROXY=http://openwrt.lan:8888 C:\Python34\Scripts>pip -v install simplejson Downloading/unpacking simplejson Could not fetch URL https://pypi.python.org/simple/simplejson/: connection err or: hostname 'openwrt.lan' doesn't match either of '*.c.ssl.fastly.net', 'c.ssl. fastly.net', '*.target.com', '*.vhx.tv', '*.snappytv.com', '*.atlassian.net', 'p laces.hoteltonight.com', 'secure.lessthan3.com', '*.atlassian.com', 'a.sellpoint .net', 'cdn.upthere.com', '*.tissuu.com', '*.issuu.com', '*.kekofan.com', '*.pyt hon.org', '*.theverge.com', '*.sbnation.com', '*.polygon.com', '*.twobrightlight s.com', '*.2brightlights.info', '*.vox.com', 'staging-cdn.upthere.com', '*.zeebo x.com', '*.beamly.com', '*.aticpan.org', 'stream.svc.7digital.net', 'stream-test .svc.7digital.net', '*.articulate.com', 's.t.st', 'vid.thestreet.com', '*.planet -labs.com', '*.url2png.com', 'turn.com', 'www.turn.com', 'rivergathering.org', ' social.icfglobal2014-europe.org', '*.innogamescdn.com', '*.pathable.com', '*.sta ging.pathable.com', '*.kickstarter.com', 'sparkingchange.org', 'www.swedavia.se' , 'www.swedavia.com', 'js-agent.newrelic.com', '*.fastly-streams.com', 'cdn.bran disty.com', 'fastly.hightailcdn.com', '*.fl.yelpcdn.com', '*.feedmagnet.com', 'a pi.contentbody.com', '*.acquia.com', '*.swarmapp.com', '*.lonny.com', '*.stylebi stro.com', '*.zimbio.com', '*.pypa.io', 'pypa.io', 'static.qbranch.se', '*.krxd. net', '*.room.co', '*.metrological.com', 'room.co', 'www.ibmserviceengage.com', 'my.ibmserviceengage.com', 'cdn.evbuc.com', 'cdn.adagility.com' Will skip URL https://pypi.python.org/simple/simplejson/ when looking for down load links for simplejson ---------- nosy: +Cybjit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 23:24:07 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Fri, 09 May 2014 21:24:07 +0000 Subject: [issue21464] fnmatch module uses undefined regular expression to perform matching Message-ID: <1399670647.23.0.136590413111.issue21464@psf.upfronthosting.co.za> New submission from Paul Sokolovsky: fnmatch.translate() ends with: return res + '\Z(?ms)' However, https://docs.python.org/3.4/library/re.html#regular-expression-syntax states: Note that the (?x) flag changes how the expression is parsed. It should be used first in the expression string, or after one or more whitespace characters. If there are non-whitespace characters before the flag, the results are undefined. Hence, fnmatch uses undefined pattern, and indeed, it fails with alternative Perl-compatible regular expression implementations (specifically, PCRE, which appear to do something like apply flag at the point of its occurrence). ---------- components: Library (Lib) messages: 218198 nosy: pfalcon priority: normal severity: normal status: open title: fnmatch module uses undefined regular expression to perform matching versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 23:26:25 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Fri, 09 May 2014 21:26:25 +0000 Subject: [issue21464] fnmatch module uses regular expression with undefined result to perform matching In-Reply-To: <1399670647.23.0.136590413111.issue21464@psf.upfronthosting.co.za> Message-ID: <1399670785.56.0.605650392812.issue21464@psf.upfronthosting.co.za> Changes by Paul Sokolovsky : ---------- title: fnmatch module uses undefined regular expression to perform matching -> fnmatch module uses regular expression with undefined result to perform matching _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 23:27:13 2014 From: report at bugs.python.org (paul j3) Date: Fri, 09 May 2014 21:27:13 +0000 Subject: [issue20333] argparse subparser usage message hides main parser usage In-Reply-To: <1390322768.82.0.0490461606421.issue20333@psf.upfronthosting.co.za> Message-ID: <1399670833.12.0.0376706978903.issue20333@psf.upfronthosting.co.za> paul j3 added the comment: When `add_subparsers` creates the `_prog_prefix` it uses a list of positionals. That makes sense, since a subparser argument is positional, so the user needs to know where it fits in the broader scope of positionals. But it intentionally skips the 'optionals'. The problem in the example for this bug is that its 'optional' is 'required'. A fix is to include all 'required optionals' along with positionals in the usage prefix. Attached is a partial patch that does this. I also question whether it makes sense to include 'mutually_exclusive_groups' in this usage formatting, since all actions in such a group must be non-required. And such a group can include at most one positional (with ? or *). A MXG is marked only if all of its actions are present in the usage list. The programmer can also customize the subparsers usage with the 'prog' keyword of either the 'add_subparsers' or 'add_parser' commands. I illustrate this in the attached 'sample.py' script. 'test_argparse.py' does not seem to test this issue much. Atleast it isn't bothered by these tweaks. Note that any arguments added to the main parser after the 'add_subparsers' command will not appear the subparser usage, since this is defined when the subparsers are created. ---------- keywords: +patch Added file: http://bugs.python.org/file35203/issue20333.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 23:27:37 2014 From: report at bugs.python.org (paul j3) Date: Fri, 09 May 2014 21:27:37 +0000 Subject: [issue20333] argparse subparser usage message hides main parser usage In-Reply-To: <1390322768.82.0.0490461606421.issue20333@psf.upfronthosting.co.za> Message-ID: <1399670857.78.0.990343795497.issue20333@psf.upfronthosting.co.za> Changes by paul j3 : Added file: http://bugs.python.org/file35204/sample.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 23:50:56 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 09 May 2014 21:50:56 +0000 Subject: [issue21465] sqlite3 Row can return duplicate keys when using adapters Message-ID: <1399672256.68.0.166250570949.issue21465@psf.upfronthosting.co.za> New submission from Mark Lawrence: Code adopted from here https://docs.python.org/3/library/sqlite3.html#default-adapters-and-converters. import sqlite3 import datetime con = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_DECLTYPES|sqlite3.PARSE_COLNAMES) con.row_factory = sqlite3.Row cur = con.cursor() cur.execute("create table test(d date, ts timestamp)") today = datetime.date.today() now = datetime.datetime.now() cur.execute("insert into test(d, ts) values (?, ?)", (today, now)) cur.execute('select current_date as "d [date]", current_timestamp as "ts [timestamp]"') row = cur.fetchone() print(row.keys()) cur.execute('select current_date as "nit [date]", current_timestamp as "nit [timestamp]"') row = cur.fetchone() print(row.keys()) cur.execute('select current_date as " [date]", current_timestamp as " [timestamp]"') row = cur.fetchone() print(row.keys()) Output --- c:\Users\Mark\MyPython>sqlite3_error.py ['d', 'ts'] ['nit', 'nit'] ['', ''] This clearly defeats the purpose of using keys to access the given columns. Hardly a show stopper but I thought I'd flag it up. ---------- components: Library (Lib) messages: 218200 nosy: BreamoreBoy priority: normal severity: normal status: open title: sqlite3 Row can return duplicate keys when using adapters type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 23:56:36 2014 From: report at bugs.python.org (Thomas Klausner) Date: Fri, 09 May 2014 21:56:36 +0000 Subject: [issue21457] NetBSD curses support improvements In-Reply-To: <1399625880.63.0.0407983839036.issue21457@psf.upfronthosting.co.za> Message-ID: <1399672596.59.0.401050364072.issue21457@psf.upfronthosting.co.za> Thomas Klausner added the comment: Thanks for your reply! I've checked: keypad in NetBSD curses was fixed in 2009. All supported NetBSD release (5.x and 6.x) have the fix. nodelay and keyname were fixed even earlier, in 2003. So this is no problem for older NetBSD releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 23:57:51 2014 From: report at bugs.python.org (Thomas Klausner) Date: Fri, 09 May 2014 21:57:51 +0000 Subject: [issue21458] MirBSD support In-Reply-To: <1399626295.34.0.481178497239.issue21458@psf.upfronthosting.co.za> Message-ID: <1399672671.06.0.609833287555.issue21458@psf.upfronthosting.co.za> Thomas Klausner added the comment: Just a final comment: MirBSD's official packaging system is pkgsrc, which is also the official packaging system for NetBSD. (This is the reason I'm sending these in bulk, to clean up local pkgsrc changes.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 9 23:58:33 2014 From: report at bugs.python.org (Thomas Klausner) Date: Fri, 09 May 2014 21:58:33 +0000 Subject: [issue21459] DragonFlyBSD support In-Reply-To: <1399626494.21.0.91219272779.issue21459@psf.upfronthosting.co.za> Message-ID: <1399672713.71.0.871090520965.issue21459@psf.upfronthosting.co.za> Thomas Klausner added the comment: Just a final comment: pkgsrc was DragonFlyBSD's official packaging system, which is also the official packaging system for NetBSD. (This is the reason I'm sending these in bulk, to clean up local pkgsrc changes.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 00:23:16 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 09 May 2014 22:23:16 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1399669336.51.0.808023904281.issue7776@psf.upfronthosting.co.za> Message-ID: <536D5551.2040402@rath.org> Nikolaus Rath added the comment: On 05/09/2014 02:02 PM, Cybjit wrote: > C:\Python34\Scripts>pip -v install simplejson > Downloading/unpacking simplejson > Could not fetch URL https://pypi.python.org/simple/simplejson/: connection err > or: hostname 'openwrt.lan' doesn't match either of '*.c.ssl.fastly.net', 'c.ssl. This looks as if pip tries to match the hostname in the certificate from pypi.python.org against the hostname of the local proxy. Looking at the code, I don't see why it would do that though. HTTPSConnection.connect definitely tries to match against the final hostname. Is pip maybe doing its own certificate check, and relying on HTTPSConnection.host to contain the final hostname rather than the proxy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 00:54:11 2014 From: report at bugs.python.org (Peter Inglesby) Date: Fri, 09 May 2014 22:54:11 +0000 Subject: [issue21435] Segfault in gc with cyclic trash In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399676051.48.0.0611735687072.issue21435@psf.upfronthosting.co.za> Peter Inglesby added the comment: It was actually through playing with aiohttp that I first hit this issue. I think I originally hit the problem with something like: import asyncio import aiohttp @asyncio.coroutine def do_work(future): response = yield from aiohttp.request('get', 'http://google.com') future.set_result(None) loop = asyncio.get_event_loop() future = asyncio.Future() asyncio.Task(do_work(future)) future.add_done_callback(print) loop.run_forever() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 02:35:06 2014 From: report at bugs.python.org (Steven Barker) Date: Sat, 10 May 2014 00:35:06 +0000 Subject: [issue21389] The repr of BoundMethod objects sometimes incorrectly identifies the bound function In-Reply-To: <1398824801.68.0.416059453762.issue21389@psf.upfronthosting.co.za> Message-ID: <1399682105.99.0.768132721109.issue21389@psf.upfronthosting.co.za> Steven Barker added the comment: Ah, I figured out why using %R may be bad. It breaks for the following silly class: class C(): def __repr__(self): return repr(self.__repr__) # or use any other bound method repr(C()) will recurse until the recursion limit is hit, both with and without my patch. If this seems like a real issue, I could probably replace the %R code with a variation on the base case code in PyObject_Repr: PyUnicode_FromFormat("<%s object at %p>", v->ob_type->tp_name, v) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 02:58:22 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 10 May 2014 00:58:22 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <3gQVQN3yRqz7Ljh@mail.python.org> Roundup Robot added the comment: New changeset b769352e2922 by Eli Bendersky in branch 'default': Issue #19655: Replace the ASDL parser carried with CPython http://hg.python.org/cpython/rev/b769352e2922 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 02:59:18 2014 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 10 May 2014 00:59:18 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1399683558.36.0.210379856722.issue19655@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 03:03:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 May 2014 01:03:08 +0000 Subject: [issue21425] Python 3 pipe handling breaks python mode in emacs on Windows In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399683788.43.0.696304304354.issue21425@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 03:06:47 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 May 2014 01:06:47 +0000 Subject: [issue21427] installer not working In-Reply-To: <1399217925.98.0.594848268677.issue21427@psf.upfronthosting.co.za> Message-ID: <1399684007.45.0.44002066713.issue21427@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I compile 32 bit debug binaries from repository with the free VC++ express 2010. I presume the 'install' option works. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 03:14:04 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 May 2014 01:14:04 +0000 Subject: [issue21439] Numerous minor issues in Language Reference In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> Message-ID: <1399684444.76.0.556085973276.issue21439@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I suggest at least a patch per chapter (3.x.y, 4.x.y, 6.x.y, ...). ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 04:03:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 10 May 2014 02:03:24 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <3gQWsR39KCz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 604e1b1a7777 by Eli Bendersky in branch 'default': Issue #19655: Add tests for the new asdl parser. http://hg.python.org/cpython/rev/604e1b1a7777 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 09:29:43 2014 From: report at bugs.python.org (Alok Singhal) Date: Sat, 10 May 2014 07:29:43 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1399706983.81.0.988277051244.issue6305@psf.upfronthosting.co.za> Alok Singhal added the comment: Uploading another patch which is the same as the last patch but this one applies cleanly after the latest islice changes for #21321. ---------- Added file: http://bugs.python.org/file35205/islice_large_values-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 09:45:43 2014 From: report at bugs.python.org (Cybjit) Date: Sat, 10 May 2014 07:45:43 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1399707943.51.0.955940492265.issue7776@psf.upfronthosting.co.za> Cybjit added the comment: On 2014-05-10 00:23, nikratio wrote: > Is pip maybe doing its own certificate check, and relying on > HTTPSConnection.host to contain the final hostname rather than the proxy? I think the culprit might be here https://github.com/pypa/pip/blob/1.5.4/pip/_vendor/requests/packages/urllib3/connection.py#L172 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 10:41:56 2014 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 10 May 2014 08:41:56 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1399711316.5.0.697113454273.issue19655@psf.upfronthosting.co.za> Stefan Behnel added the comment: The "avoid rebuilding" part doesn't seem to work for me. Source build currently fails as follows: """ /bin/mkdir -p Include python ./Parser/asdl_c.py -h Include ./Parser/Python.asdl # Substitution happens here, as the completely-expanded BINDIR # is not available in configure sed -e "s, at EXENAME@,.../INSTALL/py3km/bin/python3.5dm," < ./Misc/python-config.in >python-config.py # Replace makefile compat. variable references with shell script compat. ones; -> sed -e 's,\$(\([A-Za-z0-9_]*\)),\$\{\1\},g' < Misc/python-config.sh >python-config # On Darwin, always use the python version of the script, the shell # version doesn't use the compiler customizations that are provided # in python (_osx_support.py). if test `uname -s` = Darwin; then \ cp python-config.py python-config; \ fi Traceback (most recent call last): File "./Parser/asdl_c.py", line 1312, in main(args[0], dump_module) File "./Parser/asdl_c.py", line 1251, in main if not asdl.check(mod): File ".../cpython/Parser/asdl.py", line 183, in check v = Check() File ".../cpython/Parser/asdl.py", line 140, in __init__ super().__init__() TypeError: super() takes at least 1 argument (0 given) """ Python installation is 2.7 (originally 2.5 at the system level, but recent build changes broke that), no Py3 available. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 10:55:38 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 10 May 2014 08:55:38 +0000 Subject: [issue21435] Segfault in gc with cyclic trash In-Reply-To: <1399291198.26.0.236308223501.issue21435@psf.upfronthosting.co.za> Message-ID: <1399712138.9.0.386575996814.issue21435@psf.upfronthosting.co.za> Andrew Svetlov added the comment: @Tim nothing to close, aiohttp is separate library based on asyncio. It just uses constructions like self.attr = None in __del__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 12:24:03 2014 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 10 May 2014 10:24:03 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1399717443.81.0.717824152868.issue19655@psf.upfronthosting.co.za> Eli Bendersky added the comment: Stefan, you need to run `make touch` if you want to avoid rebuilding. See #15964 for more details. [all bots run `make touch` before building now] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 12:28:57 2014 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 10 May 2014 10:28:57 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1399717737.38.0.338094673062.issue19655@psf.upfronthosting.co.za> Eli Bendersky added the comment: This is also described in the Dev Guide: https://docs.python.org/devguide/setup.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 13:34:04 2014 From: report at bugs.python.org (Apteris) Date: Sat, 10 May 2014 11:34:04 +0000 Subject: [issue21466] General Index link to del statement is wrong Message-ID: <1399721644.32.0.749674038876.issue21466@psf.upfronthosting.co.za> New submission from Apteris: In the documentation index, https://docs.python.org/2/genindex-D.html, the link to the del statement documentation is not https://docs.python.org/2/reference/simple_stmts.html#del as it presumably should be, but https://docs.python.org/2/reference/datamodel.html#index-25 Affects all versions, but with a different wrong link in each one, as follows: Python 2.7: https://docs.python.org/2/reference/datamodel.html#index-25 Python 3.2: https://docs.python.org/3.2/reference/datamodel.html#index-21 Python 3.3: https://docs.python.org/3.3/reference/datamodel.html#index-22 Python 3.4: https://docs.python.org/3.4/reference/datamodel.html#index-22 Python 3.5: https://docs.python.org/3.5/reference/datamodel.html#index-22 The del statement is in each case documented at https://docs.python.org/[version number]/reference/simple_stmts.html#del. ---------- assignee: docs at python components: Documentation messages: 218217 nosy: apteris, docs at python priority: normal severity: normal status: open title: General Index link to del statement is wrong type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 14:54:56 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 10 May 2014 12:54:56 +0000 Subject: [issue21466] General Index link to del statement is wrong In-Reply-To: <1399721644.32.0.749674038876.issue21466@psf.upfronthosting.co.za> Message-ID: <1399726496.85.0.261826721871.issue21466@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 15:15:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 10 May 2014 13:15:56 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399727756.12.0.546690662564.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This can be reproduced as easily under Linux: $ ./python 2>&1 | cat Python 3.5.0a0 (default:17689e43839a+39f2a78f4357+, May 9 2014, 00:30:19) [GCC 4.8.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 5 5 >>> 1/0 >>> nonsense Traceback (most recent call last): File "", line 1, in ZeroDivisionError: division by zero >>> Traceback (most recent call last): File "", line 1, in NameError: name 'nonsense' is not defined >>> ---------- components: +Interpreter Core -Windows nosy: +pitrou stage: -> needs patch title: Python 3 pipe handling breaks python mode in emacs on Windows -> Interactive interpreter doesn't flush stderr prompty versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 16:02:07 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 10 May 2014 14:02:07 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399730527.59.0.764353910873.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Attached patch fixes it under Linux, and adds tests. I'd be glad if someone could give it a run under Windows. ---------- keywords: +patch nosy: +ncoghlan, tim.golden, zach.ware stage: needs patch -> patch review Added file: http://bugs.python.org/file35206/flush_stderr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 17:04:51 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 10 May 2014 15:04:51 +0000 Subject: [issue21467] IDLE icon not included in Windows installer Message-ID: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> New submission from Steve Dower: #20406 changed the icon used by IDLE, but forgot to include the new file in the Windows installer. As a result, IDLE won't start. I've attached a patch. 3.4 is unaffected, probably because msi.py changed significantly at some point. (I don't have commit rights, but since I've never actually had a patch accepted I know exactly why. I have a few more changes coming that affect/improve PCBuild and tools\msi, but I'm happy to keep creating issues and patches if that's the right way to make these changes. On the other hand, if someone wants to give me commit rights and say "just go for it in these dirs" (in my new role as build manager for 2.7/3.5+) I'm okay with that too.) ---------- components: IDLE, Installation, Windows files: idleico.diff keywords: patch messages: 218220 nosy: benjamin.peterson, loewis, steve.dower, terry.reedy priority: normal severity: normal status: open title: IDLE icon not included in Windows installer type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file35207/idleico.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 17:45:27 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 10 May 2014 15:45:27 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399736727.88.0.219196705511.issue21467@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'll declare this release-critical for the moment; I'm sure Benjamin will properly process it. As for getting access: send your ssh key to hgaccounts at python.org. ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 18:20:51 2014 From: report at bugs.python.org (Brett Cannon) Date: Sat, 10 May 2014 16:20:51 +0000 Subject: [issue21459] DragonFlyBSD support In-Reply-To: <1399626494.21.0.91219272779.issue21459@psf.upfronthosting.co.za> Message-ID: <1399738851.38.0.797106419422.issue21459@psf.upfronthosting.co.za> Brett Cannon added the comment: It was pointed out to me Dragonfly support is pre-existing, so I prematurely rejected this. Sorry about that. ---------- resolution: wont fix -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 18:23:18 2014 From: report at bugs.python.org (James Meneghello) Date: Sat, 10 May 2014 16:23:18 +0000 Subject: [issue21468] NNTPLib connections become corrupt after long periods of activity Message-ID: <1399738998.21.0.285283528599.issue21468@psf.upfronthosting.co.za> New submission from James Meneghello: After establishing an NNTP connection for a long-running process (up to hours at a time), the connection will eventually die and start producing infinite random garbage output, a small part of which is seen below. Any subsequent calls to the connection will produce a random stream of exceptions and data, as the library flips out. This happens with the connection being constantly used over the time period. The problem occurs approximately 2 hours after the initial connection is established, and happens after approximately the same amount of time each run. The below connection was initialised at 22:03:27 and broke at 23:55:58. Workaround is pretty simple: kill the connection and reinitialise it. Calling quit() will fail, however, with a series of random exceptions produced, because quit() attempts to send a QUIT command to the broken socket. Tested on Ubuntu 13.10 (which fails) and Windows 8.1, which does not appear to have the same problem - I'm unable to replicate it on Win8.1. -- 2014-05-10 23:55:58,937 - ERROR - nntp error: \udcbb\udc906Z4Ft<\udceeD\udcb5\udc9d\udcba\udcb5\udca8\udccaEk\udcfa\udcb6\udcc8\udcc1\udcf4y?\udce6\udccf\udcd8\udcc9_\udcf9c$\udc8cc?c_B\udca9\udceefudcecsr\udcc1\udced?{\udc90\udca1\udcb2\udc81\udce0I\udc91\udcfeD\udceeE\udcd3\udcf6$\udccfbd\udcec"]\udcb0\udc9a\udc8cf6\udcfa\udcbf\udcea\udcb3h:S\udcbc\udc8dG\udca6t\udc85\udcc6(\udcf2\udce0Kb\udcbe\udcb8j\\udc94\udc85B-\udc9dL+le\udcad/.\udc87\udcbbtv\udc89!\udc8f/\udcf9_\udce0 \udcad\udc98\udcc0\udcc40T\udcc21\udcd3\udceb? \udcbc@\udcf5mG\udcba\udca0\udcc2]?LU?\udcc0\udcc*\udce1,H6\udcccja\udcf9h\udc97f\udc95\udc9c\udce3\udc88%\udca7\udc860\udcfb\udc83\udca2\udca1\udccfH\udcd3Ux?\udce2\udc86?Y\udcad\udcbb\udcd7\udcf7\udca7W?\udcf6\udcbf\udce9AI1P\udc8d\udc959^\udcc5\udcc3n\udce5xY\udcfb\udc87\udcfdp\udcb4nT\udca9\udc97\udcfbp\udc8aTkkb\udc90C\udcaa\udc8aq\udcddUm\udcd5sJsS7l\udcdb`\udc88hU\udcf6 ---------- components: Library (Lib) messages: 218223 nosy: James.Meneghello priority: normal severity: normal status: open title: NNTPLib connections become corrupt after long periods of activity versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 18:23:21 2014 From: report at bugs.python.org (Tim Golden) Date: Sat, 10 May 2014 16:23:21 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399739001.48.0.0577447048411.issue21467@psf.upfronthosting.co.za> Tim Golden added the comment: Steve -- re changes to PCBuild &c.: worth liaising with Zach Ware (and, to a lesser extent, me) as he's been working through a number of things in that area and I know has other ideas. Just post a patch and nosy us both (zach.ware / tim.golden) Obviously, if it's critical: just do it. ---------- nosy: +tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 18:26:07 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 10 May 2014 16:26:07 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399739167.27.0.879489660469.issue21467@psf.upfronthosting.co.za> Steve Dower added the comment: Martin - sent. I think I need some bits flipped on my account here too. Will/can you take care of that for me? Tim - thanks. My next task was to figure out who else has an interest in this area. I wasn't sure if the 'windows' tag was accurate, but sounds like it is (I should probably get on there as well). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 18:55:10 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 May 2014 16:55:10 +0000 Subject: [issue21469] Hazards in robots.txt parser Message-ID: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> New submission from Raymond Hettinger: * The can_fetch() method is not checking to see if read() has been called, so it returns false positives if read() has not been called. * When read() is called, it fails to call modified() so that mtime() returns an incorrect result. The user has to manually call modified() to update the mtime(). >>> from urllib.robotparser import RobotFileParser >>> rp = RobotFileParser('http://en.wikipedia.org/robots.txt') >>> rp.can_fetch('UbiCrawler', 'http://en.wikipedia.org/index.html') True >>> rp.read() >>> rp.can_fetch('UbiCrawler', 'http://en.wikipedia.org/index.html') False >>> rp.mtime() 0 >>> rp.modified() >>> rp.mtime() 1399740268.628497 Suggested improvements: 1) Trigger internal calls to modified() every time the parse is modified using read() or add_entry(). That would assure that mtime() actually reflects the modification time. 2) Raise an exception or return False whenever can_fetch() is called and the mtime() is zero (meaning that the parser has not be initialized with any rules). ---------- components: Library (Lib) messages: 218226 nosy: rhettinger priority: normal severity: normal status: open title: Hazards in robots.txt parser type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 19:53:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 10 May 2014 17:53:10 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <3gQwxK0CfDz7LjR@mail.python.org> Roundup Robot added the comment: New changeset a9d34685ec47 by Brian Curtin in branch '2.7': Backport 4e9f1017355f from #3561. http://hg.python.org/cpython/rev/a9d34685ec47 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 20:11:03 2014 From: report at bugs.python.org (akira) Date: Sat, 10 May 2014 18:11:03 +0000 Subject: [issue21464] fnmatch module uses regular expression with undefined result to perform matching In-Reply-To: <1399670647.23.0.136590413111.issue21464@psf.upfronthosting.co.za> Message-ID: <1399745463.04.0.270396358629.issue21464@psf.upfronthosting.co.za> akira added the comment: I don't see (?x) flag and it is not introduced by `res` regular expression that is constructed within translate() function in Lib/fnmatch.py >>> import fnmatch >>> fnmatch.translate('a b') 'a\\ b\\Z(?ms)' ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 20:21:34 2014 From: report at bugs.python.org (akira) Date: Sat, 10 May 2014 18:21:34 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1399746094.2.0.0219960359868.issue21332@psf.upfronthosting.co.za> akira added the comment: I've asked about thread-safety of tests on python-dev mailing list: https://mail.python.org/pipermail/python-dev/2014-May/134523.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 20:22:09 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Sat, 10 May 2014 18:22:09 +0000 Subject: [issue21464] fnmatch module uses regular expression with undefined result to perform matching In-Reply-To: <1399670647.23.0.136590413111.issue21464@psf.upfronthosting.co.za> Message-ID: <1399746129.21.0.552683347575.issue21464@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: I see, so it's my misreading of the "re" module docs. I kinda thought that "x" in "(?x)" means "any single-character flag of set (?aiLmsux)". I was wrong, it is the specific literal flag. Also, rereading it again, the doc says "the letters set the corresponding flags: [list of flags], for the entire regular expression." So, my report is invalid. Just to give some context, I hit this when porting fnmatch.py to MicroPython (http://micropython.org/), which doesn't use native CPython SRE, but instead system PCRE. Well, it would be nice if stdlib maintained kind of compatibility with original PCRE semantics, but that's kinda wishful thinking, we'll work it around on our side. Closing this. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 20:22:21 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 May 2014 18:22:21 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399746141.69.0.9029385777.issue21467@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Creating issues with patches, so others can comment, is a good idea even when you have commit rights. Adding yourself to https://docs.python.org/devguide/experts.html#experts is a good way to test new commit rights. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 20:29:05 2014 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 10 May 2014 18:29:05 +0000 Subject: [issue19655] Replace the ASDL parser carried with CPython In-Reply-To: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za> Message-ID: <1399746545.98.0.894902288702.issue19655@psf.upfronthosting.co.za> Stefan Behnel added the comment: That fixes it. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 21:19:35 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 10 May 2014 19:19:35 +0000 Subject: [issue21160] incorrect comments in nturl2path.py In-Reply-To: <1396694736.78.0.949476383561.issue21160@psf.upfronthosting.co.za> Message-ID: <1399749575.29.0.818037867822.issue21160@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +patch Added file: http://bugs.python.org/file35208/d7f128afe9db.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 21:35:07 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 10 May 2014 19:35:07 +0000 Subject: [issue21160] incorrect comments in nturl2path.py In-Reply-To: <1396694736.78.0.949476383561.issue21160@psf.upfronthosting.co.za> Message-ID: <1399750507.63.0.935302454421.issue21160@psf.upfronthosting.co.za> Changes by Ezio Melotti : Removed file: http://bugs.python.org/file35208/d7f128afe9db.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 21:43:26 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 10 May 2014 19:43:26 +0000 Subject: [issue21165] Optimize str.translate() for replacement with substrings and non-ASCII strings In-Reply-To: <1396861844.88.0.0543379452839.issue21165@psf.upfronthosting.co.za> Message-ID: <1399751006.71.0.786846174226.issue21165@psf.upfronthosting.co.za> Ezio Melotti added the comment: Aren't there similar benchmarks in the benchmarks repo? If not, would it be reasonable to add this there? ---------- nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 21:44:47 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 May 2014 19:44:47 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1399751087.6.0.0507476489429.issue6305@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Alok, have you signed a contributor agreement? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 22:05:11 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 May 2014 20:05:11 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399752311.05.0.307249381203.issue21467@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Steve, I am *really* glad you caught this. We obviously need a new test somewhere that would have caught this before the release. How is the installer tested now? Is it run and the installed python tested with the test suite? If so, a new idle test that runs idlelib/idle.(bat, py, pyw) with subprocess, detects startup errors, and cleanly shuts down the subprocces, would cover the installer. 3.4 is not directly affected because 3.4 Tools/msi/msi.py does not include the patched section if dir=="Icons": lib.glob("*.gif") + lib.glob("*.ico") lib.add_file("idle.icns") and .gif and .icns are not in the file. Perhaps the change matches a change in the build process. However, new tests should go on all versions. ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 22:20:00 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 May 2014 20:20:00 +0000 Subject: [issue20815] ipaddress unit tests PEP8 In-Reply-To: <1393675292.33.0.0800271368289.issue20815@psf.upfronthosting.co.za> Message-ID: <1399753200.83.0.293886133623.issue20815@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Marking as low priority. This patch really isn't worth applying. If someone wants to starting contributing, there are plenty of useful things to do (such as adding docstrings to elementtree). I don't want to encourage non-substantive shallow code churn and eats developer time for no benefit. >From my point of view, the "benefit" is actually negative because these sort of micro-rearrangements clutter the "annotate" history and because it makes it more difficult to apply substantive patches across multiple versions of Python. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 22:28:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 May 2014 20:28:39 +0000 Subject: [issue21439] Numerous minor issues in Language Reference In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> Message-ID: <1399753719.05.0.533726167504.issue21439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I also don't agree with most of the typographic changes and, like ?ric find some of the grammar changes to be pedantic. The OP refers to his own changes as "editorial infelicities". This should have been a warning sign. The OP further warns, "I have been reading the Language Reference Manual in order to teach myself Python 3" which explains why ?ric has found " a few misunderstandings of Python". If the OP cares enough to prepare a chapter by chapter patch (as suggested by Terry), I would be happy to review them one by one, applying any that are actual readability improvements. ---------- assignee: zach.ware -> rhettinger nosy: +rhettinger priority: normal -> low versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 22:56:25 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 May 2014 20:56:25 +0000 Subject: [issue21470] Better seeding for the random module Message-ID: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The default seeding for the random module currently used 32 bytes from urandom() to create the initial state of the random number generator. This is far less than the number of possible states 2**19937-1. Changing the default seed to a larger number will cover the state space. This gives better security and better randomness by not using just a subset of the possible states. The downside is slightly slower default initialization. ---------- assignee: rhettinger files: better_seed.diff keywords: patch messages: 218238 nosy: rhettinger priority: normal severity: normal status: open title: Better seeding for the random module type: security versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35209/better_seed.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 10 22:58:46 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 10 May 2014 20:58:46 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399755526.37.0.661117990611.issue21470@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 00:42:22 2014 From: report at bugs.python.org (ita1024) Date: Sat, 10 May 2014 22:42:22 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1399761742.41.0.281413006351.issue20115@psf.upfronthosting.co.za> ita1024 added the comment: Do not touch that please!!!! The null bytes are already rejected when forbidden by the encoding (utf-8 for example). Null byte characters in comments are perfectly valid in ISO8859-1 encoding, and a few scripts depend on them: http://ftp.waf.io/pub/release/waf-1.7.16 Parsing the commented lines is also likely to slow down the parser, so keep your hands of it please! There are too many regressions already! http://bugs.python.org/issue21086 ---------- nosy: +ita1024 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 00:46:06 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 10 May 2014 22:46:06 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1399761966.5.0.130957399229.issue20115@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 00:55:26 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 10 May 2014 22:55:26 +0000 Subject: [issue19767] pathlib: iterfiles() and iterdirs() In-Reply-To: <1385375147.52.0.820545347485.issue19767@psf.upfronthosting.co.za> Message-ID: <1399762526.9.0.249012801977.issue19767@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch with the proposed API. The API for convenience: def files(self, include_symlinks=True): """Iterate over the regular files in this directory. """ def subdirs(self, include_symlinks=True): """Iterate over the subdirectories in this directory. """ ---------- Added file: http://bugs.python.org/file35210/path_subdirs_files.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 00:55:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 10 May 2014 22:55:50 +0000 Subject: [issue19767] pathlib: iterfiles() and iterdirs() In-Reply-To: <1385375147.52.0.820545347485.issue19767@psf.upfronthosting.co.za> Message-ID: <1399762550.95.0.783713992876.issue19767@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 01:37:49 2014 From: report at bugs.python.org (Donald Stufft) Date: Sat, 10 May 2014 23:37:49 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1399765069.86.0.540977956471.issue21306@psf.upfronthosting.co.za> Donald Stufft added the comment: The attached patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 01:52:56 2014 From: report at bugs.python.org (Rose Ames) Date: Sat, 10 May 2014 23:52:56 +0000 Subject: [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <1399765976.8.0.985713459911.issue21221@psf.upfronthosting.co.za> Changes by Rose Ames : ---------- keywords: +patch Added file: http://bugs.python.org/file35211/tm_isdst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 01:59:59 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 10 May 2014 23:59:59 +0000 Subject: [issue21188] Broken link In-Reply-To: <1397050895.39.0.221241316975.issue21188@psf.upfronthosting.co.za> Message-ID: <1399766399.31.0.511560943608.issue21188@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 02:01:28 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 11 May 2014 00:01:28 +0000 Subject: [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <1399766488.41.0.0324657212944.issue21221@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > .. 0 when it is not. -1 indicates that .. It does not read well when the sentence starts with a number. Consider rephrasing as "The value of -1 .." or something like that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 02:06:28 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 11 May 2014 00:06:28 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1399766788.29.0.830513262767.issue21198@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 02:42:57 2014 From: report at bugs.python.org (Rose Ames) Date: Sun, 11 May 2014 00:42:57 +0000 Subject: [issue20977] pyflakes: undefined "ctype" in 2 except blocks in the email module In-Reply-To: <1395226153.72.0.859360673019.issue20977@psf.upfronthosting.co.za> Message-ID: <1399768977.69.0.00258894856488.issue20977@psf.upfronthosting.co.za> Rose Ames added the comment: It looks like these are just typos, recording defects to ctype objects when it should be disp_header and cte_header? Apologies if it's more complicated than that. ---------- keywords: +patch nosy: +superluser Added file: http://bugs.python.org/file35212/undefined_ctypes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 03:20:15 2014 From: report at bugs.python.org (Tim Peters) Date: Sun, 11 May 2014 01:20:15 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399771215.08.0.257966050242.issue21470@psf.upfronthosting.co.za> Tim Peters added the comment: +1, although it could really use a comment explaining that 2500 bytes was chosen to be >= the Twister's 19937 internal bits of state. Otherwise it looks as arbitrary as 32 did ;-) ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 03:47:24 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 11 May 2014 01:47:24 +0000 Subject: [issue20872] dbm/gdbm/ndbm close methods are not document In-Reply-To: <1394297879.28.0.882591650164.issue20872@psf.upfronthosting.co.za> Message-ID: <1399772844.68.0.259615261144.issue20872@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> docs at python components: +Documentation keywords: +easy nosy: +docs at python stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 03:49:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 01:49:23 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399772963.48.0.55861943277.issue21470@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure it is good practice to read that many bytes from /dev/urandom. Quoting the Linux man page for /dev/urandom: The kernel random-number generator is designed to produce a small amount of high-quality seed material to seed a cryptographic pseudo-random number gen? erator (CPRNG). It is designed for security, not speed, and is poorly suited to generating large amounts of random data. Users should be very economical in the amount of seed material that they read from /dev/urandom (and /dev/random); unnecessarily reading large quantities of data from this device will have a negative impact on other users of the device. The (default?) entropy pool size under Linux is 4096 bytes, so reading 2500 bytes will deplete more than half of it, IIUC. Example: $ cat /proc/sys/kernel/random/poolsize 4096 $ cat /proc/sys/kernel/random/entropy_avail 516 $ python -c "import os; os.urandom(300)" $ cat /proc/sys/kernel/random/entropy_avail 160 ---------- nosy: +neologix, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 03:56:25 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 11 May 2014 01:56:25 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399773385.39.0.149561741806.issue21470@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 03:56:45 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 01:56:45 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399773405.59.0.326064587273.issue21470@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also, the repletion rate of the entropy pool seems quite slow actually (around 10 bytes per second?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 04:02:47 2014 From: report at bugs.python.org (Donald Stufft) Date: Sun, 11 May 2014 02:02:47 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399773767.93.0.419262205717.issue21470@psf.upfronthosting.co.za> Donald Stufft added the comment: "Depleting the entropy pool" is sort of a nonsense idea that /dev/random has. Nobody should ever be worried about it and nobody should ever use /dev/random. The manpage is wrong and has continued to be wrong because of historical reasons and the people involved not wanting to admit a wart. Anything that relies on /dev/random isn't well written and is going to randomly block for bad reasons. We can pull as many bytes as we want off /dev/urandom and just forget that /dev/random or /proc/sys/kernel/random/entropy_avail even exists. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 05:13:34 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 03:13:34 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399778014.51.0.247719645308.issue21470@psf.upfronthosting.co.za> Raymond Hettinger added the comment: http://www.2uo.de/myths-about-urandom/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 06:06:54 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 11 May 2014 04:06:54 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399781214.51.0.056128129374.issue21467@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yes, by all means, commit it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 06:10:55 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 04:10:55 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399781455.07.0.562593504098.issue21470@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 06:19:42 2014 From: report at bugs.python.org (Steve Dower) Date: Sun, 11 May 2014 04:19:42 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399781982.78.0.852002693891.issue21467@psf.upfronthosting.co.za> Steve Dower added the comment: Currently it's an entirely manual process, which is something I intend to work on for 3.5 and beyond. As far as post-mortem on this issue goes, Martin would have found it as well, since I was doing exactly what he said he normally does. The "real" fix seems to already exist, which is why this only affects 2.7. Installers are just one of those things that are difficult to maintain in a project with lots of contributors, so the more automation the better. (It also helps to have a designated owner, so they can constantly bug people about it without having to feel like they're being annoying... I've learned this in my day job, where I own most of my team's installers.) My commit rights are set up and working. Is anyone opposed to me pushing this fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 06:27:23 2014 From: report at bugs.python.org (Steve Dower) Date: Sun, 11 May 2014 04:27:23 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399782443.1.0.590027813227.issue21467@psf.upfronthosting.co.za> Steve Dower added the comment: > Yes, by all means, commit it. Obviously I spent too long writing my last comment :) Pushed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 06:55:31 2014 From: report at bugs.python.org (Steve Dower) Date: Sun, 11 May 2014 04:55:31 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399784131.6.0.582367936605.issue21467@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 07:21:17 2014 From: report at bugs.python.org (eryksun) Date: Sun, 11 May 2014 05:21:17 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399785677.34.0.886535861517.issue21425@psf.upfronthosting.co.za> eryksun added the comment: The patch fixes `python 2>&1 | cat.exe` for me on Windows, where cat.exe is from GnuWin32. The tests also pass. It looks like failing would entail hanging until a timeout. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 09:10:43 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 11 May 2014 07:10:43 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399781455.11.0.0601619582936.issue21470@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > The default seeding for the random module currently used 32 bytes from > urandom() to create the initial state of the random number generator. > This is far less than the number of possible states 2**19937-1. I'm not a cryptography expert, but IMO 32 bytes is more than enough: for example, ssh-keygen only reads 32 bytes from /dev/urandom when generating a new key (and I assume the authors know what they're doing). So I'm not sure that "convering the state space" is a good enough reason to increase the amount of data read: it can hut performance, not only for the singla process case, but also because /dev/urandom is protected by a spinlock/mutex, it can hurt workloads where multiple processes are simultaneously reading from /dev/urandom (which is the reason we switched to a persistent /dev/urandom FD), see e.g. http://drsnyder.us/2014/04/16/linux-dev-urandom-and-concurrency.html And I especially like this answer by Ted Ts'o (once again, I assume he knows what he's talking about): """ Doctor, doctor it hurts when I do this. Well, then don't do that! The reason for the spinlock is to avoid having two reads from /dev/urandom return the same results. That would be undesirable... If people are trying to read from /dev/urandom a huge number of times per second, then they're doing something wrong. The real issue, as Sebastian has pointed out, is that issue spawning a huge number of curl processes for each request. Then hopefully curl is using /dev/urandom to initialize its own userspace RNG (many crypto libraries do this; most *should* do this), so you're not trying to read from /dev/urandom for every single request. /dev/urandom is designed for security, not for speed. """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 10:56:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 08:56:08 +0000 Subject: [issue21424] Simplify and speed-up heaqp.nlargest() In-Reply-To: <1399183029.85.0.254812547035.issue21424@psf.upfronthosting.co.za> Message-ID: <3gRJzC16V8z7LjY@mail.python.org> Roundup Robot added the comment: New changeset fadc06047314 by Raymond Hettinger in branch 'default': Issue #21424: Optimize heaqp.nlargest() to make fewer tuple comparisons. http://hg.python.org/cpython/rev/fadc06047314 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 11:53:15 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 11 May 2014 09:53:15 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1399801995.2.0.114914656525.issue21467@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: test needed -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 12:23:48 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 10:23:48 +0000 Subject: [issue21424] Simplify and speed-up heaqp.nlargest() In-Reply-To: <1399183029.85.0.254812547035.issue21424@psf.upfronthosting.co.za> Message-ID: <1399803828.45.0.529000636639.issue21424@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file35213/rip_nsmallest.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:02:25 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 11:02:25 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399806145.18.0.326651963535.issue21470@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Several thoughts: * We're not reading urandom "a huge number of times per second". This is just one read of 2,500 bytes. What Ted is talking about and what we're doing are as different as night and day. * We're also not doing this in a loop. It is just once when Random() is initialized. There are no threading issues here. * 32 bytes is good but it is not enough. There is a reason that the state space for the Mersenne Twister is so large to begin with. Functions as simple as shuffle() eat through the possibilities very quickly. * The "doctor, it hurts" quote is funny, but we don't have any hurt here. Running "import os; os.urandom(2500)" takes under a millisecond on my system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:14:30 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 11:14:30 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399806870.57.0.436127980824.issue21470@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > http://www.2uo.de/myths-about-urandom/ Thanks, interesting read. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:14:56 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 11:14:56 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399806896.08.0.619740178892.issue21470@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:25:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 11:25:06 +0000 Subject: [issue21471] subprocess line-buffering only works in universal newlines mode Message-ID: <1399807506.68.0.880743038196.issue21471@psf.upfronthosting.co.za> New submission from Antoine Pitrou: The docs for subprocess.Popen seem to imply that line-buffering is always available. However, bufsize=1 is a special value only when open the pipes in text mode, i.e. when "universal newlines" are enabled. In the short term, we should probably fix the subprocess docs. In the long term, perhaps we can add a line buffering capability to BufferedWriter? ---------- components: Library (Lib) messages: 218257 nosy: benjamin.peterson, gregory.p.smith, hynek, pitrou, stutzbach priority: normal severity: normal status: open title: subprocess line-buffering only works in universal newlines mode type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:31:53 2014 From: report at bugs.python.org (mouad) Date: Sun, 11 May 2014 11:31:53 +0000 Subject: [issue21472] Fix wsgiref handling of absolute HTTP Request-URI Message-ID: <1399807913.92.0.0240575633204.issue21472@psf.upfronthosting.co.za> New submission from mouad: Hi, As most of you know, working behind a HTTP proxy raise all this corner cases that no one think about until he has to, one of them i had to deal with some months ago is absolute request URI in HTTP request, that some client will send when they detect that they are behind an HTTP proxy, to be more precise i am talking about this section of rfc2616 (https://gist.github.com/mouadino/7930974), i.e. GET http://domain.com/path HTTP/1.1 As my surprise i found that most WSGI server that are out there doesn't support very well this feature including wsgiref, to test that i have created this simple python script https://gist.github.com/mouadino/7930974 that include also status of this bug in different other projects. In term of bug impact, if a WSGI server doesn't support this, the WSGI environment variable PATH_INFO will end up containing an absolute URI instead of relative as the standard require (http://legacy.python.org/dev/peps/pep-0333/), which mean that most uri routing that web framework do end up failing (Returning 404) b/c most of them will try to much PATH_INFO with there different routes (which are relative paths) to find which controller action should they executed e.g. https://pypi.python.org/pypi/Routes . FWIW i found this bug while trying to debug boto library (that use absolute uri if proxy is detected https://github.com/mouadino/boto/blob/v2.13.2/boto/connection.py#L955) that was communicating with an OpenStack API that use eventlet wsgi server (That doesn't handle absolute URI https://github.com/eventlet/eventlet/blob/v0.14/eventlet/wsgi.py#L471) and routes (that match PATH_INFO with action path https://github.com/bbangert/routes/blob/master/routes/mapper.py#L678). ---------- components: Library (Lib) messages: 218258 nosy: mouad, pje priority: normal severity: normal status: open title: Fix wsgiref handling of absolute HTTP Request-URI type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:33:19 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 11:33:19 +0000 Subject: [issue21471] subprocess line-buffering only works in universal newlines mode In-Reply-To: <1399807506.68.0.880743038196.issue21471@psf.upfronthosting.co.za> Message-ID: <1399807999.94.0.102359839662.issue21471@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:35:16 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 11:35:16 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399808116.52.0.877765073307.issue21425@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:35:39 2014 From: report at bugs.python.org (mouad) Date: Sun, 11 May 2014 11:35:39 +0000 Subject: [issue21472] Fix wsgiref handling of absolute HTTP Request-URI In-Reply-To: <1399807913.92.0.0240575633204.issue21472@psf.upfronthosting.co.za> Message-ID: <1399808139.93.0.67868283863.issue21472@psf.upfronthosting.co.za> Changes by mouad : ---------- keywords: +patch Added file: http://bugs.python.org/file35214/issue21472.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:35:53 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 11:35:53 +0000 Subject: [issue21471] subprocess line-buffering doesn't work In-Reply-To: <1399807506.68.0.880743038196.issue21471@psf.upfronthosting.co.za> Message-ID: <1399808153.42.0.957129301599.issue21471@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ha, it seems actually worse than that, since no buffering argument is ever passed to the TextIOWrapper constructor. "bufsize=1" will simply get ignored, and line buffering doesn't work at all. Example under 2.7: $ python -c 'import subprocess; p = subprocess.Popen(["/bin/cat"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, bufsize=1, universal_newlines=True); p.stdin.write("foo\n"); print(p.stdout.readline()); p.stdin.close()' foo Under 3.4, the same line hangs in the p.stdout.readline() call. ---------- title: subprocess line-buffering only works in universal newlines mode -> subprocess line-buffering doesn't work _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:39:16 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 11:39:16 +0000 Subject: [issue21471] subprocess line-buffering only works in universal newlines mode In-Reply-To: <1399807506.68.0.880743038196.issue21471@psf.upfronthosting.co.za> Message-ID: <1399808356.67.0.169740868466.issue21471@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, the "not working at all" part is issue #21332. Let's make this issue specific to binary mode, again. ---------- nosy: +akira title: subprocess line-buffering doesn't work -> subprocess line-buffering only works in universal newlines mode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:43:18 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 11:43:18 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1399808598.72.0.336266882882.issue20115@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:45:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 11:45:20 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <3gRNkR3WSgz7LjP@mail.python.org> Roundup Robot added the comment: New changeset ab3e012c45d0 by Antoine Pitrou in branch '3.4': Issue #21425: Fix flushing of standard streams in the interactive interpreter. http://hg.python.org/cpython/rev/ab3e012c45d0 New changeset d1c0cf44160c by Antoine Pitrou in branch 'default': Issue #21425: Fix flushing of standard streams in the interactive interpreter. http://hg.python.org/cpython/rev/d1c0cf44160c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:46:02 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 11:46:02 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399808762.04.0.622244949387.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report. This should now be fixed in 3.4 and 3.5. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:52:05 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 11:52:05 +0000 Subject: [issue21389] The repr of BoundMethod objects sometimes incorrectly identifies the bound function In-Reply-To: <1398824801.68.0.416059453762.issue21389@psf.upfronthosting.co.za> Message-ID: <1399809125.3.0.410376513933.issue21389@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:55:12 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 11:55:12 +0000 Subject: [issue18564] Integer overflow in socketmodule In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za> Message-ID: <1399809312.68.0.387617690282.issue18564@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:57:02 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 11:57:02 +0000 Subject: [issue21226] PyImport_ExecCodeModuleObject not setting module attributes In-Reply-To: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za> Message-ID: <1399809422.9.0.987419200692.issue21226@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:58:41 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 11:58:41 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399809521.0.0.829282310233.issue21422@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 13:59:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 11:59:42 +0000 Subject: [issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py In-Reply-To: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za> Message-ID: <1399809582.36.0.495140592262.issue21121@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 14:01:29 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 12:01:29 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n In-Reply-To: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> Message-ID: <1399809689.1.0.112291296997.issue21420@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 14:03:26 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 12:03:26 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1399809806.13.0.428978199949.issue20383@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 14:05:41 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 12:05:41 +0000 Subject: [issue21436] Consider leaving importlib.abc.Loader.load_module() In-Reply-To: <1399291208.69.0.802643633069.issue21436@psf.upfronthosting.co.za> Message-ID: <1399809941.54.0.0839750471043.issue21436@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 14:20:06 2014 From: report at bugs.python.org (akira) Date: Sun, 11 May 2014 12:20:06 +0000 Subject: [issue21471] subprocess line-buffering only works in universal newlines mode In-Reply-To: <1399807506.68.0.880743038196.issue21471@psf.upfronthosting.co.za> Message-ID: <1399810806.76.0.291404529387.issue21471@psf.upfronthosting.co.za> akira added the comment: Until the current patch for issue #21332 is committed; bufsize=1 is equivalent to bufsize=-1 in both binary and text mode. You are correct the patch in #21332 fixes only the text mode (universal_newlines=True) -- it also updates the documentation to mention that bufsize=1 works only in text mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 14:23:30 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 May 2014 12:23:30 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1399811010.28.0.87342253677.issue21332@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 15:20:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 13:20:56 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399814456.17.0.694634405173.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Apparently the new tests hang on the "Fedora without threads" buildbot. Stefan, could you take a look? http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.4/builds/123 ---------- nosy: +skrah status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 15:52:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 13:52:44 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399816364.3.0.985831380928.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also on the PowerLinux buildbot: http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.4/builds/113/ ---------- nosy: +David.Edelsohn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 16:04:32 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 14:04:32 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399817072.9.0.220633905549.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Judging by the faulthandler traceback in the PowerLinux build: Timeout (1:00:00)! Thread 0x0000008074e46670 (most recent call first): File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_cmd_line_script.py", line 192 in interactive_python File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/contextlib.py", line 59 in __enter__ File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_cmd_line_script.py", line 205 in check_repl_stderr_flush File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_cmd_line_script.py", line 220 in test_repl_stderr_flush [snip] ... the test is actually stuck trying to read the interactive prompt from stderr: # Drain stderr until prompt while True: data = stderr.read(4) if data == b">>> ": break stderr.readline() <-- HERE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 16:09:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 14:09:24 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <3gRRwh0mWHz7LjW@mail.python.org> Roundup Robot added the comment: New changeset ffae7aad9dfa by Antoine Pitrou in branch 'default': Add debugging output for #21425 http://hg.python.org/cpython/rev/ffae7aad9dfa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 16:12:59 2014 From: report at bugs.python.org (Alok Singhal) Date: Sun, 11 May 2014 14:12:59 +0000 Subject: [issue6305] islice doesn't accept large stop values In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za> Message-ID: <1399817579.51.0.423330608956.issue6305@psf.upfronthosting.co.za> Alok Singhal added the comment: Yes, I signed it a few days ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 16:13:15 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 11 May 2014 14:13:15 +0000 Subject: [issue21472] Fix wsgiref handling of absolute HTTP Request-URI In-Reply-To: <1399807913.92.0.0240575633204.issue21472@psf.upfronthosting.co.za> Message-ID: <1399817595.92.0.63679617165.issue21472@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 16:44:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 14:44:06 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399819446.0.0.141175585002.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So, it seems like under Fedora (or PowerLinux), the Python interactive prompt produces different byte contents on stderr: [ 21/389] test_cmd_line_script repl stderr[:4]: b'Pyth' repl stderr[:4]: b'[GCC' repl stderr[:4]: b'Type' repl stderr[:4]: b'\x1b[?1' I wonder if it's because of GNU readline? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 16:46:55 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 11 May 2014 14:46:55 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399819615.54.0.34453407561.issue21470@psf.upfronthosting.co.za> Mark Dickinson added the comment: Raymond: > Functions as simple as shuffle() eat through the possibilities very quickly. Can you elaborate on this? Are there example scenarios where seeding with 32 bytes isn't likely to be enough? In the case of shuffle, for a large list, if you do a seed followed by a shuffle, the restriction to 32 bytes is restricting us to 'only' about 10**77 possible different shuffle results. It's hard to imagine a situation where that would be a problem. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 16:54:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 14:54:11 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399820051.19.0.980942520306.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks like a well-known issue on Fedora (and Red Hat?): http://stackoverflow.com/questions/15760712/python-readline-module-prints-escape-character-during-import http://reinout.vanrees.org/weblog/2009/08/14/readline-invisible-character-hack.html http://lists.gnu.org/archive/html/bug-readline/2007-08/msg00004.html Apparently using XTERM=vt100 would workaround the issue. (I can't reproduce under Ubuntu) ---------- nosy: +dmalcolm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 16:59:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 14:59:21 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <3gRT2K0rcDz7LjM@mail.python.org> Roundup Robot added the comment: New changeset e57718ac8ff8 by Antoine Pitrou in branch 'default': Try workaround for test issues in #21425 http://hg.python.org/cpython/rev/e57718ac8ff8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 17:10:55 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 11 May 2014 15:10:55 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399806145.18.0.326651963535.issue21470@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > * We're not reading urandom "a huge number of times per second". This is just one read of 2,500 bytes. What Ted is talking about and what we're doing are as different as night and day. > > * We're also not doing this in a loop. It is just once when Random() is initialized. There are no threading issues here. Well, you don't know how people will use it though: some code spawns many processes per second (see recent discussion on python-dev). > * 32 bytes is good but it is not enough. There is a reason that the state space for the Mersenne Twister is so large to begin with. Functions as simple as shuffle() eat through the possibilities very quickly. As I said, I'm not a cryptography expert, but quoting the link you gave: """About 256 bits of entropy are enough to get computationally secure numbers for a long, long time.""" The kernel's CSPRNG itself considers 256 bits enough, so I'm curious as to what makes you think that 32 *bytes* is not enough. openssl itself only reads 32 bytes from /dev/urandom: """ $ strace -e open,read openssl genrsa open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 read(3, "\336\314\312\355<\305\312\375\244\276G\n\201^\32\236\301\243\327\277\344\320\0\5\3017-\\\346\333G?", 32) = 32 """ In short, everyone seems to think that 32bytes seeding is more than enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 17:15:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 15:15:25 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399821325.11.0.782479293452.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: According to https://bugzilla.redhat.com/show_bug.cgi?id=880393, this has actually been reported to us as issue19884. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 17:17:05 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 15:17:05 +0000 Subject: [issue19884] Importing readline produces erroneous output In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za> Message-ID: <1399821425.8.0.383752143639.issue19884@psf.upfronthosting.co.za> Antoine Pitrou added the comment: We seem to have gotten bit by this in issue21425. Dave, is it possible for you to validate the proposed fix? I can't test this under Ubuntu. Setting priority to "high" as it seems to actually annoy many people: http://stackoverflow.com/questions/15760712/python-readline-module-prints-escape-character-during-import http://reinout.vanrees.org/weblog/2009/08/14/readline-invisible-character-hack.html http://lists.gnu.org/archive/html/bug-readline/2007-08/msg00004.html ---------- nosy: +skrah priority: normal -> high versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 17:29:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 15:29:11 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399822151.66.0.371120407224.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Workarounds seem to work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 17:30:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 15:30:47 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <3gRTkb1FNsz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 58e2116576cf by Antoine Pitrou in branch '3.4': Try workaround for test issues in #21425 http://hg.python.org/cpython/rev/58e2116576cf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 17:31:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 15:31:13 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399822273.15.0.367208581408.issue21425@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 17:36:58 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 11 May 2014 15:36:58 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: Any objection to the last version? If not, I'll commit it within a few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 17:37:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 15:37:46 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: <1399576407.19.0.800132565912.issue21455@psf.upfronthosting.co.za> Message-ID: <1399822666.56.0.00687821264241.issue21455@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks good to me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 19:08:16 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 17:08:16 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <1399828096.78.0.632944980787.issue21425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Workaround actually broke tests under shared library builds, because LD_LIBRARY_PATH isn't forwarded anymore. Will try another fix :-( ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 19:13:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 17:13:49 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <3gRX1S5T9Pz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 5a1b2566d68e by Antoine Pitrou in branch 'default': Try to fix issue #21425 workaround for shared library builds http://hg.python.org/cpython/rev/5a1b2566d68e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 19:39:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 17:39:23 +0000 Subject: [issue21425] Interactive interpreter doesn't flush stderr prompty In-Reply-To: <1399192120.08.0.445730611813.issue21425@psf.upfronthosting.co.za> Message-ID: <3gRXZy6YzQz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 974c0718c7e0 by Antoine Pitrou in branch '3.4': Try to fix issue #21425 workaround for shared library builds http://hg.python.org/cpython/rev/974c0718c7e0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 20:19:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 18:19:23 +0000 Subject: [issue21466] General Index link to del statement is wrong In-Reply-To: <1399721644.32.0.749674038876.issue21466@psf.upfronthosting.co.za> Message-ID: <3gRYT63SQcz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset 951775c68b1b by Benjamin Peterson in branch '2.7': remove confusing delete indexing (closes #21466) http://hg.python.org/cpython/rev/951775c68b1b New changeset 2e26703d7d2a by Benjamin Peterson in branch '3.4': remove confusing delete indexing (closes #21466) http://hg.python.org/cpython/rev/2e26703d7d2a ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 20:21:45 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 18:21:45 +0000 Subject: [issue21469] Hazards in robots.txt parser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <1399832505.17.0.149910731712.issue21469@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching a draft patch: * Repair the broken link to norobots-rfc.txt. * HTTP response codes >= 500 treated as a failed read rather than as a not found. Not found means that we can assume the entire site is allowed. A 5xx server error tells us nothing. * A successful read() updates the mtime (which is defined to be "the time the robots.txt file was last fetched"). * The can_fetch() method returns False unless we've had a read() with a 2xx or 4xx response. This avoids false positives in the case where a user calls can_fetch() before calling read(). ---------- assignee: -> rhettinger keywords: +patch Added file: http://bugs.python.org/file35215/fix_false_pos.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 20:49:04 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 18:49:04 +0000 Subject: [issue21469] Hazards in robots.txt parser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <1399834144.06.0.312809910878.issue21469@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Update patch to move the modified() call to parse(). That lets the mtime update whenever rules (either by a read() or by directly parsing text). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 20:50:13 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 18:50:13 +0000 Subject: [issue21469] Hazards in robots.txt parser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <1399834213.74.0.0487582655832.issue21469@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file35216/fix_false_pos2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:02:35 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 11 May 2014 19:02:35 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1399707943.51.0.955940492265.issue7776@psf.upfronthosting.co.za> (Cybjit's message of "Sat, 10 May 2014 07:45:43 +0000") Message-ID: <87tx8wjfzs.fsf@kosh.rath.org> Nikolaus Rath added the comment: Cybjit writes: > Cybjit added the comment: > > On 2014-05-10 00:23, nikratio wrote: >> Is pip maybe doing its own certificate check, and relying on >> HTTPSConnection.host to contain the final hostname rather than the proxy? > > I think the culprit might be here > https://github.com/pypa/pip/blob/1.5.4/pip/_vendor/requests/packages/urllib3/connection.py#L172 Yes, that's the problem. I guess that nicely demonstrates why using inheritance as an API is not a good idea. I guess we nevertheless need to repair/work around this in Python 3.4? Unfortunately pip explicitly relies on _set_tunnel() to set self.host = self._tunnel_host. So we would need to change _set_tunnel() to save the original attribute somewhere, change the other methods to use the saved attribute in favor of the real one, and have connect() restore it (so that we can reconnect). This still would not allow pip to reconnect (because it overwrites the connect method), but then reconnecting a tunneled connection with pip did not work before either. Still, rather ugly. Alternatively, maybe we could also do nothing, because if pip is depending on undocumented semantics of a private method (_set_tunnel), they have to live with the consequences? Thinking about this, I think we should just revert the entire patch for 3.4, but keep it in for 3.5. That gives the pip folks enough time to fix their code. Fixing the issue in 3.4 is probably not that crucial (after all, it existed since about 2.6.3). 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 Sun May 11 21:15:11 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 19:15:11 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399835711.85.0.52823851247.issue21470@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > 32 bytes seeding is more than enough. Not enough to cover *our* state space (2 ** 19937 - 1). This tracker item boils down to balancing "fear that something bad will happen when you call urandom(2500)" versus "having seeding sufficient to cover the state space". My judgment (based on the cited article) is the first is FUD and that the second is something that has gives us the full value from the Mersenne Twister. What constitutes "enough" is a value judgment that many vary from application to application. For some applications, a much weaker PRNG would suffice, but we decided long ago that we wanted the full power of MT. If you an show an actual downside (not just fear of badness), then we have bigger issues (i.e. needing to document that SystemRandom() and os.urandom() have major limitations and should be avoided). On my system, the difference between a call to urandom(32) and urandom(2500) is measured in microseconds. I believe (but am having a hard time measuring) that the call is even cheaper than the subsequent processing we do random_seed() and init_by_array(). In other words, the worry about calling urandom(2500) appears to baseless or immaterial. If you have timings that show evidence to the contrary, I would like to see them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:36:16 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 19:36:16 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399836976.22.0.252825088247.issue21470@psf.upfronthosting.co.za> Raymond Hettinger added the comment: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/MersenneTwister.h http://www.omnetpp.org/doc/omnetpp/api/mersennetwister_8h_source.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:38:25 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 19:38:25 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399837105.77.0.3807104105.issue21470@psf.upfronthosting.co.za> Raymond Hettinger added the comment: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/MersenneTwister.h http://www.omnetpp.org/doc/omnetpp/api/mersennetwister_8h_source.html http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:38:41 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 19:38:41 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399837121.11.0.930511926603.issue21470@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg218288 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:41:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 11 May 2014 19:41:48 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399837308.94.0.0161769080772.issue21470@psf.upfronthosting.co.za> STINNER Victor added the comment: "The default seeding for the random module currently used 32 bytes from urandom() to create the initial state of the random number generator. This is far less than the number of possible states 2**19937-1." I suggest to document how the PRNG is initialized instead of reading more bytes from /dev/urandom. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:51:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 19:51:58 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399837918.55.0.550569119819.issue21470@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > What constitutes "enough" is a value judgment that many vary from > application to application. For some applications, a much weaker PRNG > would suffice, but we decided long ago that we wanted the full power of MT. I don't really understand for which application 20000 bits of seeding entropy would be required *in practice*. Surely MT has other interesting properties (such as the statistical distribution of the output) than its insanely large cycle length, that make it desirable as a PRNG. The paper you linked to ("Good Practice in (Pseudo) Random Number Generation for Bioinformatics Applications") doesn't suggest feeding a 20000 bits seed, it actually seems to say that 64 bits is enough for numerical simulations run on large clusters. While reading 20000 bits off of /dev/urandom might be fast under Linux, it might not necessarily be the case on other systems. It doesn't sound reasonable to read this many data if there isn't a strong reason for doing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:57:34 2014 From: report at bugs.python.org (mattip) Date: Sun, 11 May 2014 19:57:34 +0000 Subject: [issue10744] ctypes arrays have incorrect buffer information (PEP-3118) In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za> Message-ID: <1399838254.84.0.374096080226.issue10744@psf.upfronthosting.co.za> mattip added the comment: Here are updated patches for 2.7 and HEAD. I've updated the patches for both python 2 and python 3 and addressed some of the issues here: 1. Added _ctypes_alloc_format_string_with_shape() to ctypes.h 2. Changed the buffer size calculation to 32 *ndim + 3 (for the question asked before, the 32 size is just because this was the size used before the patch....) 3. Changed the sprintf to use the macro: sprintf(buf, "%"PY_FORMAT_SIZE_T"d,", shape[k]); I really hope this patch makes it to 2.7.7 and python 3 versions, as currently the situation is broken and code that once worked with older numpy versions does not work today (and we have legacy code that stopped working). ---------- nosy: +mattip versions: +Python 2.7 Added file: http://bugs.python.org/file35217/hg-python2.7-ctypes-fix-pep3118-format-strings-for-arrays-updated.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:58:12 2014 From: report at bugs.python.org (mattip) Date: Sun, 11 May 2014 19:58:12 +0000 Subject: [issue10744] ctypes arrays have incorrect buffer information (PEP-3118) In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za> Message-ID: <1399838292.52.0.738120887287.issue10744@psf.upfronthosting.co.za> mattip added the comment: Here is the patch for HEAD ---------- Added file: http://bugs.python.org/file35218/hg-default-ctypes-fix-pep3118-format-strings-for-arrays-update.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:59:43 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 19:59:43 +0000 Subject: [issue10744] ctypes arrays have incorrect buffer information (PEP-3118) In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za> Message-ID: <1399838383.03.0.974010775702.issue10744@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge versions: +Python 3.5 -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 21:59:53 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 19:59:53 +0000 Subject: [issue10744] ctypes arrays have incorrect buffer information (PEP-3118) In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za> Message-ID: <1399838393.04.0.211453511505.issue10744@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 22:07:48 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 11 May 2014 20:07:48 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1399838868.32.0.00246083901493.issue7776@psf.upfronthosting.co.za> Ned Deily added the comment: Should this be a release blocker regression for 3.4.1? ---------- nosy: +larry, ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 22:27:03 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 11 May 2014 20:27:03 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1399840023.65.0.724482247667.issue7776@psf.upfronthosting.co.za> Larry Hastings added the comment: dstufft, what do you think? ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 22:32:22 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 20:32:22 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399840342.47.0.224170369422.issue21470@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Looking back over this tracker item, I realize that I didn't elaborate sufficiently on the problem being addressed: MT is equidistributed. This a major point in its favor but also implies that there are long stretches of "uninteresting" sequences. When we seed with only a subset the state space, there is a risk of systematically landing in those stretches. That is why the cited best practices paper recommends filling the seed space and likely is why the cited reference implementation uses /urandom to fill the state space. We've previously had this problem with MT (since resolved, where it is was landed in a very non-random zone). We can't avoid the *possibility* of landing in one of these zones, but we can make sure that it isn't a *systematic* recurring problem. By using a sufficiently large seed, we avoid biasing the selection of which sequences are visitable out of the huge MT period. Though the current 32 bytes is pretty good (I hope so, I'm the one that chose that constant), there is no question that there is some benefit from the larger seed and that we are following in the footsteps of published reference implementations. The real question is whether there is a actual downside to calling urandom(2500). AFAICT, the impact is insignificant (increasing the cost of initialization by mirco-seconds, a percentage increase so small that I can't measure it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 22:32:46 2014 From: report at bugs.python.org (Donald Stufft) Date: Sun, 11 May 2014 20:32:46 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1399840366.07.0.0947006597081.issue7776@psf.upfronthosting.co.za> Donald Stufft added the comment: Let me raise the issue with urllib3 and see if maybe we can get a quick turn around and just fix it for real. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 23:00:07 2014 From: report at bugs.python.org (eryksun) Date: Sun, 11 May 2014 21:00:07 +0000 Subject: [issue10744] ctypes arrays have incorrect buffer information (PEP-3118) In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za> Message-ID: <1399842007.37.0.754974165336.issue10744@psf.upfronthosting.co.za> eryksun added the comment: The shape for the StructWithArrays test should be () in 3.x; it's None in 2.x. ---------- nosy: +eryksun versions: +Python 3.3 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 23:14:27 2014 From: report at bugs.python.org (Donald Stufft) Date: Sun, 11 May 2014 21:14:27 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1399842867.71.0.933541392224.issue7776@psf.upfronthosting.co.za> Donald Stufft added the comment: This is going to break existing versions of urllib3 (and thus requests and thus pip) when using verified TLS + a proxy, however future versions can work around it and a fix is being looked at right now. Once it's fixed there it can propagate to requests and then to pip. Urllib3 issue is here https://github.com/shazow/urllib3/issues/385 As far as what CPython should do. I personally don't think 3.4.1 should go out with this broken. That'll mean either getting a new pip out with the fix and bump the bundled version in CPython or revert this patch and wait till 3.5 (or 3.4.2 if you don't want to hold up 3.4.1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 23:21:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 21:21:29 +0000 Subject: [issue21424] Simplify and speed-up heaqp.nlargest() In-Reply-To: <1399183029.85.0.254812547035.issue21424@psf.upfronthosting.co.za> Message-ID: <3gRdWD6VZgz7LjY@mail.python.org> Roundup Robot added the comment: New changeset 31950174f60f by Raymond Hettinger in branch 'default': Issue 21424: Apply the nlargest() optimizations to nsmallest() as well. http://hg.python.org/cpython/rev/31950174f60f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 23:40:03 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 21:40:03 +0000 Subject: [issue21424] Simplify and speed-up heaqp.nlargest() In-Reply-To: <1399183029.85.0.254812547035.issue21424@psf.upfronthosting.co.za> Message-ID: <1399844403.24.0.315217865102.issue21424@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 23:45:03 2014 From: report at bugs.python.org (Tim Peters) Date: Sun, 11 May 2014 21:45:03 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399844703.45.0.615867197377.issue21470@psf.upfronthosting.co.za> Tim Peters added the comment: [neologix] > some code spawns many processes per second (see recent > discussion on python-dev). But that doesn't imply they're seeding the random module many times per second, right? Seeding isn't part of Python initialization, it's part of importing the `random` module. Note that "hash randomization" is a different thing, unrelated to random.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 11 23:47:37 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 May 2014 21:47:37 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399844703.45.0.615867197377.issue21470@psf.upfronthosting.co.za> Message-ID: <1399844853.2316.2.camel@fsol> Antoine Pitrou added the comment: > [neologix] > > some code spawns many processes per second (see recent > > discussion on python-dev). > > But that doesn't imply they're seeding the random module many times > per second, right? Seeding isn't part of Python initialization, it's > part of importing the `random` module. It's easy to import the random module, even for a specific library function which may never be called by the program being run. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 00:10:49 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 May 2014 22:10:49 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <1399846249.63.0.870991272437.issue21469@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- stage: -> test needed title: Hazards in robots.txt parser -> False positive hazards in robotparser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 00:51:28 2014 From: report at bugs.python.org (Rose Ames) Date: Sun, 11 May 2014 22:51:28 +0000 Subject: [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <1399848688.19.0.792494577397.issue21221@psf.upfronthosting.co.za> Rose Ames added the comment: Thanks for the quick feedback! Altered to "A value of -1..." ---------- nosy: +superluser Added file: http://bugs.python.org/file35219/tm_isdst2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 01:11:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 May 2014 23:11:51 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <3gRgyZ4KKhz7Ljr@mail.python.org> Roundup Robot added the comment: New changeset b40f1a00b134 by Benjamin Peterson in branch '2.7': backport hmac.compare_digest to partially implement PEP 466 (closes #21306) http://hg.python.org/cpython/rev/b40f1a00b134 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 02:06:55 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 00:06:55 +0000 Subject: [issue21465] sqlite3 Row can return duplicate keys when using adapters In-Reply-To: <1399672256.68.0.166250570949.issue21465@psf.upfronthosting.co.za> Message-ID: <1399853215.2.0.416241675548.issue21465@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 02:18:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 00:18:09 +0000 Subject: [issue20826] Faster implementation to collapse consecutive ip-networks In-Reply-To: <1393771140.68.0.719869740699.issue20826@psf.upfronthosting.co.za> Message-ID: <1399853889.25.0.587455561965.issue20826@psf.upfronthosting.co.za> Antoine Pitrou added the comment: >From a quick look, the algorithm is indeed correct, and it should perform better on average than the previous one. Note: both algorithms are O(n**2) worst case, not O(n). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 02:32:12 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 May 2014 00:32:12 +0000 Subject: [issue21473] Idle: test startup scripts. Message-ID: <1399854732.22.0.268177430342.issue21473@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Add test_idle/test_startup to test that Idle starts without obvious error with any of idlelib/idle.(bat, py, pyw). Test should presumably use subprocess. Look at test.support.interactive_python for either direct use or as a model. It in turn uses test.script_helper.spawn_python and .kill_python. Also look at test_cmd_line_script.py for models. A simple sanity check would be requires('gui') test as it should bring (and exit) an actually idle window. Beyond testing startup with no options, there are multiple options and combinations of options. Some of this could be automated easier if option decoding were separated from acting on the options. If necessary, some things could be added as a non-automated human test. ---------- messages: 218306 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: test startup scripts. type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 03:27:44 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 May 2014 01:27:44 +0000 Subject: [issue21474] Idle: updata fixwordbreaks() for unicode identifiers Message-ID: <1399858064.02.0.148903090644.issue21474@psf.upfronthosting.co.za> New submission from Terry J. Reedy: EditorWindow.py has this function, applied to editor and shell windows, which is obsolete for Python3 and unicode identifiers. def fixwordbreaks(root): # Make sure that Tk's double-click and next/previous word # operations use our definition of a word (i.e. an identifier) tk = root.tk tk.call('tcl_wordBreakAfter', 'a b', 0) # make sure word.tcl is loaded tk.call('set', 'tcl_wordchars', '[a-zA-Z0-9_]') tk.call('set', 'tcl_nonwordchars', '[^a-zA-Z0-9_]') Double clicking selects a contiguous sequence of 'word' or 'nonword' characters. "Control-backspace deletes word left, Control-DEL deletes word right." "Control-left/right Arrow moves by words in a strange but useful way." It might be more useful if the REs were expanded. ---------- messages: 218307 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: test needed status: open title: Idle: updata fixwordbreaks() for unicode identifiers type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 03:35:57 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 May 2014 01:35:57 +0000 Subject: [issue21475] Support the Sitemap and Crawl-delay extensions in robotparser Message-ID: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Resources: * http://en.wikipedia.org/wiki/Robots_exclusion_standard#Nonstandard_extensions * https://support.google.com/webmasters/answer/183669?hl=en * https://github.com/seomoz/reppy ---------- components: Library (Lib) keywords: easy messages: 218308 nosy: rhettinger priority: normal severity: normal status: open title: Support the Sitemap and Crawl-delay extensions in robotparser type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 04:58:05 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Kucharski?=) Date: Mon, 12 May 2014 02:58:05 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse Message-ID: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> New submission from ?ukasz Kucharski: The behaviour of the method for both classes seem to be a little different. Executing `Parser.parse(fp)` does not close the file pointer passed while Executing `BytesParser.parse` does. I think this caused by fact that `BytesParser.parse` implementation is using `with` statement. Writing this fp = TextIOWrapper(file_pointer, encoding='ascii', errors='surrogateescape') with fp: return self.parser.parse(fp, headersonly) file_pointer.seek(0) The original `file_pointer` gets closed and the call to `seek` fails. I am not sure whether such behaviour is intended, and whether, the `with` behaves badly, or the `TextIOWrapper`, or the `BytesParser`, thus I am unable to suggest or provide a patch. But I think the behaviour should be consistent and/or documented. I attached a file that depicts the issue. The problem originated from SO: http://stackoverflow.com/questions/23599457/how-to-parse-an-email-in-python-without-closing-the-file I think it's a minor issue, but it did cause a code to fail with no apparent reason. ---------- components: email files: mail_test.py messages: 218309 nosy: barry, r.david.murray, ?ukasz.Kucharski priority: normal severity: normal status: open title: Inconsitent behaviour between BytesParser.parse and Parser.parse type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file35220/mail_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 05:37:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 12 May 2014 03:37:50 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <3gRnsT3dbWz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 460203eaf731 by Terry Jan Reedy in branch '2.7': Issue #18104: Add idlelib/idle_test/htest.py with a few sample tests to begin http://hg.python.org/cpython/rev/460203eaf731 New changeset 617656f7b538 by Terry Jan Reedy in branch '3.4': Issue #18104: Add idlelib/idle_test/htest.py with a few sample tests to begin http://hg.python.org/cpython/rev/617656f7b538 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 05:47:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 12 May 2014 03:47:52 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <3gRp541W2Qz7LjM@mail.python.org> Roundup Robot added the comment: New changeset aea4f427902f by Terry Jan Reedy in branch '3.4': Issue #18104: News for 3.4 (which will not merge forward). http://hg.python.org/cpython/rev/aea4f427902f New changeset b7bc43e96041 by Terry Jan Reedy in branch 'default': #18104: null merge of 3.4 News entry http://hg.python.org/cpython/rev/b7bc43e96041 New changeset 7cdb38fa191e by Terry Jan Reedy in branch 'default': Issue #18104: News for 3.4, in proper place. http://hg.python.org/cpython/rev/7cdb38fa191e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 06:08:38 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 May 2014 04:08:38 +0000 Subject: [issue21477] Idle: improve idle_test,htest Message-ID: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> New submission from Terry J. Reedy: #18104 created idle_test/htest.py. Besides adding more tests in other issues, some possible improvements to htest itself follow. Many depend on not reusing run, as it now it, in the runall loop. What is left in common to both might be factored out. * For runall, reuse the same master box so the user does not have to click away each master box to see another (which also appears in a different position). Instead, rewrite the message and if still used, the button. * Make sure tested widgets do not cover the master box. For configSectionNameDialog, an htest parameter was added to the class to change the usual positioning (which was intentionally centered over the parent). * For most tests, eliminate the button and simply display the widget. The button is needed for testing message boxes when one wants to test different entries (the section name dialog). 'button=True' could be added to the spec where needed. * If there is no button to restart a test, then closing the widget should, if possible, close the master. The editor window does this, but that would have to be changed if runall ran in one root. * The pre-existing editor window test hides (withdraws) the master (root) window. This is not necessary and should be changed. ---------- messages: 218312 nosy: sahutd, terry.reedy priority: normal severity: normal status: open title: Idle: improve idle_test,htest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 06:16:37 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 May 2014 04:16:37 +0000 Subject: [issue21477] Idle: improve idle_test,htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1399868197.69.0.438298338962.issue21477@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> terry.reedy stage: -> needs patch type: -> enhancement versions: +Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35221/21477-htest.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 06:17:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 May 2014 04:17:46 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <1399868266.3.0.350177612914.issue18104@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The revised patch, as pushed, will serve as a base for this portion of Saimadhav's GSOC project. #21477 proposes changes to htest itself. Adding tests from other modules will be dependencies of that issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed Added file: http://bugs.python.org/file35222/htest5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 06:47:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 12 May 2014 04:47:54 +0000 Subject: [issue21383] "make touch" fails when the build directory is not the source directory In-Reply-To: <1398760947.89.0.691766045615.issue21383@psf.upfronthosting.co.za> Message-ID: <3gRqQK0fnNz7LjY@mail.python.org> Roundup Robot added the comment: New changeset bc160f985b7b by Ned Deily in branch '3.4': Issue #21383: Allow "make touch" to work when building outside of the http://hg.python.org/cpython/rev/bc160f985b7b New changeset 9493fdad2a75 by Ned Deily in branch 'default': Issue 21383: merge from 3.4 http://hg.python.org/cpython/rev/9493fdad2a75 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 06:54:18 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 12 May 2014 04:54:18 +0000 Subject: [issue21383] "make touch" fails when the build directory is not the source directory In-Reply-To: <1398760947.89.0.691766045615.issue21383@psf.upfronthosting.co.za> Message-ID: <1399870458.41.0.896083757153.issue21383@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 08:25:07 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 12 May 2014 06:25:07 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1399875907.75.0.429180056424.issue21462@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yes, since OpenSSL 1.0.2 is still in beta, the target version for 2.7.7 would be 1.0.1g ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 09:03:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 12 May 2014 07:03:04 +0000 Subject: [issue21474] Idle: updata fixwordbreaks() for unicode identifiers In-Reply-To: <1399858064.02.0.148903090644.issue21474@psf.upfronthosting.co.za> Message-ID: <2761731.FlORVWAWjE@raxxla> Serhiy Storchaka added the comment: I think it is enough to get rid of this function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 09:26:43 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 12 May 2014 07:26:43 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <1399879603.12.0.854047216812.issue21469@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 10:10:25 2014 From: report at bugs.python.org (=?utf-8?q?Mateusz_=C5=81oskot?=) Date: Mon, 12 May 2014 08:10:25 +0000 Subject: [issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path In-Reply-To: <1399656076.64.0.0504024076762.issue21452@psf.upfronthosting.co.za> Message-ID: Mateusz ?oskot added the comment: On 9 May 2014 19:21, Tim Golden wrote: > > Fixed. Thanks for the report > Thank you for the fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 11:18:30 2014 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 12 May 2014 09:18:30 +0000 Subject: [issue1599254] mailbox: other programs' messages can vanish without trace Message-ID: <1399886310.26.0.173960388935.issue1599254@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 11:24:52 2014 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 12 May 2014 09:24:52 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1399886692.24.0.320881609641.issue20115@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 11:26:56 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 12 May 2014 09:26:56 +0000 Subject: [issue21475] Support the Sitemap and Crawl-delay extensions in robotparser In-Reply-To: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za> Message-ID: <1399886816.02.0.340313888668.issue21475@psf.upfronthosting.co.za> Berker Peksag added the comment: There is a patch for Crawl-delay in issue 16099. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 11:29:13 2014 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 12 May 2014 09:29:13 +0000 Subject: [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <1399886953.2.0.585779540562.issue21221@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 11:32:53 2014 From: report at bugs.python.org (Martin Dengler) Date: Mon, 12 May 2014 09:32:53 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1399887173.94.0.922299891568.issue21423@psf.upfronthosting.co.za> Changes by Martin Dengler : ---------- nosy: +mdengler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 14:11:27 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 12 May 2014 12:11:27 +0000 Subject: [issue17756] test_syntax_error fails when run in the installed location In-Reply-To: <1366111959.84.0.955866306047.issue17756@psf.upfronthosting.co.za> Message-ID: <1399896687.97.0.253104381079.issue17756@psf.upfronthosting.co.za> Michael Foord added the comment: It looks like the simplest fix would be to change "NameError:" to "NameError", as the problem is that they're (sometimes!?) on separate lines. This still tests what we want to test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 14:17:57 2014 From: report at bugs.python.org (Matthias Klose) Date: Mon, 12 May 2014 12:17:57 +0000 Subject: [issue17756] test_syntax_error fails when run in the installed location In-Reply-To: <1366111959.84.0.955866306047.issue17756@psf.upfronthosting.co.za> Message-ID: <1399897077.55.0.969609195549.issue17756@psf.upfronthosting.co.za> Matthias Klose added the comment: sure, doing this. my follow-up question was if it is necessary to fix anything else in unittest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 14:56:34 2014 From: report at bugs.python.org (Dmitry Andreychuk) Date: Mon, 12 May 2014 12:56:34 +0000 Subject: [issue21478] mock calls don't propagate to parent (autospec) Message-ID: <1399899394.81.0.714942512868.issue21478@psf.upfronthosting.co.za> New submission from Dmitry Andreychuk: Calls to autospecced mock functions are not recorded to mock_calls list of parent mock. This only happens if autospec is used and the original object is a function. Example: import unittest.mock as mock def foo(): pass parent = mock.Mock() parent.child = mock.create_autospec(foo) parent.child() print(parent.mock_calls) Output: [] Expected output: [call.child()] It works fine if foo function is substituted with a class. Initially I came across this problem with patch() and attach_mock() but I simplified it for the demonstration. ---------- components: Library (Lib) messages: 218321 nosy: and priority: normal severity: normal status: open title: mock calls don't propagate to parent (autospec) type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 15:57:03 2014 From: report at bugs.python.org (Martin Dengler) Date: Mon, 12 May 2014 13:57:03 +0000 Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za> Message-ID: <1399903023.37.0.827755200911.issue9400@psf.upfronthosting.co.za> Changes by Martin Dengler : ---------- nosy: +mdengler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 15:58:09 2014 From: report at bugs.python.org (Martin Dengler) Date: Mon, 12 May 2014 13:58:09 +0000 Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za> Message-ID: <1399903089.01.0.402723576115.issue8296@psf.upfronthosting.co.za> Changes by Martin Dengler : ---------- nosy: +mdengler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 16:51:22 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 12 May 2014 14:51:22 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1399906282.35.0.693455304873.issue21198@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag, serhiy.storchaka stage: needs patch -> patch review Added file: http://bugs.python.org/file35223/issue21198.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 16:54:40 2014 From: report at bugs.python.org (mattip) Date: Mon, 12 May 2014 14:54:40 +0000 Subject: [issue10744] ctypes arrays have incorrect buffer information (PEP-3118) In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za> Message-ID: <1399906480.36.0.962967889696.issue10744@psf.upfronthosting.co.za> mattip added the comment: Updated patch for default for empty shape, thanks eryksun ---------- Added file: http://bugs.python.org/file35224/hg-default-ctypes-fix-pep3118-format-strings-for-arrays-update.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 17:01:15 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 May 2014 15:01:15 +0000 Subject: [issue16099] robotparser doesn't support request rate and crawl delay parameters In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za> Message-ID: <1399906875.23.0.0969096726426.issue16099@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 17:01:39 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 12 May 2014 15:01:39 +0000 Subject: [issue21479] Document TarFile.open() as a classmethod Message-ID: <1399906899.24.0.584343681531.issue21479@psf.upfronthosting.co.za> New submission from Berker Peksag: The patch also updates the signature of TarFile.open(). ---------- assignee: docs at python components: Documentation files: tarfile-open-classmethod.diff keywords: patch messages: 218323 nosy: berker.peksag, docs at python, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Document TarFile.open() as a classmethod versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35225/tarfile-open-classmethod.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 17:34:47 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 12 May 2014 15:34:47 +0000 Subject: [issue20872] dbm/gdbm/ndbm close methods are not document In-Reply-To: <1394297879.28.0.882591650164.issue20872@psf.upfronthosting.co.za> Message-ID: <1399908887.61.0.889619064534.issue20872@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review versions: -Python 3.3 Added file: http://bugs.python.org/file35226/issue20872.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 17:56:38 2014 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 12 May 2014 15:56:38 +0000 Subject: [issue21480] A build now requires... Message-ID: New submission from Skip Montanaro: It's been awhile since I pulled from Mercurial and built, but I tried today. I almost immediately ran into an error. The configure step worked fine, but make, not so much: % make python ./Tools/scripts/generate_opcode_h.py ./Lib/opcode.py ./Include/opcode.h /opt/TWWfsw/bin/gmkdir -p Include python ./Parser/asdl_c.py -h Include ./Parser/Python.asdl Traceback (most recent call last): File "./Parser/asdl_c.py", line 1312, in main(args[0], dump_module) File "./Parser/asdl_c.py", line 1251, in main if not asdl.check(mod): File "/home/skipm/3rdParty/python/cpython/Parser/asdl.py", line 183, in check v = Check() File "/home/skipm/3rdParty/python/cpython/Parser/asdl.py", line 140, in __init__ super().__init__() TypeError: super() takes at least 1 argument (0 given) make: *** [Include/Python-ast.h] Error 1 Trying to figure out what went wrong, I peeked in the Makefile and found: ASDLGEN_FILES= $(srcdir)/Parser/asdl.py $(srcdir)/Parser/asdl_c.py # XXX Note that a build now requires Python exist before the build starts ASDLGEN= python $(srcdir)/Parser/asdl_c.py This is bothersome on a couple levels. One, it assumes that "python" means "Python 3" (which it doesn't mean here in the office). Two, it doesnt' offer any suggestions about how to work around this "missing bootstrap". After a couple minutes fussing around, I finally got around the problem with a few judicious "touch" commands. It would be nice if * The above XXX comment was expanded to describe the necessary workaround * Even better, some sort of "asdl-bootstrap" target (referenced in the above comment) was added to the Makefile which sprinkled the necessary pixie dust to artificially satisfy the AST_H and AST_C targets. The bootstrap target shouldn't ever be executed automatically, but be available to execute manually. I think this would be sufficient: # For people building for the first time without an existing Python 3 asdl-bootstrap: touch $(AST_H) $(AST_C) ---------- messages: 218324 nosy: skip.montanaro priority: normal severity: normal status: open title: A build now requires... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:07:12 2014 From: report at bugs.python.org (Tal Einat) Date: Mon, 12 May 2014 16:07:12 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <1399910832.91.0.0563023022115.issue21469@psf.upfronthosting.co.za> Tal Einat added the comment: Changes LGTM. This module could certainly use some cleanup and updates. For example, last_changed should be a property and always accessed one way (instead of either .mtime() or .last_changed) and should be initialized to None instead of zero to avoid ambiguity, and the and/or trick should be replaced with if/else. Would anyone review such a patch if I created one? ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:08:22 2014 From: report at bugs.python.org (Joe Borg) Date: Mon, 12 May 2014 16:08:22 +0000 Subject: [issue21481] Argpase Namespace object methods __eq__ and __ne__ raise TypeError when comparing to None Message-ID: <1399910902.34.0.399069985077.issue21481@psf.upfronthosting.co.za> New submission from Joe Borg: See example: >>> import argparse >>> a = argparse.ArgumentParser() >>> b = a.parse_args([]) >>> if b != None: ... print "hey" File "", line 2 print "hey" ^ SyntaxError: invalid syntax >>> >>> if b != None: ... print("hey") ... Traceback (most recent call last): File "", line 1, in File "/cfd/software/Python/340/lib/python3.4/argparse.py", line 1202, in __ne__ return not (self == other) File "/cfd/software/Python/340/lib/python3.4/argparse.py", line 1199, in __eq__ return vars(self) == vars(other) TypeError: vars() argument must have __dict__ attribute ---------- components: Library (Lib) messages: 218326 nosy: Joe.Borg priority: normal severity: normal status: open title: Argpase Namespace object methods __eq__ and __ne__ raise TypeError when comparing to None versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:09:00 2014 From: report at bugs.python.org (Joe Chan) Date: Mon, 12 May 2014 16:09:00 +0000 Subject: [issue21482] get_versions() in cygwinccomiler.py cannot return correct gcc version Message-ID: <1399910940.73.0.452990357342.issue21482@psf.upfronthosting.co.za> New submission from Joe Chan: cannot return correct gcc version if the path name contains "space". Suggest to change to: $ diff -rupN cygwinccompiler.py.original cygwinccompiler.py --- cygwinccompiler.py.original 2014-05-12 23:54:01.296303800 +0800 +++ cygwinccompiler.py 2014-05-12 23:59:57.429673400 +0800 @@ -418,14 +418,14 @@ def get_versions(): gcc_exe = find_executable('gcc') if gcc_exe: - out = os.popen(gcc_exe + ' -dumpversion','r') + out = os.popen('"%s" -dumpversion'%gcc_exe,'r') out_string = out.read() out.close() result = re.search('(\d+\.\d+(\.\d+)*)',out_string) if result: gcc_version = LooseVersion(result.group(1)) else: - gcc_version = None + gcc_version = None else: gcc_version = None ld_exe = find_executable('ld') ---------- components: Windows messages: 218327 nosy: 3togo priority: normal severity: normal status: open title: get_versions() in cygwinccomiler.py cannot return correct gcc version type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:09:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 16:09:49 +0000 Subject: [issue21480] A build now requires... In-Reply-To: Message-ID: <1399910989.51.0.938070338979.issue21480@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Does "make touch" work for you as well? ---------- components: +Devguide nosy: +eli.bendersky, ezio.melotti, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:10:09 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 12 May 2014 16:10:09 +0000 Subject: [issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF In-Reply-To: <1395153249.12.0.327856107433.issue20969@psf.upfronthosting.co.za> Message-ID: <1399911009.03.0.255908468545.issue20969@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch. I followed Antoine's name suggestion. PSF would more suitable for the "epub_publisher" option: http://sphinx-doc.org/config.html#confval-epub_publisher ---------- keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review Added file: http://bugs.python.org/file35227/issue20969.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:11:42 2014 From: report at bugs.python.org (Joe Borg) Date: Mon, 12 May 2014 16:11:42 +0000 Subject: [issue21481] Argpase Namespace object methods __eq__ and __ne__ raise TypeError when comparing to None In-Reply-To: <1399910902.34.0.399069985077.issue21481@psf.upfronthosting.co.za> Message-ID: <1399911102.83.0.302981193026.issue21481@psf.upfronthosting.co.za> Joe Borg added the comment: I believe this comes from doing vars(None). But why would this be happening if Namespace is empty. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:13:14 2014 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 12 May 2014 16:13:14 +0000 Subject: [issue21480] A build now requires... In-Reply-To: Message-ID: <1399911194.56.0.81230550607.issue21480@psf.upfronthosting.co.za> Eli Bendersky added the comment: Skip, PTAL at the devguide. https://docs.python.org/devguide/setup.html#avoiding-re-creating-auto-generated-files ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:27:14 2014 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 12 May 2014 16:27:14 +0000 Subject: [issue21480] A build now requires... In-Reply-To: <1399910989.51.0.938070338979.issue21480@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: > Does "make touch" work for you as well? Hadn't tried, and wasn't aware of its existence. I searched Makefile for things like AST_H. Perhaps: * Note "make touch" where the "A build now requires..." comment exists. That comment currently discourages users, as it gives no idea about the possibility of a workaround for a missing python. * Add a comment to the touch target identifying its purpose. It hadn't occurred to me to read the dev guide. That's for new contributors, not for old, lapsed contributors. Also, it still seems to me that the ASDLGEN definition should reference something that is explicitly "Python 3" and can't accidentally execute a Python 2.x interpreter (or, the AST-generation script should work in both Python 2.x and 3.x). S ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:27:20 2014 From: report at bugs.python.org (Joe Chan) Date: Mon, 12 May 2014 16:27:20 +0000 Subject: [issue21482] get_versions() in cygwinccomiler.py cannot return correct gcc version In-Reply-To: <1399910940.73.0.452990357342.issue21482@psf.upfronthosting.co.za> Message-ID: <1399912040.39.0.123678788869.issue21482@psf.upfronthosting.co.za> Joe Chan added the comment: better to parenthesis all three exes[gcc, ld and dllwrap] with "%s" to better support path names that contain non-alphanumeric characters. $ diff -rupN cygwinccompiler.py.original cygwinccompiler.py --- cygwinccompiler.py.original 2014-05-12 23:54:01.296303800 +0800 +++ cygwinccompiler.py 2014-05-13 00:24:08.754684500 +0800 @@ -418,19 +418,19 @@ def get_versions(): gcc_exe = find_executable('gcc') if gcc_exe: - out = os.popen(gcc_exe + ' -dumpversion','r') + out = os.popen('"%s" -dumpversion'%gcc_exe,'r') out_string = out.read() out.close() result = re.search('(\d+\.\d+(\.\d+)*)',out_string) if result: gcc_version = LooseVersion(result.group(1)) else: - gcc_version = None + gcc_version = None else: gcc_version = None ld_exe = find_executable('ld') if ld_exe: - out = os.popen(ld_exe + ' -v','r') + out = os.popen('"%s" -v'%ld_exe,'r') out_string = out.read() out.close() result = re.search('(\d+\.\d+(\.\d+)*)',out_string) @@ -442,7 +442,7 @@ def get_versions(): ld_version = None dllwrap_exe = find_executable('dllwrap') if dllwrap_exe: - out = os.popen(dllwrap_exe + ' --version','r') + out = os.popen('"%s" --version'%dllwrap_exe,'r') out_string = out.read() out.close() result = re.search(' (\d+\.\d+(\.\d+)*)',out_string) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:34:03 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 16:34:03 +0000 Subject: [issue20826] Faster implementation to collapse consecutive ip-networks In-Reply-To: <1393771140.68.0.719869740699.issue20826@psf.upfronthosting.co.za> Message-ID: <1399912443.67.0.847064728397.issue20826@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a much faster patch, around 30x faster than the original code. With exhuma's data set and tester.py, the original code gives: $ time python3.4 tester.py Execution time: 5.949284339199949 seconds real 0m30.152s user 0m30.104s sys 0m0.016s The patched code gives: $ time ./python tester.py Execution time: 0.25444041779992405 seconds real 0m1.695s user 0m1.681s sys 0m0.012s exhuma, perhaps you want to test with other data sets? ---------- Added file: http://bugs.python.org/file35228/faster_collapse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:45:17 2014 From: report at bugs.python.org (Josh Triplett) Date: Mon, 12 May 2014 16:45:17 +0000 Subject: [issue12556] Disable size checks in mmap.mmap() In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za> Message-ID: <1399913117.73.0.123490724498.issue12556@psf.upfronthosting.co.za> Josh Triplett added the comment: This rejection is indeed problematic. If mmap.mmap receives an explicit size, checking that size against stat will break on devices or special files. It's perfectly reasonable that mmap.mmap's automatic logic when passed length=0 (to map the entire file) won't work if stat says the file has length 0, but the mmap syscall works fine on special files with length 0 (or devices), and mmap.mmap should work in that case as well. ---------- nosy: +joshtriplett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:48:28 2014 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 12 May 2014 16:48:28 +0000 Subject: [issue21483] Skip os.utime() test on NFS? Message-ID: New submission from Skip Montanaro: I got a strange error during "make test" in a fresh build (hg clone ; ./configure ; make ; make test) Traceback (most recent call last): File "Lib/test/test_import.py", line 293, in test_timestamp_overflow os.utime(source, (2 ** 33 - 5, 2 ** 33 - 5)) OSError: [Errno 22] Invalid argument It took me a little while to figure out what was wrong. A simple check succeeded: >>> import os >>> os.utime("/tmp/trash", (2 ** 33 - 5, 2 ** 33 - 5)) >>> 2**33-5 8589934587 After a bit of poking around, I realized test.support.TESTFN is on an NFS filesystem in my work environment: >>> import importlib >>> from test.support import TESTFN >>> TESTFN '@test_31576_tmp' >>> import sys >>> sys.path.insert(0, os.curdir) >>> source = TESTFN + ".py" >>> compiled = importlib.util.cache_from_source(source) >>> compiled '__pycache__/@test_31576_tmp.cpython-35.pyc' >>> open(source, 'w') <_io.TextIOWrapper name='@test_31576_tmp.py' mode='w' encoding='ANSI_X3.4-1968'> >>> source '@test_31576_tmp.py' >>> os.path.getmtime(source) 1399912946.9349897 >>> 2**33-5 8589934587 >>> os.utime(source, (2 ** 33 - 5, 2 ** 33 - 5)) Traceback (most recent call last): File "", line 1, in OSError: [Errno 22] Invalid argument >>> os.utime("/tmp/trash", (2 ** 33 - 5, 2 ** 33 - 5)) >>> os.curdir '.' >>> os.getcwd() '/home/skipm/3rdParty/python/cpython' >>> blade% df -h . Filesystem Size Used Avail Use% Mounted on nfshost3:/global/export/home/skipm 2.1T 1.5T 639G 71% /home/skipm Should this test be skipped on NFS-mounted filesystems? Or should the test environment try to insure TESTFN is created on a local filesystem? Skip ---------- messages: 218336 nosy: skip.montanaro priority: normal severity: normal status: open title: Skip os.utime() test on NFS? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:53:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 16:53:17 +0000 Subject: [issue20826] Faster implementation to collapse consecutive ip-networks In-Reply-To: <1393771140.68.0.719869740699.issue20826@psf.upfronthosting.co.za> Message-ID: <1399913597.33.0.539234623003.issue20826@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Uh, those measurements are wrong, sorry, since tester.py doesn't consume the iterator. When consuming the iterator, the patch is ~ 4x faster than the original code, which is more reasonable :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 18:58:01 2014 From: report at bugs.python.org (Feliks) Date: Mon, 12 May 2014 16:58:01 +0000 Subject: [issue21484] More clarity needed about difference between "x += e" and "x = x + e" Message-ID: <1399913881.84.0.586979222354.issue21484@psf.upfronthosting.co.za> New submission from Feliks: In Sec. 7.2.1 of the Language Reference, in the description of "+=" we have: "Also, when possible, the actual operation is performed in-place, meaning that rather than creating a new object and assigning that to the target, the old object is modified instead." Although this is quite accurate, not all the consequences are immediately obvious, and sometimes they are quite serious. I would suggest adding a note that points the reader's attention in particular to the phenomenon exhibited in the following example: >>> def f(ls): ls += [2] ... >>> def g(ls): ls = ls + [2] ... >>> a = [1] >>> g(a) >>> a [1] >>> f(a) >>> a [1, 2] ---------- assignee: docs at python components: Documentation messages: 218338 nosy: Kluzniak, docs at python priority: normal severity: normal status: open title: More clarity needed about difference between "x += e" and "x = x + e" type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 19:11:22 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 12 May 2014 17:11:22 +0000 Subject: [issue21484] More clarity needed about difference between "x += e" and "x = x + e" In-Reply-To: <1399913881.84.0.586979222354.issue21484@psf.upfronthosting.co.za> Message-ID: <1399914682.35.0.79435782779.issue21484@psf.upfronthosting.co.za> Josh Rosenberg added the comment: It seems to me like that is one of the most obvious consequences. How is this not an immediately obvious consequence? ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 19:12:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 17:12:39 +0000 Subject: [issue20826] Faster implementation to collapse consecutive ip-networks In-Reply-To: <1393771140.68.0.719869740699.issue20826@psf.upfronthosting.co.za> Message-ID: <1399914759.24.0.194716935021.issue20826@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It seems like the speed of Network.supernet() is a bottleneck here. issue16531 would probably allow making supernet() much faster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 19:12:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 17:12:44 +0000 Subject: [issue16531] Allow IPNetwork to take a tuple In-Reply-To: <1353621566.3.0.0992835206333.issue16531@psf.upfronthosting.co.za> Message-ID: <1399914764.86.0.439019082866.issue16531@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: needs patch -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 19:48:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 17:48:19 +0000 Subject: [issue16531] Allow IPNetwork to take a tuple In-Reply-To: <1353621566.3.0.0992835206333.issue16531@psf.upfronthosting.co.za> Message-ID: <1399916899.49.0.24906362581.issue16531@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch with more tests, documentation updates, and an optimized version of the supernet() that's now 5x faster than the original. I would like to commit this if there's no further comment. ---------- Added file: http://bugs.python.org/file35229/issue16531-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 19:57:43 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 12 May 2014 17:57:43 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1399917463.69.0.696046250088.issue13742@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 19:58:31 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 12 May 2014 17:58:31 +0000 Subject: [issue17794] Add a key parameter to PriorityQueue In-Reply-To: <1366331842.58.0.144732937336.issue17794@psf.upfronthosting.co.za> Message-ID: <1399917511.04.0.488931625846.issue17794@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 19:59:23 2014 From: report at bugs.python.org (akira) Date: Mon, 12 May 2014 17:59:23 +0000 Subject: [issue21485] remove unnecesary .flush() calls in the asyncio subprocess code example Message-ID: <1399917563.48.0.572590350966.issue21485@psf.upfronthosting.co.za> New submission from akira: The current code example contains [1]: print("Python failed with exit code %s:" % exitcode) sys.stdout.flush() sys.stdout.buffer.flush() sys.stdout.buffer.write(stdout) sys.stdout.buffer.flush() that looks bizarre. Either a comment should be added that explains why the `.flush()` calls are necessary or they should be removed. I've attached the documentation patch that removes the calls. [1] http://hg.python.org/cpython/file/2af5a52b9b87/Doc/library/asyncio-subprocess.rst#l227 ---------- assignee: docs at python components: Documentation files: docs-subprocess-remove-unnecessary-flush-from-code-example.patch keywords: patch messages: 218342 nosy: akira, docs at python priority: normal severity: normal status: open title: remove unnecesary .flush() calls in the asyncio subprocess code example versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35230/docs-subprocess-remove-unnecessary-flush-from-code-example.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 19:59:55 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 12 May 2014 17:59:55 +0000 Subject: [issue1475692] replacing obj.__dict__ with a subclass of dict Message-ID: <1399917595.25.0.272434501424.issue1475692@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 20:17:45 2014 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Mon, 12 May 2014 18:17:45 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399918665.8.0.863836711624.issue21422@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: Hi, sorry if it's trivial but shouldn't we add a 'shifted_true' test some were to make sure that this behavior change gets noticed next time? def test_shifted_true(self): self.assertEqual(True << 0, 1) self.assertEqual(True << 1, 2) ---------- nosy: +francismb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 20:24:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 18:24:46 +0000 Subject: [issue21486] optimize v4 netmask parsing Message-ID: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Here is a patch to optimize ipv4 netmask parsing by maintaining a cache (there are not many valid ipv4 netmask representations). This should be especially useful with #16531. ---------- components: Library (Lib) files: v4_netmask.patch keywords: patch messages: 218344 nosy: ncoghlan, pitrou, pmoody priority: low severity: normal stage: patch review status: open title: optimize v4 netmask parsing type: performance versions: Python 3.5 Added file: http://bugs.python.org/file35231/v4_netmask.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 20:24:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 18:24:56 +0000 Subject: [issue21486] optimize v4 netmask parsing In-Reply-To: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> Message-ID: <1399919096.08.0.400983112613.issue21486@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- dependencies: +Allow IPNetwork to take a tuple _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 20:33:34 2014 From: report at bugs.python.org (pmoody) Date: Mon, 12 May 2014 18:33:34 +0000 Subject: [issue16531] Allow IPNetwork to take a tuple In-Reply-To: <1353621566.3.0.0992835206333.issue16531@psf.upfronthosting.co.za> Message-ID: <1399919614.69.0.89089285078.issue16531@psf.upfronthosting.co.za> pmoody added the comment: fine by me. this has been on my todo list forever by $payingjob and $family have prevented me from devoting any time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 20:36:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 12 May 2014 18:36:53 +0000 Subject: [issue16531] Allow IPNetwork to take a tuple In-Reply-To: <1353621566.3.0.0992835206333.issue16531@psf.upfronthosting.co.za> Message-ID: <3gS9pr2Td3z7LjX@mail.python.org> Roundup Robot added the comment: New changeset 4e33c343a264 by Antoine Pitrou in branch 'default': Issue #16531: ipaddress.IPv4Network and ipaddress.IPv6Network now accept an (address, netmask) tuple argument, so as to easily construct network objects from existing addresses. http://hg.python.org/cpython/rev/4e33c343a264 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 20:37:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 18:37:22 +0000 Subject: [issue16531] Allow IPNetwork to take a tuple In-Reply-To: <1353621566.3.0.0992835206333.issue16531@psf.upfronthosting.co.za> Message-ID: <1399919842.52.0.0210245408217.issue16531@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the approval, Peter! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 20:51:04 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 12 May 2014 18:51:04 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399920664.15.0.576948203117.issue21422@psf.upfronthosting.co.za> R. David Murray added the comment: Francisco: I'd say that was a good idea. Would you like to propose a patch? (ie: figure out where it should go) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 20:57:34 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 18:57:34 +0000 Subject: [issue21486] optimize v4 & v6 netmask parsing In-Reply-To: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> Message-ID: <1399921054.49.0.986527844973.issue21486@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch, also optimizing v6 netmask parsing (same principle). Before patch: $ ./python -m timeit -s "import ipaddress" "net = ipaddress.IPv6Network(('2001:db8::', 96))" 10000 loops, best of 3: 26.1 usec per loop $ ./python -m timeit -s "import ipaddress" "net = ipaddress.IPv4Network(('10.0.0.0', 23))" 100000 loops, best of 3: 17 usec per loop After patch: $ ./python -m timeit -s "import ipaddress" "net = ipaddress.IPv6Network(('2001:db8::', 96))" 100000 loops, best of 3: 13.8 usec per loop $ ./python -m timeit -s "import ipaddress" "net = ipaddress.IPv4Network(('10.0.0.0', 23))" 100000 loops, best of 3: 14.3 usec per loop ---------- title: optimize v4 netmask parsing -> optimize v4 & v6 netmask parsing Added file: http://bugs.python.org/file35232/netmask.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 20:58:44 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 12 May 2014 18:58:44 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399921124.97.0.322920015156.issue21422@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Use assertIs, since True == 1, but True is not 1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 21:01:56 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 12 May 2014 19:01:56 +0000 Subject: [issue12556] Disable size checks in mmap.mmap() In-Reply-To: <1399913117.73.0.123490724498.issue12556@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: >From a cursory inspection, we only check the size for regular files. What exception are you seeing exactly? What does stat return on this file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 21:05:23 2014 From: report at bugs.python.org (Joe Chan) Date: Mon, 12 May 2014 19:05:23 +0000 Subject: [issue21482] get_versions() in cygwinccomiler.py cannot return correct gcc version In-Reply-To: <1399910940.73.0.452990357342.issue21482@psf.upfronthosting.co.za> Message-ID: <1399921523.84.0.3262795148.issue21482@psf.upfronthosting.co.za> Joe Chan added the comment: To prevent system crashes, I have to exclude msvc runtime library $ diff -rupN cygwinccompiler.py.original cygwinccompiler.py --- cygwinccompiler.py.original 2014-05-12 23:54:01.296303800 +0800 +++ cygwinccompiler.py 2014-05-13 02:59:37.870414900 +0800 @@ -341,7 +341,7 @@ class Mingw32CCompiler (CygwinCCompiler) # Include the appropriate MSVC runtime library if Python was built # with MSVC 7.0 or later. - self.dll_libraries = get_msvcr() + #self.dll_libraries = get_msvcr() # __init__ () @@ -418,19 +418,19 @@ def get_versions(): gcc_exe = find_executable('gcc') if gcc_exe: - out = os.popen(gcc_exe + ' -dumpversion','r') + out = os.popen('"%s" -dumpversion'%gcc_exe,'r') out_string = out.read() out.close() result = re.search('(\d+\.\d+(\.\d+)*)',out_string) if result: gcc_version = LooseVersion(result.group(1)) else: - gcc_version = None + gcc_version = None else: gcc_version = None ld_exe = find_executable('ld') if ld_exe: - out = os.popen(ld_exe + ' -v','r') + out = os.popen('"%s" -v'%ld_exe,'r') out_string = out.read() out.close() result = re.search('(\d+\.\d+(\.\d+)*)',out_string) @@ -442,7 +442,7 @@ def get_versions(): ld_version = None dllwrap_exe = find_executable('dllwrap') if dllwrap_exe: - out = os.popen(dllwrap_exe + ' --version','r') + out = os.popen('"%s" --version'%dllwrap_exe,'r') out_string = out.read() out.close() result = re.search(' (\d+\.\d+(\.\d+)*)',out_string) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 21:06:13 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 12 May 2014 19:06:13 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1399921573.57.0.934815820327.issue7776@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 21:09:40 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 12 May 2014 19:09:40 +0000 Subject: [issue21485] remove unnecesary .flush() calls in the asyncio subprocess code example In-Reply-To: <1399917563.48.0.572590350966.issue21485@psf.upfronthosting.co.za> Message-ID: <1399921780.89.0.551079366693.issue21485@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 21:09:44 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 12 May 2014 19:09:44 +0000 Subject: [issue12556] Disable size checks in mmap.mmap() In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: Scratch that. I'll try to work on a patch that doesn't break guarantees for regular files (we try to limit the possibilities of segfault). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 21:10:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 19:10:21 +0000 Subject: [issue20826] Faster implementation to collapse consecutive ip-networks In-Reply-To: <1393771140.68.0.719869740699.issue20826@psf.upfronthosting.co.za> Message-ID: <1399921821.37.0.5838269591.issue20826@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch, a bit faster yet. After issue16531 is committed, it is now ~15x faster than 3.4. ---------- Added file: http://bugs.python.org/file35233/faster_collapse2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 21:10:47 2014 From: report at bugs.python.org (Donald Stufft) Date: Mon, 12 May 2014 19:10:47 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1399921847.45.0.0919093699657.issue7776@psf.upfronthosting.co.za> Donald Stufft added the comment: Just an update, the issue is fixed in urllib3 and that has been pulled into requests. Requests is currently prepping to release a new version which I'll pull into pip and issue a pip 1.5.6 release which can be pulled into CPython which should fix this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 21:39:22 2014 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 12 May 2014 19:39:22 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <1399923562.12.0.278810694791.issue21469@psf.upfronthosting.co.za> Skip Montanaro added the comment: Can this change be (easily) tested? If so, a test case akin to your original example would be nice. ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 22:04:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 20:04:23 +0000 Subject: [issue21487] Assorted ipaddress performance improvements Message-ID: <1399925063.26.0.615670484521.issue21487@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Now that issue #16531 has been committed, it becomes possible to make some operations faster. Attached patch makes summarize_address_range() ~2x faster and Network.subnets() ~4x faster. ---------- components: Library (Lib) files: ipaddr_perf.patch keywords: patch messages: 218357 nosy: ncoghlan, pitrou, pmoody priority: normal severity: normal stage: patch review status: open title: Assorted ipaddress performance improvements type: performance versions: Python 3.5 Added file: http://bugs.python.org/file35234/ipaddr_perf.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 22:43:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 12 May 2014 20:43:29 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <3gSDcw63d5z7Ljf@mail.python.org> Roundup Robot added the comment: New changeset ef49aaad3812 by Victor Stinner in branch '3.4': Issue #21422: Add a test to check that bool << int and bool >> int return an int http://hg.python.org/cpython/rev/ef49aaad3812 New changeset 3da4aed1d18a by Victor Stinner in branch 'default': (Merge 3.4) Issue #21422: Add a test to check that bool << int and bool >> int http://hg.python.org/cpython/rev/3da4aed1d18a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 22:44:42 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 20:44:42 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399927482.4.0.217254676037.issue21422@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, 3 core dev are opposed to the change, I close the issue. I added a test on bool >> int and bool << int to ensure that the result is an int. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 22:46:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 20:46:21 +0000 Subject: [issue21420] Optimize 2 ** n: implement it as 1 << n In-Reply-To: <1399067662.75.0.0621982207381.issue21420@psf.upfronthosting.co.za> Message-ID: <1399927581.8.0.271186235614.issue21420@psf.upfronthosting.co.za> STINNER Victor added the comment: My main motivation was to use calloc() (issue #21419) for 2**n. It looks like using calloc() for this is only useful for very rare cases (very large value of n: result larger than 1 MB). I close the issue. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 22:46:38 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 12 May 2014 20:46:38 +0000 Subject: [issue21478] mock calls don't propagate to parent (autospec) In-Reply-To: <1399899394.81.0.714942512868.issue21478@psf.upfronthosting.co.za> Message-ID: <1399927598.22.0.382585027965.issue21478@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 22:48:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 20:48:01 +0000 Subject: [issue21419] Use calloc() instead of malloc() for int << int (lshift) In-Reply-To: <1399063907.65.0.694619539973.issue21419@psf.upfronthosting.co.za> Message-ID: <1399927681.58.0.418473957888.issue21419@psf.upfronthosting.co.za> STINNER Victor added the comment: The optimization of 2**n looks to be only useful for very large value of n, result larger than 1 MB. This use case is very rare, and you should probably use another library (GMP, numpy, or something else) for such large numbers. I close the issue. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 22:48:16 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 12 May 2014 20:48:16 +0000 Subject: [issue21478] mock calls don't propagate to parent (autospec) In-Reply-To: <1399899394.81.0.714942512868.issue21478@psf.upfronthosting.co.za> Message-ID: <1399927696.94.0.851011734333.issue21478@psf.upfronthosting.co.za> Michael Foord added the comment: Mock objects detect when another mock is added as a "child", but they don't currently detect that a function created by autospec has been added. It should be a fairly easy fix. ---------- assignee: -> michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 22:49:31 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 12 May 2014 20:49:31 +0000 Subject: [issue21478] mock calls don't propagate to parent (autospec) In-Reply-To: <1399899394.81.0.714942512868.issue21478@psf.upfronthosting.co.za> Message-ID: <1399927771.96.0.0426564986404.issue21478@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- nosy: +kushal.das stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 23:04:49 2014 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Mon, 12 May 2014 21:04:49 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399928689.57.0.582972770646.issue21422@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: I Victor you were so fast, I started with one patch also in bool (at least the place was right). The problem is that I was getting some extrage (for me at least). As far I hat: def test_shifted_true(self): with self.assertRaises(ValueError): True << -1 self.assertIs(True << 0, 1) self.assertIs(True << 1, 2) self.assertEqual(True << 63, 1 << 63) self.assertIs(True << 63, 1 << 63) And I'm getting: ====================================================================== FAIL: test_shifted_true (test.test_bool.BoolTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/ci/Prog/cpython/src/Lib/test/test_bool.py", line 349, in test_shifted_true self.assertIs(True << 63, 1 << 63) AssertionError: 9223372036854775808 is not 9223372036854775808 ---------------------------------------------------------------------- That's: ./python --version Python 3.5.0a0 >>> type(True<<63) >>> type(1<<63) hg tip changeset: 90664:4e33c343a264 What I'm doing wrong? That's: ./python --version Python 3.5.0a0 >>> type(True<<63) >>> type(1<<63) hg tip changeset: 90664:4e33c343a264 What I was doing wrong? Thanks in advance! francis ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 23:18:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 21:18:41 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399929521.66.0.22538391131.issue21422@psf.upfronthosting.co.za> STINNER Victor added the comment: > What I was doing wrong? The "is" operator should only be used to compare identical objects. Small integers (range -5..255 if I remember correctly) are singletons. I prefer to not rely on this implementation detail in a unit test of the Python standard library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 23:23:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 21:23:40 +0000 Subject: [issue21384] Windows: Make handle non inheritable by default In-Reply-To: <1398761981.56.0.701422046655.issue21384@psf.upfronthosting.co.za> Message-ID: <1399929820.32.0.249695352324.issue21384@psf.upfronthosting.co.za> STINNER Victor added the comment: > For example, hCryptProv in Python/random.c is inheritable or not? This is not a standard handle. GetHandleInformation() fails with a Windows error 6 (invalid descriptor). I listed inheritable handles with a loop on range(0, 0x1001): only handles of stdin, stdout and stderr are inheritable. The other handles are not inheritable. I also listed handles of parent and child processes using "handle.exe" tool from Microsoft. I see that the child has less open handle, all file handles that I opened manually are not inheried, and everything looks fine. So I think that the issue can now be closed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 23:25:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 12 May 2014 21:25:35 +0000 Subject: [issue21485] remove unnecesary .flush() calls in the asyncio subprocess code example In-Reply-To: <1399917563.48.0.572590350966.issue21485@psf.upfronthosting.co.za> Message-ID: <3gSFYV3RwJz7LjP@mail.python.org> Roundup Robot added the comment: New changeset c0404f0da01a by Victor Stinner in branch '3.4': Issue #21485: remove unnecesary .flush() calls in the asyncio subprocess code http://hg.python.org/cpython/rev/c0404f0da01a New changeset 3c26389d741c by Victor Stinner in branch 'default': (Merge 3.4) Issue #21485: remove unnecesary .flush() calls in the asyncio http://hg.python.org/cpython/rev/3c26389d741c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 23:26:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 21:26:08 +0000 Subject: [issue21485] remove unnecesary .flush() calls in the asyncio subprocess code example In-Reply-To: <1399917563.48.0.572590350966.issue21485@psf.upfronthosting.co.za> Message-ID: <1399929968.57.0.0264177491948.issue21485@psf.upfronthosting.co.za> STINNER Victor added the comment: I wrote the example and the first call to buffer.flush() is a mistake. Thanks for your patch, I applied it. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 23:31:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 21:31:39 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399930299.63.0.135877353548.issue21470@psf.upfronthosting.co.za> STINNER Victor added the comment: "MT is equidistributed. This a major point in its favor but also implies that there are long stretches of "uninteresting" sequences. When we seed with only a subset the state space, there is a risk of systematically landing in those stretches." What is an uninteresting sequence? What are the problem of these sequences? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 23:47:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 21:47:05 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: <1399576407.19.0.800132565912.issue21455@psf.upfronthosting.co.za> Message-ID: <1399931225.03.0.143877159485.issue21455@psf.upfronthosting.co.za> STINNER Victor added the comment: > Py_MIN(SOMAXCONN, 128) On Windows, it's not the best choice to use this hardcoded limit. socket.SOMAXCONN is 2^31-1. listen() documentation says that Windows chooses a reasonable backlog value for you if you pass SOMAXCONN: http://msdn.microsoft.com/en-us/library/windows/desktop/ms739168%28v=vs.85%29.aspx You should maybe use SOMAXCONN by default on Windows, and Py_MIN(SOMAXCONN, 128) by default on other platforms (UNIX). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 23:57:40 2014 From: report at bugs.python.org (Tim Peters) Date: Mon, 12 May 2014 21:57:40 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399931860.92.0.757744260915.issue21470@psf.upfronthosting.co.za> Tim Peters added the comment: [haypo] > What is an uninteresting sequence? What are the problem of these > sequences? A sequence that would greatly surprise a user. For example, if you generate 32-bit ints from the Twister in one obvious way, there are starting places where you'll get 623 zeroes in a row. And places where you'll get 2**32-1 623 times in a row. Pick a sequence of any 623 32-bit ints, and there's a starting place that will deliver that sequence. And, indeed, a truly random sequence must also display that behavior, but it's nevertheless very surprising when you see one. It's very rare, both in a truly random sequence and in sequences derived from the Twister. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 12 23:59:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 21:59:26 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399931966.46.0.657918466458.issue21470@psf.upfronthosting.co.za> STINNER Victor added the comment: > A sequence that would greatly surprise a user. No user complained past years. I don't think that we should worry so much, because it looks like reading more data from /dev/urandom can be a more serious and concrete issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 00:05:50 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 12 May 2014 22:05:50 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399932350.54.0.0436623283077.issue21422@psf.upfronthosting.co.za> R. David Murray added the comment: Arfrever's advice was misleading...the test would have needed to be assertIsNot(True << 0, 1), but the fact that True is not preserved is not really what we want to test. What we want to test is that the return value is of type 'int', which is what Victor's test checks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 00:10:40 2014 From: report at bugs.python.org (Tim Peters) Date: Mon, 12 May 2014 22:10:40 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399932640.41.0.945572978542.issue21470@psf.upfronthosting.co.za> Tim Peters added the comment: [haypo] > No user complained past years. Raymond said "We've previously had this problem with MT (since resolved, where it is was landed in a very non-random zone)." Do you believe he was wrong? > I don't think that we should worry so much, because it looks like > reading more data from /dev/urandom can be a more serious and > concrete issue. Why do you say that? Most links people have found and posted here clearly say that the Linux warnings about urandom are basically nonsense. Please supply references to back up "serious and concrete" (or point to earlier references, if you found them convincing). I'm with Raymond on this. There is no useful theory that allows us to predict the characteristics of the produced sequences from a set of possible seeds, so limiting the set of possible seeds is potentially dangerous. The theory about equidistribution (etc) is very useful, but relies on mathematical analysis of the _entire_ period of the generator. The only way to span the entire period is to allow for all possible seeds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 00:18:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 22:18:22 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: <1399576407.19.0.800132565912.issue21455@psf.upfronthosting.co.za> Message-ID: <1399933102.71.0.586963037533.issue21455@psf.upfronthosting.co.za> STINNER Victor added the comment: An article suggests to use max(1024, socket.SOMAXCONN) (to "listen() backlog as large as possible") instead of socket.SOMAXCONN because the OS maximum can be larger than SOMAXCONN (and that it's not possible in Python to get the OS value): http://utcc.utoronto.ca/~cks/space/blog/python/AvoidSOMAXCONN?showcomments#comments The following article tries to explain why the default limit is 128 on Linux: https://derrickpetzold.com/p/somaxconn/ Article giving the value chosen by Windows when SOMAXCONN is passed: it depends on the Windows version (between 5 and 50, hard limit of 200 on Windows 7): http://stackoverflow.com/questions/4709756/listen-maximum-queue-size-per-windows-version ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 00:22:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 22:22:39 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399933359.8.0.373164800318.issue21470@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > There is no useful theory that allows us to predict the > characteristics of the produced sequences from a set of possible > seeds, so limiting the set of possible seeds is potentially dangerous. I still find it difficult to understand where is the said danger. As you point out, a sequence of zeroes is a valid random sequence, and there is no reason to believe that a sequence of zeroes is more likely with a 256 bits seed, than with a 20 kbits seed (it might as well be less likely, for all we know). We may as well bump it from 256 to 512 or 1024 bits, but 20 kbits sounds extremely unusual for a program to read from /dev/urandom at startup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 00:42:21 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 12 May 2014 22:42:21 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399120457.78.0.274409942195.issue21422@psf.upfronthosting.co.za> Message-ID: <1399934541.15.0.391084141881.issue21422@psf.upfronthosting.co.za> R. David Murray added the comment: Arfrever pointed out on irc that I misread. It would indeed be assertIs(True << 0, 1), but that wouldn't make a good test because the fact that '1 is 1' is an implementation detail of CPython and can't be relied upon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:18:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 23:18:57 +0000 Subject: [issue21437] document that asyncio.ProactorEventLoop doesn't support SSL In-Reply-To: <1399296732.42.0.791038898639.issue21437@psf.upfronthosting.co.za> Message-ID: <1399936737.74.0.989622635128.issue21437@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +gvanrossum, haypo, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:33:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 12 May 2014 23:33:17 +0000 Subject: [issue21418] Segv during call to super_init in application embedding Python interpreter. In-Reply-To: <1399058560.74.0.137672140336.issue21418@psf.upfronthosting.co.za> Message-ID: <3gSJNr6hf0z7LjN@mail.python.org> Roundup Robot added the comment: New changeset cee528d44b1e by Victor Stinner in branch '3.4': Issue #21418: Fix a crash in the builtin function super() when called without http://hg.python.org/cpython/rev/cee528d44b1e New changeset 53cf343c4fff by Victor Stinner in branch 'default': (Merge 3.4) Issue #21418: Fix a crash in the builtin function super() when http://hg.python.org/cpython/rev/53cf343c4fff ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:35:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 23:35:40 +0000 Subject: [issue21418] Segv during call to super_init in application embedding Python interpreter. In-Reply-To: <1399058560.74.0.137672140336.issue21418@psf.upfronthosting.co.za> Message-ID: <1399937740.81.0.0214437363062.issue21418@psf.upfronthosting.co.za> STINNER Victor added the comment: "While embedding the Python interpreter in an application, I have encountered a crash when the built-in function 'super' is invoked with no arguments." This is not supported. When super() is invoked with no arguments, the class is retrieved (indirectly) from the current frame. In your example, there is no current frame. You can workaround this limitation by passing explicitly the class to super. The crash should be fixed: a RuntimeError is now raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:35:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 23:35:48 +0000 Subject: [issue21418] Segv during call to super_init in application embedding Python interpreter. In-Reply-To: <1399058560.74.0.137672140336.issue21418@psf.upfronthosting.co.za> Message-ID: <1399937748.76.0.724496295974.issue21418@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:35:52 2014 From: report at bugs.python.org (Tim Peters) Date: Mon, 12 May 2014 23:35:52 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399937752.18.0.0201962181488.issue21470@psf.upfronthosting.co.za> Tim Peters added the comment: [pitrou] > I still find it difficult to understand where is the said danger. The theoretical properties that make the Twister so attractive were all proved based on mathematical analysis of its entire period. The only way to get at the whole period is to allow for all possible seeds. If the seeds Python can use are drawn from a relatively tiny subset of the possible seeds, nothing can be said about most of the "proved correct" properties anymore. Maybe they still hold. Maybe they don't. In the absence of analysis (which, AFAIK, is still too difficult to do), the only way to be safe is to refrain from being so bloody "clever" in the interest of saving a few microseconds. > As you point out, a sequence of zeroes is a valid random > sequence, and there is no reason to believe that a sequence > of zeroes is more likely with a 256 bits seed, than with a > 20 kbits seed (it might as well be less likely, for all we know). That's the point: we don't _know_ much of anything if we restrict to a subset of possible seeds. But we DO know if all possible seeds are allowed for. Then the Twister has many nice properties, and provably so. Allowing for all possible seeds is judicious: it's an acknowledgement of our ignorance, and a statement that we're more concerned with correctness than micro-efficiency in a (typically) zero- or one-time-per-process `random` initialization cost. > We may as well bump it from 256 to 512 or 1024 bits, That's as unprincipled as using 1 bit - although _likely_ to give better results ;-) > but 20 kbits sounds extremely unusual for a program to read from > /dev/urandom at startup. At least on my box, starting Python does not import `random`, and the seeding code isn't called at all. It's only called when `random` is imported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:37:30 2014 From: report at bugs.python.org (Brad Aylsworth) Date: Mon, 12 May 2014 23:37:30 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency Message-ID: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> New submission from Brad Aylsworth: The documentation page for codecs (https://docs.python.org/2/library/codecs.html) shows keyword arguments for codecs.encode and codecs.decode, but they throw an error if keyword arguments are used. codecs.decode.__doc__ reports 'decode(obj, [encoding[,errors]]) -> object. This happens on both 2.7.6 and 3.4.0. ---------- assignee: docs at python components: Documentation messages: 218380 nosy: Ouaouaron, docs at python priority: normal severity: normal status: open title: codecs.encode/decode documentation inconsistency type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:37:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 23:37:50 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <1399937870.61.0.73172262218.issue21088@psf.upfronthosting.co.za> STINNER Victor added the comment: Can we now close this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:38:40 2014 From: report at bugs.python.org (Mark Nottingham) Date: Mon, 12 May 2014 23:38:40 +0000 Subject: [issue21308] PEP 466: backport ssl changes In-Reply-To: <9f606957-c0fc-42fe-b0e1-52ea1cb44333@email.android.com> Message-ID: <1399937920.35.0.278551417097.issue21308@psf.upfronthosting.co.za> Changes by Mark Nottingham : ---------- nosy: +mnot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:41:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 12 May 2014 23:41:23 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399937752.18.0.0201962181488.issue21470@psf.upfronthosting.co.za> Message-ID: <1399938080.2339.31.camel@fsol> Antoine Pitrou added the comment: > The theoretical properties that make the Twister so attractive were > all proved based on mathematical analysis of its entire period. The > only way to get at the whole period is to allow for all possible > seeds. > > If the seeds Python can use are drawn from a relatively tiny subset of > the possible seeds, nothing can be said about most of the "proved > correct" properties anymore. Maybe they still hold. Maybe they > don't. In the absence of analysis (which, AFAIK, is still too > difficult to do), the only way to be safe is to refrain from being so > bloody "clever" in the interest of saving a few microseconds. Thanks for the explanation. It's much clearer now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:45:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 May 2014 23:45:25 +0000 Subject: [issue21385] in debug mode, compile(ast) fails with an assertion error if an AST node has no line number information In-Reply-To: <1398762010.89.0.992252148712.issue21385@psf.upfronthosting.co.za> Message-ID: <1399938325.33.0.640799848381.issue21385@psf.upfronthosting.co.za> STINNER Victor added the comment: With the development version (Python 3.5), I reproduce the crash when Python is compiled in debug mode: $ ./python astlinenotest.py python: Python/compile.c:3975: assemble_lnotab: Assertion `d_lineno >= 0' failed. Abandon (core dumped) The problem is that astlinenotest.py creates an AST node without lineno information, which makes an assertion to fail in the compiler. In my astoptimizer project, I use this function to not have to worry of the lineno: def copy_lineno(node, new_node): ast.fix_missing_locations(new_node) ast.copy_location(new_node, node) return new_node ---------- nosy: +haypo title: Compiling modified AST crashes on debug build unless linenumbering discarded -> in debug mode, compile(ast) fails with an assertion error if an AST node has no line number information _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:46:52 2014 From: report at bugs.python.org (Tim Peters) Date: Mon, 12 May 2014 23:46:52 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399938412.56.0.710335138173.issue21470@psf.upfronthosting.co.za> Tim Peters added the comment: > Thanks for the explanation. It's much clearer now. Maybe, but it's also overblown - LOL ;-) That is, no matter what the starting seed, the user will see a microscopically tiny span of the Twister's entire period. So all those "provably correct" properties that depend on whole-period analysis remain pretty much theoretical no matter what we do. It's just a "better safe than sorry" thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 01:56:36 2014 From: report at bugs.python.org (Matthew Fernandez) Date: Mon, 12 May 2014 23:56:36 +0000 Subject: [issue21489] Switching from -OO to -O still uses cached bytecode Message-ID: <1399938996.28.0.0918365412077.issue21489@psf.upfronthosting.co.za> New submission from Matthew Fernandez: Perhaps others wouldn't consider this a bug, but it was definitely surprising to me. When switching between optimisation levels -OO (optimise and strip docstrings) and -O (just optimise), you will find the docstrings are still stripped. E.g. $ ls hello.py world.py $ cat hello.py import world $ cat world.py def foo(): '''I'm a docstring''' pass import sys print 'optimization: %d' % sys.flags.optimize if sys.flags.optimize < 2: print foo.__doc__ else: print 'optimisation is enabled; no docstrings' $ python -OO hello.py optimization: 2 optimisation is enabled; no docstrings $ python -O hello.py optimization: 1 None $ rm world.pyo $ python -O hello.py optimization: 1 I'm a docstring Is this behaviour intentional? ---------- messages: 218385 nosy: Matthew.Fernandez priority: normal severity: normal status: open title: Switching from -OO to -O still uses cached bytecode versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 02:02:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 00:02:43 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1399939363.36.0.689373402775.issue21412@psf.upfronthosting.co.za> STINNER Victor added the comment: > Victor: sure; see attached. Ok, so the error occurs when Python tries to import the _heapq dynamic module: PyModule_Create2() calls PyThreadState_Get() to retrieve to current thread, but it fails. There is a current thread because PyModule_Create2() is called indirectly by PyEval_EvalFrameExReal() (and I don't see where the GIL would be released in the call stack). It looks like a bug in PyThreadState_Get(). This function relies on _Py_atomic_load_relaxed() which is defined in Include/pyatomic.h. This file has an implementation of atomic functions for Intel processors and contains an interesting comment: ... #else /* !gcc x86 */ /* Fall back to other compilers and processors by assuming that simple volatile accesses are atomic. This is false, so people should port this. */ ... It looks like John tries Python on SPARC which may explain the issue. This is just a theory. It also looks like we had SPARC buildbots running on Solaris with system C compiler ("/opt/solarisstudio12.3/bin/cc") and it was able to run tests. I don't understand the link with pymalloc. @John: Did you try to build Python 3.3? Did it work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 02:04:51 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 00:04:51 +0000 Subject: [issue21489] Switching from -OO to -O still uses cached bytecode In-Reply-To: <1399938996.28.0.0918365412077.issue21489@psf.upfronthosting.co.za> Message-ID: <1399939491.27.0.236339600214.issue21489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Not really intentional, it's just a limitation of the current implementation (where the same .pyo files are used for both -O and -OO). Already reported as issue1538778 (which was closed as won't fix). ---------- nosy: +barry, pitrou superseder: -> pyo's are not overwritten by different optimization levels _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 02:06:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 May 2014 00:06:43 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <3gSK7Q3pv9z7Ljs@mail.python.org> Roundup Robot added the comment: New changeset 89a29e92416f by Victor Stinner in branch '3.4': Issue #21398: Fix an unicode error in the pydoc pager when the documentation http://hg.python.org/cpython/rev/89a29e92416f New changeset 3424d65ad5ce by Victor Stinner in branch 'default': (Merge 3.4) Issue #21398: Fix an unicode error in the pydoc pager when the http://hg.python.org/cpython/rev/3424d65ad5ce ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 02:08:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 00:08:11 +0000 Subject: [issue21398] LC_CTYPE=C: pydoc leaves terminal in an unusable state In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za> Message-ID: <1399939691.52.0.23024104296.issue21398@psf.upfronthosting.co.za> STINNER Victor added the comment: I fixed the initial bug and so I close the issue. Open a new issue if you have an idea to restore the terminal state when the pager breaks the terminal. I don't think that it's possible to save/restore the terminal state in a portable way. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 02:22:18 2014 From: report at bugs.python.org (Matthew Fernandez) Date: Tue, 13 May 2014 00:22:18 +0000 Subject: [issue21489] Switching from -OO to -O still uses cached bytecode In-Reply-To: <1399938996.28.0.0918365412077.issue21489@psf.upfronthosting.co.za> Message-ID: <1399940538.82.0.0444001754648.issue21489@psf.upfronthosting.co.za> Matthew Fernandez added the comment: Ah thanks, Antoine. Sorry, failed to find that issue in my prior searching. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 02:27:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 May 2014 00:27:34 +0000 Subject: [issue21226] PyImport_ExecCodeModuleObject not setting module attributes In-Reply-To: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za> Message-ID: <3gSKbR6jTgz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset 7d20e30bd540 by Eric Snow in branch '3.4': Issue #21226: Set all attrs in PyImport_ExecCodeModuleObject. http://hg.python.org/cpython/rev/7d20e30bd540 New changeset bc324a49d0fc by Eric Snow in branch 'default': Merge from 3.4 (for #21226). http://hg.python.org/cpython/rev/bc324a49d0fc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 02:31:35 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 13 May 2014 00:31:35 +0000 Subject: [issue21226] PyImport_ExecCodeModuleObject not setting module attributes In-Reply-To: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za> Message-ID: <1399941095.15.0.133596121665.issue21226@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 02:31:38 2014 From: report at bugs.python.org (Boris Dayma) Date: Tue, 13 May 2014 00:31:38 +0000 Subject: [issue21436] Consider leaving importlib.abc.Loader.load_module() In-Reply-To: <1399291208.69.0.802643633069.issue21436@psf.upfronthosting.co.za> Message-ID: <1399941098.27.0.62195057144.issue21436@psf.upfronthosting.co.za> Changes by Boris Dayma : ---------- nosy: +Borisd13 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 03:03:38 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 13 May 2014 01:03:38 +0000 Subject: [issue21415] Python __new__ method doc typo (it's a class and not a static method) In-Reply-To: <1399026596.96.0.389694886975.issue21415@psf.upfronthosting.co.za> Message-ID: <1399943018.5.0.638087447386.issue21415@psf.upfronthosting.co.za> Eric Snow added the comment: FYI, __new__() is a staticmethod to accommodate subclassing. Several things that happen at instantiation-time (when __new__() is called), including memory allocation, are tied to the class that is passed in and may be different for subclasses. For example: class Spam(int): def __new__(cls, value): self = super().__new__(Spam, value) self._eggs = 10 return self Spam is passed in instead of int (as would happen if it were a classmethod), resulting in extra memory being allocated for _eggs (and for __dict__ among other things). ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 03:28:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 01:28:26 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1399944506.53.0.531246293683.issue21401@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached py2_warn_cmp_bytes_text.patch adds BytesWarning for bytes == unicode, bytes != unicode, unicode == bytes, unicode != bytes and similar comparisons with bytearray. The new warnings are added when -b or -bb command line options are used. As a consequence, a lot of tests are failing with the patch applied and -bb command line option. Some tests are obviously wrong (unicode expected, but the tests use bytes), but it's much more complex to fix tricky modules like urllib, os.path, json and re (sre_parse) to handle "correctly" bytes and unicode. In some other cases, the warning should be made quiet because a same test compares bytes and then text. It also means that programs currently working fine with Python 2.7.6 with "-3 -b" options will start to see new BytesWarning warnings. Is it acceptable? What is the purpose of -b in Python 2? Help developers to notice earlier future Unicode issues in their program, or help them to port their code to Python 3? Maybe the new warnings should only by emited if -3 and -b options are used at the same time? Tell me if you would like to see my work-in-progress patch to fix the whole test suite. Just the stats: $ hg diff --stat Lib/_pyio.py | 16 ++++++++-------- Lib/ctypes/test/test_arrays.py | 12 ++++++------ Lib/ctypes/test/test_buffers.py | 20 ++++++++++---------- Lib/ctypes/test/test_cast.py | 2 +- Lib/ctypes/test/test_memfunctions.py | 10 +++++----- Lib/ctypes/test/test_prototypes.py | 10 +++++----- Lib/ctypes/test/test_structures.py | 2 +- Lib/fractions.py | 1 + Lib/sqlite3/dump.py | 8 ++++---- Lib/sqlite3/test/dump.py | 4 ++-- Lib/sre_parse.py | 3 ++- Lib/test/string_tests.py | 6 +++--- Lib/test/test_builtin.py | 14 ++++++++++---- Lib/test/test_bytes.py | 27 +++++++++++++++++++++++++-- Lib/test/test_format.py | 10 +++++++--- Lib/test/test_future4.py | 2 +- Lib/test/test_pyexpat.py | 28 ++++++++++++++-------------- Lib/test/test_sax.py | 20 ++++++++++---------- Lib/test/test_tempfile.py | 4 ++-- Objects/bytearrayobject.c | 2 +- Objects/stringobject.c | 9 +++++++++ Objects/unicodeobject.c | 8 ++++++++ 22 files changed, 135 insertions(+), 83 deletions(-) A funny one: diff -r 670fb496f1f6 Lib/test/test_future4.py --- a/Lib/test/test_future4.py Sun May 11 23:37:26 2014 -0400 +++ b/Lib/test/test_future4.py Tue May 13 03:28:12 2014 +0200 @@ -43,5 +43,5 @@ class TestFuture(unittest.TestCase): def test_main(): test_support.run_unittest(TestFuture) -if __name__ == "__main__": +if __name__ == b"__main__": test_main() ---------- keywords: +patch Added file: http://bugs.python.org/file35235/py2_warn_cmp_bytes_text.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 03:31:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 01:31:51 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1399944711.71.0.322005154218.issue21401@psf.upfronthosting.co.za> STINNER Victor added the comment: The title of the issue is "python2 -3 does not warn about str/unicode to bytes conversions and comparisons". IMO it would be insane to emit BytesWarning on unicode(str). It would break most code using unicode. six.u() function is based on this feature. For example, six.u("abc") calls unicode("abc") in Python 2. I have no opinion for the encode operation: str(unicode). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 03:38:47 2014 From: report at bugs.python.org (paul j3) Date: Tue, 13 May 2014 01:38:47 +0000 Subject: [issue12806] argparse: Hybrid help text formatter In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za> Message-ID: <1399945127.13.0.661388279597.issue12806@psf.upfronthosting.co.za> paul j3 added the comment: An alternative to passing a Formatter instance to the parser is to use a wrapper function. `HelpFormatter.__init__` takes several keyword args. '_get_formatter' does not use those. However we could define: def format_wrapper(**kwargs): # class 'factory' used to give extra parameters def fnc(prog): cls = argparse.HelpFormatter return cls(prog, **kwargs) return fnc and use that to set the 'width' of the formatter object. parser = argparse.ArgumentParser( formatter_class = format_wrapper(width=40)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 04:35:54 2014 From: report at bugs.python.org (John Beck) Date: Tue, 13 May 2014 02:35:54 +0000 Subject: [issue21412] core dump in PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1399948554.16.0.646052323482.issue21412@psf.upfronthosting.co.za> John Beck added the comment: Victor: * This is not a SPARC-specific issue; the exact same failure occurs on x86. * I had built Python 3.3 (some time ago) but only --without-pymalloc. But I tried just now rebuilt Python 3.3 --with-pymalloc, and it failed in the exact same way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 04:54:57 2014 From: report at bugs.python.org (paul j3) Date: Tue, 13 May 2014 02:54:57 +0000 Subject: [issue12806] argparse: Hybrid help text formatter In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za> Message-ID: <1399949697.44.0.529338761123.issue12806@psf.upfronthosting.co.za> paul j3 added the comment: An alternative to adding a 'ParagraphFormatter' class to 'argparse', is to format the individual text blocks PRIOR to passing them to the 'parser', and use the 'RawTextHelpFormatter'. In the attached script I use a simple function that applies 'textwrap' to each 'line' of the text. Description, epilog, and argument help are formatted in roughly the same manner as in paraformatter.py, but without as many bells and whistles. def mywrap(text,**kwargs): # apply textwrap to each line individually text = text.splitlines() text = [textwrap.fill(line,**kwargs) for line in text] return '\n'.join(text) parser = argparse.ArgumentParser( formatter_class = argparse.RawTextHelpFormatter, description = mywrap(description), epilog = mywrap(epilog, width=40)) I suspect there are tools for doing similar formatting, starting with 'markdown' or 'rsT' paragraphs (though HTML is the usual output). As the formatting becomes more complex it is better to use existing tools than to write something new for 'argparse'. ---------- Added file: http://bugs.python.org/file35236/wrap_sample.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 06:21:46 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 13 May 2014 04:21:46 +0000 Subject: [issue16099] robotparser doesn't support request rate and crawl delay parameters In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za> Message-ID: <1399954906.72.0.968303947441.issue16099@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 06:23:40 2014 From: report at bugs.python.org (Alexey) Date: Tue, 13 May 2014 04:23:40 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1399955020.37.0.966410970552.issue21430@psf.upfronthosting.co.za> Alexey added the comment: Please document this method. I'm developing xmpp client using python 3.4 and it's ssl module. Stuck with this same issue for a few days just because of a lack of documentation. I'm asking you: why should I know about this method not from python documentation, but from search engine and perl's forum (http://www.perlmonks.org/?node_id=845342) ? ---------- nosy: +Animus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 06:24:53 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 13 May 2014 04:24:53 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <1399955093.29.0.465594066037.issue21469@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Changes LGTM. Thanks for the review :-) > This module could certainly use some cleanup and updates. Yes, the API is a mess, but I would like to be very conservative with API modifications (preferably none at all) so we don't break the code of very few people who ever cared enough to use this module. My goal here was just to fix the risk of a false positives. > For example, last_changed should be a property and always > accessed one way (instead of either .mtime() or .last_changed) > and should be initialized to None instead of zero to avoid ambiguity, It's too late for fixing the published API. The time for that was when the module was introduced. > and the and/or trick should be replaced with if/else. Yes, would be a reasonable minor clean-up that wouldn't affect the API. > Would anyone review such a patch if I created one? Yes. Just add the one-line patch to this tracker item and I'll incorporate it with the rest. FWIW, it is perfectly reasonable to add new well-designed API extensions. You can post patches to the open tracker items for Bug 16099 and Bug 21475. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 06:42:06 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 13 May 2014 04:42:06 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399938412.56.0.710335138173.issue21470@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Tim, any idea why openssl, openssh & Co get away with just 32 bytes of seed read from /dev/urandom? Is it because of a much smaller state space of the underlying CSPRNG? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 06:50:45 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 13 May 2014 04:50:45 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: <1399931225.03.0.143877159485.issue21455@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: >> Py_MIN(SOMAXCONN, 128) > > On Windows, it's not the best choice to use this hardcoded limit. socket.SOMAXCONN is 2^31-1. I don't see what this would bring: 128 *is* a reasonable limit. > listen() documentation says that Windows chooses a reasonable backlog value for you if you pass SOMAXCONN: > http://msdn.microsoft.com/en-us/library/windows/desktop/ms739168%28v=vs.85%29.aspx > > You should maybe use SOMAXCONN by default on Windows, and Py_MIN(SOMAXCONN, 128) by default on other platforms (UNIX). Trying to come up with a good heuristic is a lost battle, since it depends not only on the OS but also the application. The goal is to have a default value that works, is large enough to avoid connection drops in common use cases, and not too large to avoid resource consumption. > An article suggests to use max(1024, socket.SOMAXCONN) (to "listen() backlog as large as possible") > instead of socket.SOMAXCONN because the OS maximum can be larger than SOMAXCONN (and that > it's not possible in Python to get the OS value): In theory we could use net.core.somaxconn sysctl & Co (that's what go does), but IMO it's overkill. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 06:57:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 May 2014 04:57:26 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <3gSRZt1pQ9z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 4ea86cd87f95 by Raymond Hettinger in branch '3.4': Issue 21469: Mitigate risk of false positives with robotparser. http://hg.python.org/cpython/rev/4ea86cd87f95 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 07:05:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 May 2014 05:05:32 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <3gSRmC1HJYz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset f67cf5747a26 by Raymond Hettinger in branch '3.4': Issue 21469: Add missing news item http://hg.python.org/cpython/rev/f67cf5747a26 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 07:19:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 May 2014 05:19:00 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <3gSS3l5QgGz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset d4fd55278cec by Raymond Hettinger in branch '2.7': Issue 21469: Mitigate risk of false positives with robotparser. http://hg.python.org/cpython/rev/d4fd55278cec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 07:22:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 May 2014 05:22:57 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <3gSS8J3Rn1z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 560320c10564 by Raymond Hettinger in branch 'default': Issue 21469: Minor code modernization (convert and/or expression to an if/else expression). http://hg.python.org/cpython/rev/560320c10564 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 07:42:00 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 13 May 2014 05:42:00 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1399959720.36.0.470144278927.issue21401@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 07:58:20 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 13 May 2014 05:58:20 +0000 Subject: [issue21469] False positive hazards in robotparser In-Reply-To: <1399740910.18.0.482286720777.issue21469@psf.upfronthosting.co.za> Message-ID: <1399960700.41.0.885892256911.issue21469@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 07:59:23 2014 From: report at bugs.python.org (Bas Wijnen) Date: Tue, 13 May 2014 05:59:23 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1399960763.71.0.426583405135.issue21430@psf.upfronthosting.co.za> Bas Wijnen added the comment: The documentation about non-blocking is clear enough, thank you for pointing it out. However, I would ask to write anything in there that contains the word "pending". The reason is that I didn't find anything in the documentation, looked in the source, found the pending() method and searched the documentation to see how it was defined. If I would have found an explanation that I shouldn't be using it, even if that wasn't the documentation of the method, I would have done the right thing in my program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 08:03:02 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 13 May 2014 06:03:02 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1399960982.39.0.0120371001912.issue19776@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Added a new version of the patch with improvements suggested by Berker Peksag. Thanks for the review! ---------- Added file: http://bugs.python.org/file35237/issue19776.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 08:43:03 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 13 May 2014 06:43:03 +0000 Subject: [issue21308] PEP 466: backport ssl changes In-Reply-To: <9f606957-c0fc-42fe-b0e1-52ea1cb44333@email.android.com> Message-ID: <1399963383.93.0.935315479918.issue21308@psf.upfronthosting.co.za> Nick Coghlan added the comment: Christian, Alex, Donald - is there an in-progress patch for this available at all? 2.7.7rc1 is bearing down on us quite rapidly. Given the likely magnitude of this change, should we consider targeting 2.7.8, and give the OpenStack CI team and others a greater chance to check for any issues based on a source checkout before we publish it for general consumption? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 09:58:42 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 07:58:42 +0000 Subject: [issue21490] Add Py_ABS and Py_STINGIFY macros Message-ID: <1399967922.02.0.0726994682155.issue21490@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patches replaces duplicated C macros with two new shared macros: Py_ABS(x) and Py_STRINGIFY(x). I didn't touch PC/pyconfig.h because it uses 3 macros to stringify instead of just 2 and I don't know why: --- /* We want COMPILER to expand to a string containing _MSC_VER's *value*. * This is horridly tricky, because the stringization operator only works * on macro arguments, and doesn't evaluate macros passed *as* arguments. * Attempts simpler than the following appear doomed to produce "_MSC_VER" * literally in the string. */ #define _Py_PASTE_VERSION(SUFFIX) \ ("[MSC v." _Py_STRINGIZE(_MSC_VER) " " SUFFIX "]") /* e.g., this produces, after compile-time string catenation, * ("[MSC v.1200 32 bit (Intel)]") * * _Py_STRINGIZE(_MSC_VER) expands to * _Py_STRINGIZE1((_MSC_VER)) expands to * _Py_STRINGIZE2(_MSC_VER) but as this call is the result of token-pasting * it's scanned again for macros and so further expands to (under MSVC 6) * _Py_STRINGIZE2(1200) which then expands to * "1200" */ #define _Py_STRINGIZE(X) _Py_STRINGIZE1((X)) #define _Py_STRINGIZE1(X) _Py_STRINGIZE2 ## X #define _Py_STRINGIZE2(X) #X --- Maybe it's time to drop these old macros (only required for MSVC 6?) and use Py_STRINGIFY? I will try with Visual Studio 2010. ---------- files: abs_stringify.patch keywords: patch messages: 218409 nosy: haypo priority: normal severity: normal status: open title: Add Py_ABS and Py_STINGIFY macros versions: Python 3.5 Added file: http://bugs.python.org/file35238/abs_stringify.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:05:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 08:05:11 +0000 Subject: [issue21412] Solaris/Oracle Studio: Fatal Python error: PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1399968311.28.0.749259575077.issue21412@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: core dump in PyThreadState_Get when built --with-pymalloc -> Solaris/Oracle Studio: Fatal Python error: PyThreadState_Get when built --with-pymalloc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:09:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 08:09:21 +0000 Subject: [issue21412] Solaris/Oracle Studio: Fatal Python error: PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1399968561.24.0.637312491727.issue21412@psf.upfronthosting.co.za> STINNER Victor added the comment: "This is not a SPARC-specific issue; the exact same failure occurs on x86." Ah ok, good to know. To me, it looks like a compiler issue. Did you try Stefan's advices in issue #15963? You may try to disable compiler optimizations to see if you get the same behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:11:33 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 08:11:33 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: <1399576407.19.0.800132565912.issue21455@psf.upfronthosting.co.za> Message-ID: <1399968693.85.0.390617573588.issue21455@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum ok, thanks for your explanation Charles-Fran?ois. socket_listen-1.diff looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:13:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 08:13:59 +0000 Subject: [issue21385] in debug mode, compile(ast) fails with an assertion error if an AST node has no line number information In-Reply-To: <1398762010.89.0.992252148712.issue21385@psf.upfronthosting.co.za> Message-ID: <1399968839.19.0.640819908223.issue21385@psf.upfronthosting.co.za> STINNER Victor added the comment: We can maybe modify the compiler to use the line number 1 if the line information is missing? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:40:34 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 08:40:34 +0000 Subject: [issue19775] Provide samefile() on Path objects In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za> Message-ID: <1399970434.63.0.688345991953.issue19775@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sorry, it seems I have let this issue slip. I will update the patch and commit it soon! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:49:14 2014 From: report at bugs.python.org (Ids van der Molen) Date: Tue, 13 May 2014 08:49:14 +0000 Subject: [issue21491] race condition in SocketServer.py ForkingMixIn collect_children Message-ID: <1399970954.74.0.599178198558.issue21491@psf.upfronthosting.co.za> New submission from Ids van der Molen: collect_children routine in SocketServer.py contains two possible race conditions. First one is in while loop "while len(self.active_children) >= self.max_children:". If status of child is collected outside of Socket server (for example in signal handler or something), then the variable self.active_children will not match actual child processes and the os.waitpid(0, 0) within the while loop will raise os.error, errno=10 (ECHILD) "No Child Processes". self.active_children should be emptied in this case, otherwise you'll end up with an endless loop comsuming 100% CPU (as happened to us). The second possible race condition is below in the collect_children routine in the "for child in self.active_children" which contains a statement self.active_children.remove(pid) which would modify the iterator. I do not now about python 2.7, but before this would result in "incorrect iteration". Original code: for child in self.active_children: try: pid, status = os.waitpid(child, os.WNOHANG) except os.error: pid = None if not pid: continue try: self.active_children.remove(pid) except ValueError, e: raise ValueError('%s. x=%d and list=%r' % (e.message, pid, self.active_children)) Fixed code: to_remove = [] for child in self.active_children: try: pid, status = os.waitpid(child, os.WNOHANG) except os.error: pid = None if not pid: continue to_remove.append(pid) for pid in to_remove: try: self.active_children.remove(pid) except ValueError, e: raise ValueError('%s. x=%d and list=%r' % (e.message, pid, self.active_children)) ---------- components: Library (Lib) messages: 218414 nosy: idsvandermolen priority: normal severity: normal status: open title: race condition in SocketServer.py ForkingMixIn collect_children type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:50:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 May 2014 08:50:39 +0000 Subject: [issue19775] Provide samefile() on Path objects In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za> Message-ID: <3gSXly2F8Jz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 197ac5d79456 by Antoine Pitrou in branch 'default': Issue #19775: Add a samefile() method to pathlib Path objects. http://hg.python.org/cpython/rev/197ac5d79456 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:52:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 08:52:06 +0000 Subject: [issue21490] Add Py_ABS and Py_STRINGIFY macros In-Reply-To: <1399967922.02.0.0726994682155.issue21490@psf.upfronthosting.co.za> Message-ID: <1399971126.38.0.661079872119.issue21490@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: Add Py_ABS and Py_STINGIFY macros -> Add Py_ABS and Py_STRINGIFY macros _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:53:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 13 May 2014 08:53:52 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <1399971232.06.0.852655437768.issue21088@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:55:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 08:55:56 +0000 Subject: [issue19775] Provide samefile() on Path objects In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za> Message-ID: <1399971356.58.0.481655415635.issue19775@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 10:59:10 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 08:59:10 +0000 Subject: [issue21491] race condition in SocketServer.py ForkingMixIn collect_children In-Reply-To: <1399970954.74.0.599178198558.issue21491@psf.upfronthosting.co.za> Message-ID: <1399971550.98.0.914218528957.issue21491@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:04:13 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 13 May 2014 09:04:13 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399971853.52.0.130318213066.issue21470@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: neologix: According to man rand(3ssl), OpenSSL uses an internal state of 1023 bytes for the RNG. You only see it reading 32 bytes from /dev/urandom in the strace because it has already loaded 1024 bytes from the RNG state file ~/.rng before adding another 32 bytes: open("/home/lemburg/.rnd", O_RDONLY) = 3 read(3, "..."..., 4096) = 1024 read(3, "", 4096) = 0 Generating RSA private key, 512 bit long modulus open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 read(3, "...", 32) = 32 FWIW: I'm with Raymond and Tim on this one. I prefer to have a good seed in an RNG per default, simply because most application don't bother to reseed RNGs every now and then, so having a good start into the day is important :-) ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:04:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 09:04:29 +0000 Subject: [issue21483] Skip os.utime() test on NFS? In-Reply-To: Message-ID: <1399971869.47.0.378036938411.issue21483@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Or we could simply catch the EINVAL failure and then skip the test. I suppose the filesystem doesn't support timestamps > 2**32 ? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:04:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 09:04:38 +0000 Subject: [issue21483] Skip os.utime() test on NFS? In-Reply-To: Message-ID: <1399971878.99.0.627728219851.issue21483@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:06:30 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 09:06:30 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1399971990.68.0.594554717471.issue21470@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is ~/.rnd any kind of serious? It hasn't been modified since two weeks on my system (which is rebooted every day). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:08:05 2014 From: report at bugs.python.org (Jim Minter) Date: Tue, 13 May 2014 09:08:05 +0000 Subject: [issue21492] email.header.decode_header sometimes returns bytes, sometimes str Message-ID: <1399972085.94.0.85314895463.issue21492@psf.upfronthosting.co.za> New submission from Jim Minter: Python 3.3.2 (default, Mar 5 2014, 08:21:05) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import email.header >>> email.header.decode_header("foo") [('foo', None)] >>> email.header.decode_header("foo=?windows-1252?Q?bar?=") [(b'foo', None), (b'bar', 'windows-1252')] I may well be wrong, but I believe it's erroneous that in the second example above, b'foo' is returned instead of the expected 'foo'. ---------- components: Library (Lib) messages: 218419 nosy: jim_minter priority: normal severity: normal status: open title: email.header.decode_header sometimes returns bytes, sometimes str type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:21:04 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 13 May 2014 09:21:04 +0000 Subject: [issue21483] Skip os.utime() test on NFS? In-Reply-To: Message-ID: <1399972864.64.0.611310297008.issue21483@psf.upfronthosting.co.za> Larry Hastings added the comment: Antoine's plan sounds good to me. And, is it true that NFS only supports four-byte timestamps? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:23:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 09:23:35 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1399973015.39.0.914409766492.issue21401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue19656. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:30:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 May 2014 09:30:45 +0000 Subject: [issue17756] test_syntax_error fails when run in the installed location In-Reply-To: <1366111959.84.0.955866306047.issue17756@psf.upfronthosting.co.za> Message-ID: <3gSYfD4NFsz7Ljt@mail.python.org> Roundup Robot added the comment: New changeset 20db5e9086d4 by doko in branch '3.4': - Issue #17756: Fix test_code test when run from the installed location. http://hg.python.org/cpython/rev/20db5e9086d4 New changeset 8885fc2e92b3 by doko in branch 'default': Merge from 3.4: http://hg.python.org/cpython/rev/8885fc2e92b3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:32:39 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 13 May 2014 09:32:39 +0000 Subject: [issue17756] test_syntax_error fails when run in the installed location In-Reply-To: <1366111959.84.0.955866306047.issue17756@psf.upfronthosting.co.za> Message-ID: <1399973559.35.0.28045124487.issue17756@psf.upfronthosting.co.za> Matthias Klose added the comment: not yet closing, to see if there are some stream buffering issues in mock ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:46:00 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 13 May 2014 09:46:00 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399971853.52.0.130318213066.issue21470@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > According to man rand(3ssl), OpenSSL uses an internal state of 1023 bytes for the RNG. > > You only see it reading 32 bytes from /dev/urandom in the strace because it has already loaded 1024 bytes from the RNG state file ~/.rng before adding another 32 bytes: Remove this .rnd file, and you'll see on the next run that it still only reads 32 bytes. Same holds for openssh. I'm not using this as an argument against increasing the seed size - Tim and Raymond convinced me - I'm just curious. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:48:15 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 13 May 2014 09:48:15 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399971990.68.0.594554717471.issue21470@psf.upfronthosting.co.za> Message-ID: <5371EA5A.9080801@egenix.com> Marc-Andre Lemburg added the comment: On 13.05.2014 11:06, Antoine Pitrou wrote: > > Is ~/.rnd any kind of serious? It hasn't been modified since two weeks on my system (which is rebooted every day). The file is apparently only updated if you use one the OpenSSL commands which needs random data. grep for "RAND_write_file" in the apps/ subdir of the OpenSSL distribution. Of course, applications can also use that API, so there may be other situations where it gets updated as well. However, when removing that file, OpenSSL still only reads 32 bytes from /dev/urandom, which suggests that it's either using some other sources of randomness as well (there are some timing tricks being used in the code for this), or (more likely) simply doesn't need more random bytes to start with. So while the file does have some meaning, it's not why I had thought it would be. Here's a more likely explanation: The OpenSSL random number source only works with hash function feedback and random data that gets added to it. It's not an PRNG with provable characteristics. OpenSSL uses SHA-1 for hashing which has a 20 byte digest size, so an initial vector of 32 bytes is a good start (though more are always better ;-)): http://en.wikipedia.org/wiki/Randomness_extractor That said and coming back to the question why 32 bytes are enough for OpenSSL: the OpenSSL RNG is being seeded with a seed from the full range of possible values (160 bits). It's period is a lot smaller than the MT one (19937 bits), which is why fewer random bytes are needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 11:52:15 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 09:52:15 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1399974735.04.0.758144557155.issue21430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For the record, SSLSocket.pending() was added in b59825d9db8f with the commit message "get SSL support to work again". It isn't used anywhere in the stdlib. It isn't used by asyncio, Tornado or Twisted. It isn't necessary to write non-blocking SSL applications, and it can actually lead to misunderstandings as some messages on this issue show. I'd rather deprecate the method than start documentating it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 12:12:40 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 13 May 2014 10:12:40 +0000 Subject: [issue21493] Add test for ntpath.expanduser Message-ID: <1399975960.27.0.370722329224.issue21493@psf.upfronthosting.co.za> New submission from Claudiu.Popa: Hello. This patch adds a test for ntpath.expanduser, which was missing. Also, it increases the test coverage for ntpath.py from 68% to 75%. ---------- components: Tests files: expanduser.patch keywords: patch messages: 218427 nosy: Claudiu.Popa priority: normal severity: normal status: open title: Add test for ntpath.expanduser type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35239/expanduser.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 12:23:20 2014 From: report at bugs.python.org (Rose Ames) Date: Tue, 13 May 2014 10:23:20 +0000 Subject: [issue20977] pyflakes: undefined "ctype" in 2 except blocks in the email module In-Reply-To: <1395226153.72.0.859360673019.issue20977@psf.upfronthosting.co.za> Message-ID: <1399976600.9.0.568019286622.issue20977@psf.upfronthosting.co.za> Rose Ames added the comment: This is my first attempt at contributing to python & I'd really appreciate some feedback :). Should I have added a test to demonstrate the bug before trying to fix it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 12:25:02 2014 From: report at bugs.python.org (Feliks) Date: Tue, 13 May 2014 10:25:02 +0000 Subject: [issue21484] More clarity needed about difference between "x += e" and "x = x + e" In-Reply-To: <1399913881.84.0.586979222354.issue21484@psf.upfronthosting.co.za> Message-ID: <1399976702.67.0.241531647636.issue21484@psf.upfronthosting.co.za> Feliks added the comment: Well, there is some anecdotal evidence. ;-) I happen to have a lot of experience with a lot of programming languages, and I was bitten by this. Let's put it like this: it is quite easy to overlook the significance of the sentence in question. One looks at the paragraph, reads the stuff about evaluation, thinks "of course" and moves on. If the sentence were in a new paragraph, and instead of with "Also" began with something like "More importantly", then it might have drawn more attention. After all, the drastic semantic difference between the two forms is quite unlike what one is used to from programming in, say, C. I think it would be helpful if it were stressed a little bit more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 12:45:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 10:45:17 +0000 Subject: [issue19656] Add Py3k warning for non-ascii bytes literals In-Reply-To: <1384884587.46.0.636196916046.issue19656@psf.upfronthosting.co.za> Message-ID: <1399977917.42.0.82720182995.issue19656@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 12:47:46 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 13 May 2014 10:47:46 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1399978066.64.0.692842554127.issue21488@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +patch nosy: +berker.peksag, ncoghlan stage: -> patch review type: resource usage -> behavior versions: +Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35240/issue21488.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 12:49:11 2014 From: report at bugs.python.org (Alexey Gorshkov) Date: Tue, 13 May 2014 10:49:11 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1399978151.14.0.0324160818786.issue21430@psf.upfronthosting.co.za> Alexey Gorshkov added the comment: Ok. As https://docs.python.org/dev/library/ssl.html#notes-on-non-blocking-sockets says: "Calling select() tells you that the OS-level socket can be read from (or written to)", and here is situation: len(select([ssl_socket],[],[], 0.2)[0]) returns 0, but ssl layer has pending data and "SSLWantWriteError or SSLWantReadError instead of BlockingIOError" are not raised, because there is no error.. How should app know what it's need to do another recv() call? Are You suggesting to make loop like this (as for non-blocking socket)? while True: ssl_socket.recv(4096) if something: break what I think is: pending() method - is fine solution for knowing needed information about ssl layer status. SSL_pending(3) is not deprecated in OpenSSL, and I do not see reason why it should be deprecated in python. I do not think it should be deprecated only because it is not used. And it is not need to tell about asyncio, Tornado or Twisted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 12:50:20 2014 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 13 May 2014 10:50:20 +0000 Subject: [issue21483] Skip os.utime() test on NFS? In-Reply-To: <1399971869.47.0.378036938411.issue21483@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: > Or we could simply catch the EINVAL failure and then skip the test. > I suppose the filesystem doesn't support timestamps > 2**32 ? Just in that one test? If I passed -1 that would probably also generate EINVAL (haven't tested). I'll have to check with the admins to see if this particular filesystem is NFS3 or NFS4. I'm guessing 2**32 might be the max for the former. The latter causes us all sorts of other heartburn though, so even though it might be "more modern" in this regard, we don't use it much. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 12:58:04 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 10:58:04 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1399978684.99.0.12215301056.issue21430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Alexey, to quote your own link, here is the proper way: http://www.perlmonks.org/?node_id=845640 > And it is not need to tell about asyncio, Tornado or Twisted. Of course it is :-) It is generally far better to use an existing non-blocking I/O framework, than grow your own event loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 12:59:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 10:59:26 +0000 Subject: [issue20565] Update Tcl/Tk version for buildbots In-Reply-To: <1391883994.31.0.277087136027.issue20565@psf.upfronthosting.co.za> Message-ID: <1399978766.65.0.31988550572.issue20565@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Zachary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:00:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 11:00:23 +0000 Subject: [issue20560] tkFileFilter.c: ostypeCount not initialized? In-Reply-To: <1391854471.94.0.0196154123534.issue20560@psf.upfronthosting.co.za> Message-ID: <1399978823.18.0.442488036984.issue20560@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:14:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 11:14:33 +0000 Subject: [issue4913] wave.py: add writesamples() and readsamples() In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za> Message-ID: <1399979673.38.0.358532155329.issue4913@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I hope all mentioned bugs were already fixed in the wave module. As for new writesamples() and readsamples() methods, perhaps it would be better to add utility functions in the audioop module for packing/unpacking integers. In any case a user can use array.array. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:23:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 11:23:09 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1399980189.41.0.276680139446.issue19385@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Claudiu, your benchmark is broken, it measure a no-op. Correct benchmark: $ ./python -S -m timeit -n 100000 -s "import dbm.dumb as dbm; d=dbm.open('x.dat', 'c')" "len(d)" 3.4: 100000 loops, best of 3: 2.56 usec per loop 3.5: 100000 loops, best of 3: 4.17 usec per loop There is 60% regression. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:32:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 11:32:08 +0000 Subject: [issue18615] sndhdr.whathdr could return a namedtuple In-Reply-To: <1375370275.79.0.808837089288.issue18615@psf.upfronthosting.co.za> Message-ID: <1399980728.16.0.960734796333.issue18615@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Personally I doubt it is a good idea to convert any tuple to named tuple. There are downsides: this increases memory usage and decreases performance; this changes pickled data and makes it backward incompatible (and even worse with other serialization methods). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:32:45 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 13 May 2014 11:32:45 +0000 Subject: [issue21308] PEP 466: backport ssl changes In-Reply-To: <9f606957-c0fc-42fe-b0e1-52ea1cb44333@email.android.com> Message-ID: <1399980765.19.0.96078625558.issue21308@psf.upfronthosting.co.za> Alex Gaynor added the comment: I have not started on this patch yet, I'd wanted to get the other, smaller, backports done first. Unless someone else is planning on getting to this, I think 2.7.8 is more realistic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:34:40 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 13 May 2014 11:34:40 +0000 Subject: [issue21308] PEP 466: backport ssl changes In-Reply-To: <9f606957-c0fc-42fe-b0e1-52ea1cb44333@email.android.com> Message-ID: <1399980880.25.0.21089563342.issue21308@psf.upfronthosting.co.za> Donald Stufft added the comment: I agree that 2.7.8 is more realistic. This particular backport is going to be the most work due to the scope of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:38:46 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 13 May 2014 11:38:46 +0000 Subject: [issue18615] sndhdr.whathdr could return a namedtuple In-Reply-To: <1375370275.79.0.808837089288.issue18615@psf.upfronthosting.co.za> Message-ID: <1399981126.58.0.828255275184.issue18615@psf.upfronthosting.co.za> Claudiu.Popa added the comment: But it improves the API. It's much nicer to actually access the values returned by sndhdr as f.type, f.sampling_rate, f.channels than f[0], f[1], f[2]. You do have a point though. Would it be more acceptable if we'll provide a new function which returns a namedtuple and leaving `whathdr` and `what` in peace? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:39:25 2014 From: report at bugs.python.org (Jim Jewett) Date: Tue, 13 May 2014 11:39:25 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1399980189.41.0.276680139446.issue19385@psf.upfronthosting.co.za> Message-ID: Jim Jewett added the comment: Did you try 3.5 without the patch, in case the issue is not with his code? On May 13, 2014 7:23 AM, "Serhiy Storchaka" wrote: > > Serhiy Storchaka added the comment: > > Claudiu, your benchmark is broken, it measure a no-op. > > Correct benchmark: > > $ ./python -S -m timeit -n 100000 -s "import dbm.dumb as dbm; > d=dbm.open('x.dat', 'c')" "len(d)" > > 3.4: 100000 loops, best of 3: 2.56 usec per loop > 3.5: 100000 loops, best of 3: 4.17 usec per loop > > There is 60% regression. > > ---------- > status: closed -> open > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:42:39 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 13 May 2014 11:42:39 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1399981359.87.0.906212525771.issue19385@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Right, my benchmark was indeed flawed. Here are the new results on my machine: Without the patch # ./python -S -m timeit -n 100000 -s "import dbm.dumb as dbm; d=dbm.open('x.dat', 'c')" "len(d)" 100000 loops, best of 3: 0.564 usec per loop With the patch # ./python -S -m timeit -n 100000 -s "import dbm.dumb as dbm; d=dbm.open('x.dat', 'c')" "len(d)" 100000 loops, best of 3: 0.857 usec per loop Even having an empty _verify_open in __len__ method leads to this: # ./python -S -m timeit -n 100000 -s "import dbm.dumb as dbm; d=dbm.open('x.dat', 'c')" "len(d)" 100000 loops, best of 3: 0.749 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 13:44:48 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 13 May 2014 11:44:48 +0000 Subject: [issue21492] email.header.decode_header sometimes returns bytes, sometimes str In-Reply-To: <1399972085.94.0.85314895463.issue21492@psf.upfronthosting.co.za> Message-ID: <1399981488.92.0.493193998865.issue21492@psf.upfronthosting.co.za> Berker Peksag added the comment: > >>> email.header.decode_header("foo") > [('foo', None)] email.header.decode_header() implements rfc-2047 and the "foo" header doesn't match the syntax described in rfc-2047 (see "2. Syntax of encoded-words"). See the code for more information: * http://hg.python.org/cpython/file/default/Lib/email/header.py#l34 * http://hg.python.org/cpython/file/default/Lib/email/header.py#l81 See the "6.1. Recognition of 'encoded-word's in message headers" section at http://www.rfc-base.org/txt/rfc-2047.txt ---------- components: +email nosy: +barry, berker.peksag, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 14:04:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 12:04:15 +0000 Subject: [issue20544] Use specific asserts in operator tests In-Reply-To: <1391804710.79.0.27308793582.issue20544@psf.upfronthosting.co.za> Message-ID: <1399982655.45.0.328889498712.issue20544@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I had stopped committing patches for similar issues because there is an opposition against this. See discussion at http://comments.gmane.org/gmane.comp.python.devel/145535. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 14:10:23 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 13 May 2014 12:10:23 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1399983023.53.0.353914735029.issue19385@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Here's a new patch which uses the EAFP approach for dunder methods (__len__, __contains__ etc) and the _verify_open method for the other methods (.keys, .iterkeys) etc. Now the results are similar with the benchmark without the patch. ---------- Added file: http://bugs.python.org/file35241/issue19385_speed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 14:12:18 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 12:12:18 +0000 Subject: [issue20544] Use specific asserts in operator tests In-Reply-To: <1391804710.79.0.27308793582.issue20544@psf.upfronthosting.co.za> Message-ID: <1399983138.3.0.189160574152.issue20544@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think these transformations are useful, because on failure they will give you what is the actual value of the compared operands (something which assertTrue is enable to extract). Also they are clearer to read IMO. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 14:23:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 12:23:58 +0000 Subject: [issue20544] Use specific asserts in operator tests In-Reply-To: <1391804710.79.0.27308793582.issue20544@psf.upfronthosting.co.za> Message-ID: <1399983838.24.0.630106746255.issue20544@psf.upfronthosting.co.za> STINNER Victor added the comment: I agree with Antoine. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 14:41:29 2014 From: report at bugs.python.org (Priya pawar) Date: Tue, 13 May 2014 12:41:29 +0000 Subject: [issue21494] getopt error doesnot display correct error Message-ID: <1399984889.06.0.295770888533.issue21494@psf.upfronthosting.co.za> New submission from Priya pawar: i created command from getopt but it gives error if i give single hyphan in long option it should check long option not in small option. eg. hello -foo -o option is not recognized hello --foo is working fine. ---------- messages: 218447 nosy: priya priority: normal severity: normal status: open title: getopt error doesnot display correct error type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:06:28 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 13 May 2014 13:06:28 +0000 Subject: [issue20977] pyflakes: undefined "ctype" in 2 except blocks in the email module In-Reply-To: <1395226153.72.0.859360673019.issue20977@psf.upfronthosting.co.za> Message-ID: <1399986388.92.0.535011506512.issue20977@psf.upfronthosting.co.za> R. David Murray added the comment: It doesn't really matter what order you do it in (though I prefer to write tests first, usually), but yes, we will want tests before we commit the fix. I tried to be thorough in my testing, but obviously I missed some branches :(. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:10:11 2014 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 13 May 2014 13:10:11 +0000 Subject: [issue21494] getopt error doesnot display correct error In-Reply-To: <1399984889.06.0.295770888533.issue21494@psf.upfronthosting.co.za> Message-ID: <1399986611.76.0.475918994298.issue21494@psf.upfronthosting.co.za> Eric V. Smith added the comment: That's working as designed. It allows you to say "-fo" if both 'f' and 'o' are short options. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:11:38 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 13 May 2014 13:11:38 +0000 Subject: [issue21492] email.header.decode_header sometimes returns bytes, sometimes str In-Reply-To: <1399972085.94.0.85314895463.issue21492@psf.upfronthosting.co.za> Message-ID: <1399986698.04.0.202555297311.issue21492@psf.upfronthosting.co.za> R. David Murray added the comment: The error is actually the first case returning string rather than bytes. See issue 6302. ---------- dependencies: +Add decode_header_as_string method to email.utils resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:15:12 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 13 May 2014 13:15:12 +0000 Subject: [issue21492] email.header.decode_header sometimes returns bytes, sometimes str In-Reply-To: <1399972085.94.0.85314895463.issue21492@psf.upfronthosting.co.za> Message-ID: <1399986912.26.0.177811334665.issue21492@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. It looks like we decided that we couldn't fix the behavior for backward compatibility reasons. In 3.4 you can use the new email policies to get automatic, correct stringification of headers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:25:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 13:25:27 +0000 Subject: [issue20977] pyflakes: undefined "ctype" in 2 except blocks in the email module In-Reply-To: <1395226153.72.0.859360673019.issue20977@psf.upfronthosting.co.za> Message-ID: <1399987527.16.0.363974530479.issue20977@psf.upfronthosting.co.za> STINNER Victor added the comment: I would prefer to see the patch applied if no test can be written. The bug was not notified before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:32:56 2014 From: report at bugs.python.org (Thomas Guettler) Date: Tue, 13 May 2014 13:32:56 +0000 Subject: [issue21495] Sane default for logging config Message-ID: <1399987976.18.0.00182198684039.issue21495@psf.upfronthosting.co.za> New submission from Thomas Guettler: Imagine you write a small console script which is implemented like a library. This tool has to do two things: the console script needs to configure the logging, and the library needs to use it. The library usage of logging it easy well documented: {{{ logger=logging.getLogger(__name__) }}} But the part in the console script has no sane default in the python world. I know how to set up the logging config with BasicConfig, DictConfig, ... There needs to be something like DefaultConfig() which reads its config from well known places. This bug report is not about clever code solutions. It is about a sane and easy default agreement on how to load the logging configuration. ---------- messages: 218453 nosy: guettli priority: normal severity: normal status: open title: Sane default for logging config _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:37:28 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 13 May 2014 13:37:28 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1399988248.31.0.1401390849.issue21304@psf.upfronthosting.co.za> Alex Gaynor added the comment: New patch includes the documentation as well. ---------- keywords: +needs review Added file: http://bugs.python.org/file35242/pbkdf2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:52:50 2014 From: report at bugs.python.org (couplewavylines) Date: Tue, 13 May 2014 13:52:50 +0000 Subject: [issue21496] pyvenv activate_this.py Message-ID: <1399989170.01.0.911856918297.issue21496@psf.upfronthosting.co.za> New submission from couplewavylines: Is there any plan to add an 'activate_this.py' to venv? The virtualenv package includes this script. Its purpose is to activate the environment "in-place," from other Python code. One use-case is running multiple WSGI apps that each need a different virtual environment: https://www.pythonanywhere.com/wiki/VirtualEnvForNewerDjango ---------- components: Library (Lib) messages: 218455 nosy: couplewavylines priority: normal severity: normal status: open title: pyvenv activate_this.py type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:54:47 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 13 May 2014 13:54:47 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1399989287.36.0.958615956312.issue21304@psf.upfronthosting.co.za> Donald Stufft added the comment: The attached patch looks pretty good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:55:15 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 13 May 2014 13:55:15 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1399989315.68.0.840881026886.issue21304@psf.upfronthosting.co.za> Alex Gaynor added the comment: I'm still concerned about the unicode issue, but I'm not sure what the right way to fix it is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:56:19 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 13 May 2014 13:56:19 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1399989379.5.0.884072331646.issue21304@psf.upfronthosting.co.za> Donald Stufft added the comment: I don't think there's any way around it, nor do I think that it actually leaks any meaningful timing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:57:03 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 13 May 2014 13:57:03 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1399989423.13.0.780134377016.issue21304@psf.upfronthosting.co.za> Alex Gaynor added the comment: Sorry, I wasn't concerned from a timing attack perspective here, I was concerned from an "oh my god implicit coercion is terrible" perspective :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 15:57:42 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 13 May 2014 13:57:42 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1399989462.27.0.142850800982.issue21304@psf.upfronthosting.co.za> Donald Stufft added the comment: Oh, gotcha. Yea I agree, but it's Python 2.x that's par for the course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 16:09:29 2014 From: report at bugs.python.org (Florian Bruhin) Date: Tue, 13 May 2014 14:09:29 +0000 Subject: [issue21497] faulthandler should handle sys.stderr being None gracefully Message-ID: <1399990169.45.0.873283104693.issue21497@psf.upfronthosting.co.za> New submission from Florian Bruhin: When faulthandler is used while sys.stderr is None (e.g. when using pythonw.exe), a (IMHO) confusing exception is raised: Traceback (most recent call last): File "test.py", line 7, in faulthandler.enable() AttributeError: 'NoneType' object has no attribute 'fileno' Example script which demonstrates the issue without using pythonw.exe: import faulthandler import sys sys.stderr = None try: faulthandler.enable() except: sys.stderr = sys.__stderr__ raise Looking at the code it seems the file passed gets correctly checked against NULL and Py_None, but stderr (as fallback) then only gets checked against NULL: http://hg.python.org/cpython/file/8885fc2e92b3/Modules/faulthandler.c#l141 ---------- components: Extension Modules messages: 218461 nosy: The Compiler, haypo priority: normal severity: normal status: open title: faulthandler should handle sys.stderr being None gracefully type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 16:13:12 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 13 May 2014 14:13:12 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1399990392.02.0.637264652242.issue21423@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Related: https://groups.google.com/forum/#!topic/dev-python/ytbYwHXKC6o I'm not sure how what is proposed here would be useful for ThreadPoolExecutor but it would definitely be helpful being able to set an initializer for ProcessPoolExecutor because right now it seems it's impossible to cleanly shutdown the executor, see: http://noswap.com/blog/python-multiprocessing-keyboardinterrupt ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 16:47:29 2014 From: report at bugs.python.org (Florian Bruhin) Date: Tue, 13 May 2014 14:47:29 +0000 Subject: [issue21498] configparser accepts keys beginning with comment_chars when writing Message-ID: <1399992449.17.0.699994077825.issue21498@psf.upfronthosting.co.za> New submission from Florian Bruhin: When adding something to a configparser instance which has a key beginning with a comment char, it writes the data to a file without generating an error, and when reading the file back obviously the data is different as it's a comment: >>> cp = configparser.ConfigParser() >>> cp.read_dict({'DEFAULT': {';foo': 'bar'}}) >>> cp.write(sys.stdout) [DEFAULT] ;foo = bar This was discussed on python-dev here: https://mail.python.org/pipermail/python-dev/2014-April/134293.html Of course there are other corner cases as well, like having a key like "[foo]" or "=bar". I think whatever data I pass into a configparser should also come out again when reading the file back. Since there's no escaping in configparser, I think the ideal solution would be configparser refusing to write ambigious values. While this is technically a backwards-incompatible change, applications doing this were broken in the first place, so validation while writing will not break anything. Validating when setting values would be better of course, but this can potentially break applications where configparser is used without actually writing a file. ---------- components: Library (Lib) messages: 218463 nosy: The Compiler, lukasz.langa priority: normal severity: normal status: open title: configparser accepts keys beginning with comment_chars when writing type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 16:48:18 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 13 May 2014 14:48:18 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1399992498.09.0.566499565057.issue21488@psf.upfronthosting.co.za> Brett Cannon added the comment: Berker's patch LGTM, so assigning to him to commit. ---------- assignee: docs at python -> berker.peksag nosy: +brett.cannon stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 17:01:36 2014 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 13 May 2014 15:01:36 +0000 Subject: [issue21494] getopt error doesnot display correct error In-Reply-To: <1399984889.06.0.295770888533.issue21494@psf.upfronthosting.co.za> Message-ID: <1399993296.31.0.384663124035.issue21494@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 17:20:06 2014 From: report at bugs.python.org (couplewavylines) Date: Tue, 13 May 2014 15:20:06 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1399994406.41.0.340134460799.issue9253@psf.upfronthosting.co.za> Changes by couplewavylines : ---------- nosy: +couplewavylines _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 17:32:17 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 13 May 2014 15:32:17 +0000 Subject: [issue21489] Switching from -OO to -O still uses cached bytecode In-Reply-To: <1399938996.28.0.0918365412077.issue21489@psf.upfronthosting.co.za> Message-ID: <1399995137.35.0.648673233464.issue21489@psf.upfronthosting.co.za> Brett Cannon added the comment: It's something that could potentially be changed in the future, but no one has prioritized it enough to worry about it. Typically this opens a pandora's box of wanting to generalize it so it supports custom user optimizations as well and then people lose motivation to push it through to the end. =) ---------- nosy: +brett.cannon resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 17:36:48 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 13 May 2014 15:36:48 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1399995408.23.0.53533645373.issue21401@psf.upfronthosting.co.za> Brett Cannon added the comment: I thought we gave ourselves the wiggle room to change the warnings we emitted for -3 (I unfortunately can't find a reference to something relating to that in the Python 2.7 PEP)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 17:42:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 15:42:25 +0000 Subject: [issue21497] faulthandler should handle sys.stderr being None gracefully In-Reply-To: <1399990169.45.0.873283104693.issue21497@psf.upfronthosting.co.za> Message-ID: <1399995745.07.0.860447913411.issue21497@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached patch modifies faulthandler to raises a RuntimeError("sys.stderr is None") with your use case. Is it what you expected? ---------- keywords: +patch Added file: http://bugs.python.org/file35243/faulthandler.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 17:48:22 2014 From: report at bugs.python.org (Florian Bruhin) Date: Tue, 13 May 2014 15:48:22 +0000 Subject: [issue21497] faulthandler should handle sys.stderr being None gracefully In-Reply-To: <1399990169.45.0.873283104693.issue21497@psf.upfronthosting.co.za> Message-ID: <1399996102.57.0.978332976627.issue21497@psf.upfronthosting.co.za> Florian Bruhin added the comment: I didn't test the patch (I don't have the toolchain set up to do so), but it looks like this is indeed an exception which makes more sense to the developer. When I saw the exception as it is now, I only discovered it's related to stderr being None by finding people having a similiar issue with curses, and with the new exception it'd be clear to me what happened. I personally would prefer failing silently though so the application still runs (if there's no stderr, there just is no fault log), but that's debatable of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 17:51:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 15:51:06 +0000 Subject: [issue21497] faulthandler should handle sys.stderr being None gracefully In-Reply-To: <1399990169.45.0.873283104693.issue21497@psf.upfronthosting.co.za> Message-ID: <1399996266.62.0.494009248977.issue21497@psf.upfronthosting.co.za> STINNER Victor added the comment: > I personally would prefer failing silently though so the application still runs (if there's no stderr, there just is no fault log), but that's debatable of course. Nope, there is no debate: there is the Zen of Python :-) "Errors should never pass silently." What's the purpose of enabling faulthandler if sys.stderr is None? If you don't want faulthandler output, don't enable faulthandler!? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 17:58:22 2014 From: report at bugs.python.org (Florian Bruhin) Date: Tue, 13 May 2014 15:58:22 +0000 Subject: [issue21497] faulthandler should handle sys.stderr being None gracefully In-Reply-To: <1399990169.45.0.873283104693.issue21497@psf.upfronthosting.co.za> Message-ID: <1399996702.84.0.167277942596.issue21497@psf.upfronthosting.co.za> Florian Bruhin added the comment: The thing is the developer is not necessarely the one controlling if sys.stderr is None, sometimes the user is. For example, see https://docs.python.org/3.4/using/windows.html#executing-scripts-without-the-python-launcher - an user might have decided to use pythonw by default. This means there's an unexpected gotcha - if I want my application to still run under Windows when the user has changed the default, I first have to check sys.stderr before enabling faulthandler. At the very least I think this should be documented in the faulthandler documentation. I noticed the issue when starting my application under Windows after using cx_Freeze on it, and as a developer wouldn't have expected (or thought about this) at all. I don't feel like I'm the one to decide this properly though, and I'm uncertain what's the right choice, so what you say is probably right ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 18:09:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 May 2014 16:09:47 +0000 Subject: [issue21497] faulthandler should handle sys.stderr being None gracefully In-Reply-To: <1399990169.45.0.873283104693.issue21497@psf.upfronthosting.co.za> Message-ID: <1399997387.74.0.509266050939.issue21497@psf.upfronthosting.co.za> STINNER Victor added the comment: > This means there's an unexpected gotcha I prefer to see an exception before sys.stderr is None, instead of not seeing the traceback when the application does crash. It is usually a pain to reproduce a crash in the exact same conditions. > if I want my application to still run under Windows when the user has changed the default, I first have to check sys.stderr before enabling faulthandler. Exactly. It's not really specific to Windows, you may also have sys.stderr on UNIX in some cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 18:28:57 2014 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Tue, 13 May 2014 16:28:57 +0000 Subject: [issue21422] int << 0: return the number unmodified In-Reply-To: <1399932350.54.0.0436623283077.issue21422@psf.upfronthosting.co.za> Message-ID: <53724837.90502@email.de> Francisco Mart?n Brugu? added the comment: > > What we want to test is that the return value is of type 'int', which is what Victor's test checks. > Thank you for the explanations! for 2.7.6 type(2 << 62) is and type(2 << 61) is (I suppose it's analogous in a 32 bit machine around type(2 << 30) so I just wanted to test on that limits). Is that still relevant? or is too much detail and we should stop here. Regards, francis ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 18:34:33 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 13 May 2014 16:34:33 +0000 Subject: [issue21329] configparser can't parse MySQL style config In-Reply-To: <1398180453.28.0.0252275500481.issue21329@psf.upfronthosting.co.za> Message-ID: <1399998873.23.0.999924433204.issue21329@psf.upfronthosting.co.za> R. David Murray added the comment: The data structure you are asking for bears a resemblance to the data structure used by the email package to record message headers. Email uses a list with a dict-like API cobbled together on top. The difference with your suggestion is that email also needs to record the order of the headers, so just having a list-of-values for each key isn't adequate. Any bets on whether or not we eventually run across a use of .ini format where the exact order of the duplicated keys within the whole list of keys matters? :) With two use cases that could be served by the same data structure in the stdlib, I wonder if it is worth actually building the abstract data type. Probably not, but I thought I'd raise the possibility anyway :) ---------- nosy: +r.david.murray type: -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 19:40:54 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 13 May 2014 17:40:54 +0000 Subject: [issue19656] Add Py3k warning for non-ascii bytes literals In-Reply-To: <1384884587.46.0.636196916046.issue19656@psf.upfronthosting.co.za> Message-ID: <1400002854.63.0.120515512234.issue19656@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 20:13:54 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 13 May 2014 18:13:54 +0000 Subject: [issue21499] test_importlib incorrectly relies on .__builtins__ Message-ID: <1400004834.04.0.700423021102.issue21499@psf.upfronthosting.co.za> New submission from Eric Snow: Per the docs*, a module's __builtins__ may be a module or a dict or even missing. However, test.test_importlib.test_api.ReloadTests checks __builtins__ as part of several tests. Instead, the tests should ignore __bulitins__. I'll push a patch in a minute that fixes that. * https://docs.python.org/3/library/builtins.html ---------- assignee: eric.snow components: Tests messages: 218474 nosy: brett.cannon, eric.snow priority: normal severity: normal stage: needs patch status: open title: test_importlib incorrectly relies on .__builtins__ type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 20:19:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 May 2014 18:19:47 +0000 Subject: [issue21499] test_importlib incorrectly relies on .__builtins__ In-Reply-To: <1400004834.04.0.700423021102.issue21499@psf.upfronthosting.co.za> Message-ID: <3gSnNf50bsz7Ljj@mail.python.org> Roundup Robot added the comment: New changeset 16d26391ec36 by Eric Snow in branch '3.4': Issue #21499: Ignore __builtins__ in several test_importlib.test_api tests. http://hg.python.org/cpython/rev/16d26391ec36 New changeset bdf94b2c0639 by Eric Snow in branch 'default': Merge from 3.4 (for #21499). http://hg.python.org/cpython/rev/bdf94b2c0639 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 20:20:25 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 13 May 2014 18:20:25 +0000 Subject: [issue21499] test_importlib incorrectly relies on .__builtins__ In-Reply-To: <1400004834.04.0.700423021102.issue21499@psf.upfronthosting.co.za> Message-ID: <1400005225.23.0.714525700739.issue21499@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 20:55:58 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 13 May 2014 18:55:58 +0000 Subject: [issue21500] Make use of the "load_tests" protocol in test_importlib packages Message-ID: <1400007358.12.0.940641548905.issue21500@psf.upfronthosting.co.za> New submission from Eric Snow: Right now to run importlib tests you can do either of the following: ./python -m tests test_importlib ./python -m tests.test_importlib Both make use of the regrtest infrastructure. For test submodules the commands are similar: ./python -m tests test_importlib.test_api ./python -m tests.test_importlib.test_api You can also use unittest directly when testing specific test modules: ./python -m unittest tests.test_importlib.test_api ./python -m unittest tests.test_importlib.test_api.Source_ReloadTests.test_reload_location_changed However, currently you cannot use unittest directly with a test package: ./python -m unittest tests.test_importlib ./python -m unittest tests.test_importlib.source It would be nice to be able to do so, rather than switching back and forth between the unittest CLI and the regrtest CLI. The change to do so is relatively straight-forward using the "load_tests" protocol*. Just add the following to the __init__.py of the test packages: def load_tests(loader, tests, pattern): from test import TEST_HOME_DIR as topdir startdir = os.path.dirname(__name__) pkgtests = loader.discover(startdir, pattern or 'test*.py', topdir) tests.addTests(pkgtests) return tests The boilerplate could even be moved to tests.support as a factory function: def make_load_tests(modfilename): from test import TEST_HOME_DIR as topdir startdir = os.path.dirname(modfilename) def load_tests(loader, tests, pattern): pkgtests = loader.discover(startdir, pattern or 'test*.py', topdir) tests.addTests(pkgtests) return tests return load_tests In the test package __init__.py: load_tests = support.make_load_tests(__name__) Then using unittest directly with an importlib test package will work as expected. This is also something that could readily apply to any other test packages in the suite, which is why the factory function in test.support makes sense. * https://docs.python.org/2/library/unittest.html#load-tests-protocol ---------- components: Tests messages: 218476 nosy: brett.cannon, eric.snow priority: low severity: normal stage: needs patch status: open title: Make use of the "load_tests" protocol in test_importlib packages type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 21:00:59 2014 From: report at bugs.python.org (Tim Peters) Date: Tue, 13 May 2014 19:00:59 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1400007659.52.0.524110354452.issue21470@psf.upfronthosting.co.za> Tim Peters added the comment: Crytpo generators are a whole different world, and I wouldn't listen to anyone save a bona fide expert in that field. Plausible: the "hardest thing" OpenSSL has to do is generate secure RSA keys. But the bit length of an RSA key can't be taken at face value: the true strength of such a key is measured by the number of operations required to break it. According to (among many others): http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths "NIST key management guidelines further suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys". So 32 bytes = 256 bits of entropy is sufficient to generate secure 15360-bit RSA keys, which is larger than virtually anyone actually uses (so far), provided everything else is done exactly right. For that reason, "bug reports" about OpenSSL using only 32 bytes seem to get brushed off, like: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742145 So what does that have to do with Python's random()? Nothing ;-) A more fruitful tack would be to investigate switching away from the Mersenne Twister. It was groundbreaking at the time, but nothing lasts forever. Even Wikipedia can come up with a list of its disadvantages now, including "the state space is too large and uselessly stresses the CPU cache": http://en.wikipedia.org/wiki/Mersenne_twister#Disadvantages Worse (according to me), when it reaches a point where "most of" the bits in its state are zeroes, it can take a long time (many calls) before its outputs pass randomness tests again - a paucity of 1 bits tends to persist "way too long". More recent algorithms claim to address these flaws, with smaller state and similar speed. But they're marginal improvements, and don't seem to be gaining traction quickly. The Twister was a huge improvement at the time, and caught on very quickly. In the meantime, better safe than sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 21:18:53 2014 From: report at bugs.python.org (Steve Foley) Date: Tue, 13 May 2014 19:18:53 +0000 Subject: [issue21501] submitting mmap example for use in documentation Message-ID: <1400008733.4.0.146542624997.issue21501@psf.upfronthosting.co.za> New submission from Steve Foley: Hello, I would like to submit an example for the mmap docs page. It demonstrates the use of shared memory and message passing between processes. Thanks! -------------------- import mmap, os, select NUM_CHILDREN = 30 MSG_LEN = 8 BUF_LEN = NUM_CHILDREN * MSG_LEN buf = mmap.mmap(-1, BUF_LEN) p = select.poll() def write_buffer(i): msg = '%s\t%d\n' % (i, os.getpid()) offset = MSG_LEN * i buf.seek(offset) buf.write(msg) def child(i, pipeout): write_buffer(i) os.write(pipeout, 'OK\0'.encode()) os._exit(0) def fork(i, p): pipein, pipeout = os.pipe() if os.fork() == 0: child(i, pipeout) else: p.register(pipein) def loop(msgs, p): while msgs: for fd, event in p.poll(): p.unregister(fd) msgs = msgs - 1 for i in range(NUM_CHILDREN): fork(i, p) loop(NUM_CHILDREN, p) buf.seek(0) print buf.read(BUF_LEN) ---------- assignee: docs at python components: Documentation messages: 218478 nosy: docs at python, hudson priority: normal severity: normal status: open title: submitting mmap example for use in documentation type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 21:25:57 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 13 May 2014 19:25:57 +0000 Subject: [issue2052] Allow changing difflib._file_template character encoding. In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za> Message-ID: <1400009157.38.0.820994802318.issue2052@psf.upfronthosting.co.za> Berker Peksag added the comment: Attaching two patches: issue2052.diff adds a "charset" keyword argument to HtmlDiff.make_file(). issue2052_html5.diff also adds a "charset" keyword argument to HtmlDiff.make_file() and updates the markup of HtmlDiff() to HTML5. I tested it with Firefox 29 and Chrome 34. ---------- keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.5 -Python 3.2 Added file: http://bugs.python.org/file35244/issue2052.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 21:26:11 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 13 May 2014 19:26:11 +0000 Subject: [issue2052] Allow changing difflib._file_template character encoding. In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za> Message-ID: <1400009171.74.0.896726663892.issue2052@psf.upfronthosting.co.za> Changes by Berker Peksag : Added file: http://bugs.python.org/file35245/issue2052_html5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 21:41:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 19:41:04 +0000 Subject: [issue21057] TextIOWrapper does not support reading bytearrays or memoryviews In-Reply-To: <1395720869.89.0.455515257207.issue21057@psf.upfronthosting.co.za> Message-ID: <1400010064.19.0.571593532042.issue21057@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that this is not work with the punycode encoding (and may be some third-party encodings). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 22:03:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 May 2014 20:03:00 +0000 Subject: [issue21486] optimize v4 & v6 netmask parsing In-Reply-To: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> Message-ID: <1400011380.48.0.915593563844.issue21486@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why not just use functools.lru_cache? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 22:04:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 May 2014 20:04:50 +0000 Subject: [issue21486] optimize v4 & v6 netmask parsing In-Reply-To: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> Message-ID: <1400011490.04.0.0552151648071.issue21486@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Because that would incur the cost of LRU logic and locking, which we don't need here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 22:13:23 2014 From: report at bugs.python.org (Steve Foley) Date: Tue, 13 May 2014 20:13:23 +0000 Subject: [issue21501] submitting mmap example for use in documentation In-Reply-To: <1400008733.4.0.146542624997.issue21501@psf.upfronthosting.co.za> Message-ID: <1400012003.54.0.605655314952.issue21501@psf.upfronthosting.co.za> Steve Foley added the comment: sorry! this is the correct version ;-) ------------------------------------------- import mmap, os, select NUM_CHILDREN = 30 MSG_LEN = 9 BUF_LEN = NUM_CHILDREN * MSG_LEN buf = mmap.mmap(-1, BUF_LEN) p = select.poll() def write_buffer(i): msg = '%s\t%d\n' % (i, os.getpid()) offset = MSG_LEN * i buf.seek(offset) buf.write(msg) def child(i, pipeout): write_buffer(i) os.write(pipeout, 'OK\0'.encode()) os._exit(0) def fork(i, p): pipein, pipeout = os.pipe() if os.fork() == 0: child(i, pipeout) else: p.register(pipein) def loop(msgs, p): msgs = NUM_CHILDREN while msgs: for fd, event in p.poll(): p.unregister(fd) msgs = msgs - 1 for i in range(NUM_CHILDREN): fork(i, p) loop(NUM_CHILDREN, p) buf.seek(0) print buf.read(BUF_LEN) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 22:32:56 2014 From: report at bugs.python.org (AJNeufeld) Date: Tue, 13 May 2014 20:32:56 +0000 Subject: [issue18877] tkinter askopenfilenames does not work in Windows library folder In-Reply-To: <1377802367.69.0.551472579776.issue18877@psf.upfronthosting.co.za> Message-ID: <1400013176.28.0.478961917792.issue18877@psf.upfronthosting.co.za> AJNeufeld added the comment: I'd like this issue to be reopened. It does not appear resolved. It is different from the wantobjects=False issue. Windows 7 has 'libraries' which are folders containing the contents of more than one folder. For instance, on my computer > Libraries > Documents presents the contents of the following 2 folders simultaneously: C:\Users\aneufeld\Documents C:\Users\Public\Documents If you execute the script listed in the original bug report, press the [File Open] button, press "Libraries" from the left bar, double click "Documents" in the main area, and select one or more *FILES* in the displayed list of files, I get back: ('',) On the other hand, if I press "Computer" on the left bar, and navigate through "C:", "Users", "aneufeld", "My Documents", and select the SAME FILES, I get back: ('C:/Users/aneufeld/Documents/timelog.txt', 'C:/Users/aneufeld/Documents/notes.txt') >From the "> Libraries > Documents" folder, if you navigate into any real folder, the problem goes away. For example, with the folder ATS in My Documents, press the [File Open] button, press "Libraries" from the left bar, double click "Documents" in the main area, double click ATS, and select the two files, I get: ('C:/Users/aneufeld/Documents/ATS/readme.txt', 'C:/Users/aneufeld/Documents/ATS/Changes.txt') The issue is, when the file "Foo.txt" is selected in a Library folder, such as "Documents", the dialog does not know if that file should be: C:/Users/aneufeld/Documents/Foo.txt or C:/Users/Public/Documents/Foo.txt and returns a null string for the filename. ---------- nosy: +AJNeufeld _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 22:40:33 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 13 May 2014 20:40:33 +0000 Subject: [issue21495] Sane default for logging config In-Reply-To: <1399987976.18.0.00182198684039.issue21495@psf.upfronthosting.co.za> Message-ID: <1400013633.11.0.188603852608.issue21495@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 22:41:52 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 13 May 2014 20:41:52 +0000 Subject: [issue21496] pyvenv activate_this.py In-Reply-To: <1399989170.01.0.911856918297.issue21496@psf.upfronthosting.co.za> Message-ID: <1400013712.98.0.959598743231.issue21496@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:07:56 2014 From: report at bugs.python.org (Stephen Paul Chappell) Date: Tue, 13 May 2014 21:07:56 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1400015276.35.0.545291502095.issue21402@psf.upfronthosting.co.za> Stephen Paul Chappell added the comment: It seems that most functions and methods do not bother checking if _default_root exists before trying to access it. However, upon seeing line 366 in ttk (if tkinter._support_default_root:), my recommendation would be to change line 319 to "if tkinter._support_default_root and tkinter._default_root:" to fix the problem. Several similar lines appear in tkinter\__init__.py at locations 1835, 1845, and 2050. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:36:43 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:36:43 +0000 Subject: [issue15871] Online docs: make index search always available. In-Reply-To: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za> Message-ID: <1400017003.53.0.0453119353885.issue15871@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:37:46 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:37:46 +0000 Subject: [issue16108] Include maintainer information in register/upload In-Reply-To: <1349154240.01.0.151032575778.issue16108@psf.upfronthosting.co.za> Message-ID: <1400017066.0.0.726451861229.issue16108@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:39:29 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:39:29 +0000 Subject: [issue20051] PA-RISC buildbot: compiler cannot create executables In-Reply-To: <1387746992.49.0.56287185551.issue20051@psf.upfronthosting.co.za> Message-ID: <1400017169.21.0.385272762999.issue20051@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:42:05 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:42:05 +0000 Subject: [issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc In-Reply-To: <1325078714.64.0.530368798013.issue13669@psf.upfronthosting.co.za> Message-ID: <1400017325.02.0.849084397289.issue13669@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:42:49 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:42:49 +0000 Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za> Message-ID: <1400017369.65.0.71923414553.issue2552@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:43:54 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:43:54 +0000 Subject: [issue13869] CFLAGS="-UNDEBUG" build failure In-Reply-To: <1327536717.01.0.741263593585.issue13869@psf.upfronthosting.co.za> Message-ID: <1400017434.47.0.0428624165586.issue13869@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> wont fix stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:44:58 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:44:58 +0000 Subject: [issue6467] PyOS_Readline: treatment of "1234EOF"; behavior of builtin_raw_input In-Reply-To: <1247399845.7.0.918611986455.issue6467@psf.upfronthosting.co.za> Message-ID: <1400017498.47.0.299031101657.issue6467@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:45:50 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:45:50 +0000 Subject: [issue7836] Add /usr/sfw/lib to OpenSSL search path for Solaris. In-Reply-To: <1265104504.64.0.0631825253097.issue7836@psf.upfronthosting.co.za> Message-ID: <1400017550.89.0.171129505328.issue7836@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:46:36 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:46:36 +0000 Subject: [issue4999] multiprocessing.Queue does not order objects In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za> Message-ID: <1400017596.94.0.380220963002.issue4999@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:47:28 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:47:28 +0000 Subject: [issue12923] test_urllib fails in refleak mode In-Reply-To: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za> Message-ID: <1400017648.44.0.742816076475.issue12923@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:48:06 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:48:06 +0000 Subject: [issue7424] segmentation fault in listextend during install In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za> Message-ID: <1400017686.87.0.781371845749.issue7424@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:48:36 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:48:36 +0000 Subject: [issue6895] locale._parse_localename fails when localename does not contain encoding information In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za> Message-ID: <1400017716.24.0.0634340776355.issue6895@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:49:30 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:49:30 +0000 Subject: [issue14341] sporadic (?) test_urllib2 failures In-Reply-To: <1331943969.2.0.17966534502.issue14341@psf.upfronthosting.co.za> Message-ID: <1400017770.44.0.779903376133.issue14341@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:50:30 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:50:30 +0000 Subject: [issue5619] Pass MS CRT debug flags into subprocesses In-Reply-To: <1238472783.0.0.132667741337.issue5619@psf.upfronthosting.co.za> Message-ID: <1400017830.02.0.852385561186.issue5619@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:51:03 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:51:03 +0000 Subject: [issue15192] test_bufio failures on Win64 buildbot In-Reply-To: <1340715209.45.0.994879492682.issue15192@psf.upfronthosting.co.za> Message-ID: <1400017863.75.0.626759977588.issue15192@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:52:04 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:52:04 +0000 Subject: [issue14142] getlocale(LC_ALL) behavior In-Reply-To: <1330363994.24.0.841585589979.issue14142@psf.upfronthosting.co.za> Message-ID: <1400017924.14.0.151338220736.issue14142@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> out of date stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:52:58 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:52:58 +0000 Subject: [issue14141] 2.7.2 64-bit Windows library has __impt_Py* for several symbols instead of __imp__Py* In-Reply-To: <1330360352.45.0.311661027338.issue14141@psf.upfronthosting.co.za> Message-ID: <1400017978.34.0.0842246248818.issue14141@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:54:32 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:54:32 +0000 Subject: [issue13837] test_shutil fails with symlinks enabled under Windows In-Reply-To: <1327255807.39.0.63998442373.issue13837@psf.upfronthosting.co.za> Message-ID: <1400018072.4.0.929883012989.issue13837@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:55:06 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:55:06 +0000 Subject: [issue15668] PEP 3121, 384 Refactoring applied to random module In-Reply-To: <1345039836.78.0.438193538839.issue15668@psf.upfronthosting.co.za> Message-ID: <1400018106.59.0.455566250396.issue15668@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:56:59 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:56:59 +0000 Subject: [issue16721] configure incorrectly adds -OPT:Olimit=0 for clang In-Reply-To: <1355868497.91.0.141324882263.issue16721@psf.upfronthosting.co.za> Message-ID: <1400018219.64.0.822312742096.issue16721@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:57:39 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:57:39 +0000 Subject: [issue16275] test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler) In-Reply-To: <1350552289.03.0.785225307416.issue16275@psf.upfronthosting.co.za> Message-ID: <1400018259.35.0.649864183284.issue16275@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:58:01 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:58:01 +0000 Subject: [issue15757] ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS. In-Reply-To: <1345584581.07.0.102502771699.issue15757@psf.upfronthosting.co.za> Message-ID: <1400018281.37.0.361713835348.issue15757@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 13 23:59:50 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 21:59:50 +0000 Subject: [issue15963] Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al). In-Reply-To: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za> Message-ID: <1400018390.0.0.82327664169.issue15963@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:00:53 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:00:53 +0000 Subject: [issue19554] Enable all freebsd* host platforms In-Reply-To: <1384172989.4.0.879301350688.issue19554@psf.upfronthosting.co.za> Message-ID: <1400018453.07.0.833939339292.issue19554@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:02:10 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:02:10 +0000 Subject: [issue18859] README.valgrind should mention --with-valgrind In-Reply-To: <1377649189.0.0.381916551624.issue18859@psf.upfronthosting.co.za> Message-ID: <1400018530.07.0.18722513641.issue18859@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:03:29 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:03:29 +0000 Subject: [issue21412] Solaris/Oracle Studio: Fatal Python error: PyThreadState_Get when built --with-pymalloc In-Reply-To: <1398976678.74.0.10327376478.issue21412@psf.upfronthosting.co.za> Message-ID: <1400018609.08.0.169960937973.issue21412@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:06:11 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:06:11 +0000 Subject: [issue21370] segfault from simple traceback.format_exc call In-Reply-To: <1398638273.35.0.105572602615.issue21370@psf.upfronthosting.co.za> Message-ID: <1400018771.73.0.852162241984.issue21370@psf.upfronthosting.co.za> Stefan Krah added the comment: Closing due to lack of response. ---------- resolution: -> works for me stage: -> resolved status: open -> closed type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:07:03 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:07:03 +0000 Subject: [issue4928] Problem with tempfile.NamedTemporaryFile In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za> Message-ID: <1400018823.47.0.376202994365.issue4928@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:11:17 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:11:17 +0000 Subject: [issue1747670] Limiting data copy in xmlrpclib Message-ID: <1400019077.03.0.0463308959231.issue1747670@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:12:23 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:12:23 +0000 Subject: [issue1615158] POSIX capabilities support Message-ID: <1400019143.6.0.115690355161.issue1615158@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:13:11 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:13:11 +0000 Subject: [issue1043134] Add preferred extensions for MIME types Message-ID: <1400019191.69.0.773998071977.issue1043134@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:14:54 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:14:54 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1400019294.05.0.0244980490787.issue15745@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:17:16 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:17:16 +0000 Subject: [issue969718] BASECFLAGS are not passed to module build line Message-ID: <1400019436.56.0.905994018827.issue969718@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:19:17 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:19:17 +0000 Subject: [issue17781] optimize compilation options In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za> Message-ID: <1400019557.7.0.532164645379.issue17781@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:19:51 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:19:51 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1400019591.08.0.796591321736.issue4130@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:20:25 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:20:25 +0000 Subject: [issue12271] panel.h is not found even if it's installed on various flavours of SUSE In-Reply-To: <1307365298.12.0.602165301483.issue12271@psf.upfronthosting.co.za> Message-ID: <1400019625.12.0.118318766922.issue12271@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:21:37 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:21:37 +0000 Subject: [issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler In-Reply-To: <1316173380.25.0.744886006815.issue12991@psf.upfronthosting.co.za> Message-ID: <1400019697.72.0.59366664824.issue12991@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:23:48 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 13 May 2014 22:23:48 +0000 Subject: [issue4999] multiprocessing.Queue does not order objects In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za> Message-ID: <1400019828.93.0.599135078567.issue4999@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:24:58 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:24:58 +0000 Subject: [issue5404] Cross-compiling Python In-Reply-To: <1235984629.04.0.168155698084.issue5404@psf.upfronthosting.co.za> Message-ID: <1400019898.44.0.155300816146.issue5404@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:25:35 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:25:35 +0000 Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za> Message-ID: <1400019935.26.0.046603146632.issue7511@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:30:38 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 13 May 2014 22:30:38 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <1369515651.34.0.291697920686.issue18062@psf.upfronthosting.co.za> Message-ID: <1400020238.67.0.282665494499.issue18062@psf.upfronthosting.co.za> Stefan Krah added the comment: This should be fixed now. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> HAVE_PY_SET_53BIT_PRECISION for m68k type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:38:47 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 13 May 2014 22:38:47 +0000 Subject: [issue21495] Sane default for logging config In-Reply-To: <1399987976.18.0.00182198684039.issue21495@psf.upfronthosting.co.za> Message-ID: <1400020727.94.0.0926617656417.issue21495@psf.upfronthosting.co.za> Vinay Sajip added the comment: Who decides what's sane and what isn't? You seem to be asking for something, but you don't seem to have a concrete proposal. Are there "sane" defaults in other worlds than the Python world? What are they? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:39:44 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 13 May 2014 22:39:44 +0000 Subject: [issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader In-Reply-To: <1396634360.22.0.98257221553.issue21156@psf.upfronthosting.co.za> Message-ID: <1400020784.71.0.399928756348.issue21156@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: test needed -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 00:43:32 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 13 May 2014 22:43:32 +0000 Subject: [issue21496] pyvenv activate_this.py In-Reply-To: <1399989170.01.0.911856918297.issue21496@psf.upfronthosting.co.za> Message-ID: <1400021012.48.0.816950468548.issue21496@psf.upfronthosting.co.za> Vinay Sajip added the comment: You say "from other Python code", but you mean running an external command in a subprocess, right? If you know where that command is (which you would need to in order to invoke activate_this on the appropriate venv) then you could run the command directly from its bin folder in the venv, and it would run with the venv's environment (interpreter, sys.path etc.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 01:06:07 2014 From: report at bugs.python.org (Eric Ongerth) Date: Tue, 13 May 2014 23:06:07 +0000 Subject: [issue19891] Exiting Python REPL prompt with user without home directory throws error in atexit._run_exitfuncs In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za> Message-ID: <1400022367.7.0.243952807978.issue19891@psf.upfronthosting.co.za> Eric Ongerth added the comment: I'm getting the same PermissionError 13: Error in atexit._run_exitfuncs: PermissionError: [Errno 13] Permission denied My case is: I'm running Python 3.4.0 as a non-root user in a docker.io container built on ubuntu 14.04. This user was created during the creation (Dockerfile) of the container. The user has a home directory and that directory appears to have the usual/proper permissions. When I exit the python3 REPL I get this error even if all I did was start python3 from the command line and then immediately exit. So maybe the cause is other, or more subtle, than just a user with no home dir or home dir with unusual perms? ---------- nosy: +Eric.Ongerth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 01:20:07 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 13 May 2014 23:20:07 +0000 Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za> Message-ID: <1400023207.41.0.655220673294.issue21112@psf.upfronthosting.co.za> Berker Peksag added the comment: Is there a chance to get this into 3.4.1? ---------- stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 01:22:47 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 13 May 2014 23:22:47 +0000 Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za> Message-ID: <1400023367.0.0.349185434496.issue21112@psf.upfronthosting.co.za> Ned Deily added the comment: Berker, if you think it should go into 3.4.1, you need to set the priority to "release blocker" to bring it to the attention of the release manager. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 02:11:32 2014 From: report at bugs.python.org (Jiang-Nan Yang) Date: Wed, 14 May 2014 00:11:32 +0000 Subject: [issue21502] freeze.py not working properly on Mac OSX 10.9 Message-ID: <1400026292.27.0.150943565159.issue21502@psf.upfronthosting.co.za> New submission from Jiang-Nan Yang: Command: python3.4 /Library/Frameworks/Python.framework/Versions/3.4/share/doc/python3.4/examples/Tools/freeze/freeze.py okcointrade.py Error: Reporting needed directory %s not found Basically the problem is on lines 235~239: config should be config-3.4m, python%s on two lines should be python%sm After I corrected these errors, the command works, asking me to run make, except a warning about "unknown modules remains". So I run make, another error occurs: gcc-4.2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -c M_difflib.c gcc-4.2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -c M_ftplib.c gcc-4.2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -I/Library/Frameworks/Python.framework/Versions/3.4/include/python3.4m -c M_pydoc.c gcc-4.2 -Wl,-stack_size,1000000 -framework CoreFoundation Python.framework/Versions/3.4/Python config.o frozen.o M___future__.o M___main__.o M__bootlocale.o M__collections_abc.o M__dummy_thread.o M__osx_support.o M__sitebuiltins.o M__strptime.o M__sysconfigdata.o M__threading_local.o M__weakrefset.o M_abc.o M_argparse.o M_ast.o M_base64.o M_bdb.o M_bisect.o M_bz2.o M_calendar.o M_cmd.o M_code.o M_codecs.o M_codeop.o M_collections.o M_contextlib.o M_copy.o M_copyreg.o M_datetime.o M_difflib.o M_dis.o M_distutils.o M_distutils__errors.o M_distutils__log.o M_distutils__spawn.o M_distutils__sysconfig.o M_distutils__text_file.o M_doctest.o M_dummy_threading.o M_email.o M_email___encoded_words.o M_email___header_value_parser.o M_email___parseaddr.o M_email___policybase.o M_email__base64mime.o M_email__charset.o M_email__contentmanager.o M_email__encoders.o M_email__errors.o M_email__feedparser.o M_email__generator.o M_email__header.o M_email__headerregistry.o M_email__iterators.o M_email__message.o M_email__parser.o M_email__policy.o M_email__quoprimime.o M_email__utils.o M_encodings.o M_encodings__aliases.o M_encodings__latin_1.o M_encodings__utf_8.o M_enum.o M_fnmatch.o M_ftplib.o M_functools.o M_genericpath.o M_getopt.o M_getpass.o M_gettext.o M_glob.o M_gzip.o M_hashlib.o M_heapq.o M_html.o M_html__entities.o M_http.o M_http__client.o M_http__cookiejar.o M_http__server.o M_imp.o M_importlib.o M_importlib___bootstrap.o M_importlib__machinery.o M_importlib__util.o M_inspect.o M_io.o M_json.o M_json__decoder.o M_json__encoder.o M_json__scanner.o M_keyword.o M_linecache.o M_locale.o M_logging.o M_lzma.o M_mimetypes.o M_ntpath.o M_nturl2path.o M_opcode.o M_operator.o M_optparse.o M_os.o M_pdb.o M_pkgutil.o M_platform.o M_plistlib.o M_posixpath.o M_pprint.o M_py_compile.o M_pydoc.o M_pydoc_data.o M_pydoc_data__topics.o M_quopri.o M_random.o M_re.o M_reprlib.o M_rlcompleter.o M_selectors.o M_shlex.o M_shutil.o M_site.o M_socket.o M_socketserver.o M_sre_compile.o M_sre_constants.o M_sre_parse.o M_ssl.o M_stat.o M_string.o M_struct.o M_subprocess.o M_sysconfig.o M_tarfile.o M_tempfile.o M_textwrap.o M_threading.o M_token.o M_tokenize.o M_traceback.o M_tty.o M_types.o M_unittest.o M_unittest__case.o M_unittest__loader.o M_unittest__main.o M_unittest__result.o M_unittest__runner.o M_unittest__signals.o M_unittest__suite.o M_unittest__util.o M_urllib.o M_urllib__error.o M_urllib__parse.o M_urllib__request.o M_urllib__response.o M_uu.o M_warnings.o M_weakref.o M_webbrowser.o M_xml.o M_xml__parsers.o M_xml__parsers__expat.o M_zipfile.o /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/config-3.4m/libpython3.4.a -ldl -framework CoreFoundation -o okcointrade clang: error: no such file or directory: 'Python.framework/Versions/3.4/Python' make: *** [okcointrade] Error 1 I guess that 'Python.framework/Versions/3.4/Python' using a relative location might be a problem, so I go into the Makefile, changed PYTHONFRAMEWORKDIR=Python.framework into PYTHONFRAMEWORKDIR=/Library/Frameworks/Python.framework Now the above problem disappeared, but a new appeared: gcc-4.2 -Wl,-stack_size,1000000 -framework CoreFoundation /Library/Frameworks/Python.framework/Versions/3.4/Python config.o frozen.o M___future__.o M___main__.o M__bootlocale.o M__collections_abc.o M__dummy_thread.o M__osx_support.o M__sitebuiltins.o M__strptime.o M__sysconfigdata.o M__threading_local.o M__weakrefset.o M_abc.o M_argparse.o M_ast.o M_base64.o M_bdb.o M_bisect.o M_bz2.o M_calendar.o M_cmd.o M_code.o M_codecs.o M_codeop.o M_collections.o M_contextlib.o M_copy.o M_copyreg.o M_datetime.o M_difflib.o M_dis.o M_distutils.o M_distutils__errors.o M_distutils__log.o M_distutils__spawn.o M_distutils__sysconfig.o M_distutils__text_file.o M_doctest.o M_dummy_threading.o M_email.o M_email___encoded_words.o M_email___header_value_parser.o M_email___parseaddr.o M_email___policybase.o M_email__base64mime.o M_email__charset.o M_email__contentmanager.o M_email__encoders.o M_email__errors.o M_email__feedparser.o M_email__generator.o M_email__header.o M_email__headerregistry.o M_email__iterators.o M_email__message.o M_email__parser.o M_email__policy.o M_email__quoprimime.o M_email__utils.o M_encodings.o M_encodings__aliases.o M_encodings__latin_1.o M_encodings__utf_8.o M_enum.o M_fnmatch.o M_ftplib.o M_functools.o M_genericpath.o M_getopt.o M_getpass.o M_gettext.o M_glob.o M_gzip.o M_hashlib.o M_heapq.o M_html.o M_html__entities.o M_http.o M_http__client.o M_http__cookiejar.o M_http__server.o M_imp.o M_importlib.o M_importlib___bootstrap.o M_importlib__machinery.o M_importlib__util.o M_inspect.o M_io.o M_json.o M_json__decoder.o M_json__encoder.o M_json__scanner.o M_keyword.o M_linecache.o M_locale.o M_logging.o M_lzma.o M_mimetypes.o M_ntpath.o M_nturl2path.o M_opcode.o M_operator.o M_optparse.o M_os.o M_pdb.o M_pkgutil.o M_platform.o M_plistlib.o M_posixpath.o M_pprint.o M_py_compile.o M_pydoc.o M_pydoc_data.o M_pydoc_data__topics.o M_quopri.o M_random.o M_re.o M_reprlib.o M_rlcompleter.o M_selectors.o M_shlex.o M_shutil.o M_site.o M_socket.o M_socketserver.o M_sre_compile.o M_sre_constants.o M_sre_parse.o M_ssl.o M_stat.o M_string.o M_struct.o M_subprocess.o M_sysconfig.o M_tarfile.o M_tempfile.o M_textwrap.o M_threading.o M_token.o M_tokenize.o M_traceback.o M_tty.o M_types.o M_unittest.o M_unittest__case.o M_unittest__loader.o M_unittest__main.o M_unittest__result.o M_unittest__runner.o M_unittest__signals.o M_unittest__suite.o M_unittest__util.o M_urllib.o M_urllib__error.o M_urllib__parse.o M_urllib__request.o M_urllib__response.o M_uu.o M_warnings.o M_weakref.o M_webbrowser.o M_xml.o M_xml__parsers.o M_xml__parsers__expat.o M_zipfile.o /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/config-3.4m/libpython3.4.a -ldl -framework CoreFoundation -o okcointrade Undefined symbols for architecture x86_64: "_PyInit__imp", referenced from: __PyImport_Inittab in config.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [okcointrade] Error 1 Now it is out of my comprehension. What is wrong? How can I get freeze.py to work? I have a program doing very very heavy computation, so I really hope I can compile it into binary so that it could run much faster. Thanks. ---------- assignee: ronaldoussoren components: Macintosh messages: 218493 nosy: ronaldoussoren, yjiangnan priority: normal severity: normal status: open title: freeze.py not working properly on Mac OSX 10.9 type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 02:25:29 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 14 May 2014 00:25:29 +0000 Subject: [issue21503] Use test_both() consistently throughout test_importlib Message-ID: <1400027129.06.0.740257439061.issue21503@psf.upfronthosting.co.za> New submission from Eric Snow: test_importlib.util provides the test_both() function that facilitates testing both the frozen and source versions of importlib. The function helps to keep the tests more maintainable. However, the following test modules are not using test_both(): Lib/test/test_importlib/test_abc.py Lib/test/test_importlib/test_api.py Lib/test/test_importlib/test_locks.py Lib/test/test_importlib/test_spec.py Lib/test/test_importlib/test_windows.py Furthermore, the remaining test modules use test_both() inconsistently. Here is a patch that makes consistent use of test_both() and formats usage in a way that helps with readability. ---------- assignee: eric.snow components: Tests files: use-test_both-consistently.diff keywords: patch messages: 218494 nosy: brett.cannon, eric.snow priority: low severity: normal stage: needs patch status: open title: Use test_both() consistently throughout test_importlib type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35246/use-test_both-consistently.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 02:33:29 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 14 May 2014 00:33:29 +0000 Subject: [issue21057] TextIOWrapper does not support reading bytearrays or memoryviews In-Reply-To: <1400010064.19.0.571593532042.issue21057@psf.upfronthosting.co.za> Message-ID: <5372B9D1.6020401@rath.org> Nikolaus Rath added the comment: On 05/13/2014 12:41 PM, Serhiy Storchaka wrote: > Note that this is not work with the punycode encoding (and may be some third-party encodings). I do not understand. Could you elaborate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 03:04:28 2014 From: report at bugs.python.org (mattip) Date: Wed, 14 May 2014 01:04:28 +0000 Subject: [issue9266] ctypes "ValueError: NULL pointer access" on Win7 x64 In-Reply-To: <1279198550.56.0.12735266712.issue9266@psf.upfronthosting.co.za> Message-ID: <1400029468.22.0.0796593749008.issue9266@psf.upfronthosting.co.za> mattip added the comment: This was fixed with changeset 8fa73a0885c9 in Jan 2011, probably should be closed ---------- nosy: +mattip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 03:15:43 2014 From: report at bugs.python.org (Jiang-Nan Yang) Date: Wed, 14 May 2014 01:15:43 +0000 Subject: [issue21502] freeze.py not working properly on Mac OSX 10.9 In-Reply-To: <1400026292.27.0.150943565159.issue21502@psf.upfronthosting.co.za> Message-ID: <1400030143.61.0.575235499785.issue21502@psf.upfronthosting.co.za> Changes by Jiang-Nan Yang : ---------- nosy: -ronaldoussoren, yjiangnan versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 03:43:13 2014 From: report at bugs.python.org (Josh Cogliati) Date: Wed, 14 May 2014 01:43:13 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1400031793.58.0.413402002434.issue21401@psf.upfronthosting.co.za> Josh Cogliati added the comment: Other than in the source code in Modules/main.c, is -b documented anywhere? (For 2.7.6, The html docs, man page, and --help all failed to mention it) ---------- nosy: +jrincayc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 04:40:46 2014 From: report at bugs.python.org (donald petravick) Date: Wed, 14 May 2014 02:40:46 +0000 Subject: [issue21504] can the subprocess module war using os.wait4 and so return usage? Message-ID: <1400035246.64.0.2270855198.issue21504@psf.upfronthosting.co.za> New submission from donald petravick: hi, we use python for the Dark Energy Survey and use the subprocess module to run a variety of programs, which we do not control. One concern we have is to monitor system information such as whether the code causes swapping. It's be really useful if -- The Pipe object (and similar objectsI in the subprocess module could .... - have waits in unix implemented by os.wait4() for unix, instead of os.waitpid() - have an new data member, rusage, make the resource usage available to the caller. An additional comment is that all of the wait() family of system calls are implemented in terms of wait4, and there is an argument that hiding usage has no effective cost. There is a wait(self,...) method in pipe. it seems a simple change to subprocess.Pipe to call os.wait4 in the unix variant and stash usage in a data member. ---------- components: Library (Lib) messages: 218498 nosy: donald.petravick priority: normal severity: normal status: open title: can the subprocess module war using os.wait4 and so return usage? type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 06:12:09 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 14 May 2014 04:12:09 +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: <1400040729.05.0.502941096749.issue21502@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: ronaldoussoren -> ned.deily nosy: +ned.deily stage: -> needs patch title: freeze.py not working properly on Mac OSX 10.9 -> freeze.py not working properly with OS X framework builds type: compile error -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 06:57:14 2014 From: report at bugs.python.org (Thomas Guettler) Date: Wed, 14 May 2014 04:57:14 +0000 Subject: [issue21495] Sane default for logging config In-Reply-To: <1399987976.18.0.00182198684039.issue21495@psf.upfronthosting.co.za> Message-ID: <1400043434.97.0.670464173446.issue21495@psf.upfronthosting.co.za> Thomas Guettler added the comment: Thank you for reading and replying. Yes, I wrote no concret proposal up to now. I have this solutions in mind: logging.config.defaultConfig() Related https://docs.python.org/2/library/logging.config.html Loading a python module: ------------------------ load a module "loggingconfig" this module gets imported like any other python module. It is like django loads its settings. It could be possible to check the environment variable LOGGINGCONFIG first. It could contain a string which defaults to "loggingconfig". This module has a method "set_up()" which sets up the logging for this environment. Loading from a file: --------------------- A file searched in this places: - CWD/.loggingconfig.conf - VIRTUAL_ENV/.loggingconfig.conf - HOME/.loggingconfig.conf - etc/loggingconfig.conf The file gets loaded with fileConfig() Module or file config loading ----------------------------- I think the module loading is better than the file based solution. That's why I think it should be done first. If there is no module found, the file loading should be tried. If not config found -------------------- If not config was found, default gets set. My proposal: - loglevel is set to INFO. (Debug gets suppressed) - format: '%(asctime)s %(name)s: %(levelname)-8s [%(process)d] %(message)s' - logging goes to stdout --------------------------- What is the best way to get this into the python standard library? Should I create a PEP? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 07:09:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 05:09:43 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <3gT3pZ6Fy9z7LkT@mail.python.org> Roundup Robot added the comment: New changeset 7b5265752942 by Raymond Hettinger in branch '2.7': Issue #21470: Do a better job seeding the random number generator http://hg.python.org/cpython/rev/7b5265752942 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 07:21:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 05:21:35 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <3gT44G5K7Kz7LjP@mail.python.org> Roundup Robot added the comment: New changeset c203df907092 by Raymond Hettinger in branch '3.4': Issue #21470: Do a better job seeding the random number generator http://hg.python.org/cpython/rev/c203df907092 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 07:33:52 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 14 May 2014 05:33:52 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1400045632.41.0.448441822829.issue21470@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 08:01:53 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 14 May 2014 06:01:53 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1400045632.46.0.244582789846.issue21470@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Thanks for the explanations! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 08:08:34 2014 From: report at bugs.python.org (Shivani) Date: Wed, 14 May 2014 06:08:34 +0000 Subject: [issue21505] cx_freeze multiprocessing bug Message-ID: <1400047714.39.0.600066285372.issue21505@psf.upfronthosting.co.za> New submission from Shivani: Hey all, I have problem with multiprocessing and cx_freeze.. I am freezing my UI application. i have a line in code::-> "multiprocessing.set_executable(os.path.join(sys.exec_prefix, 'pythonw.exe'))" when a commented out this line, my UI keeps iterating again and again. and when i uncomment it, without throwing any error,UI just stuck in its second phase. and moreover spoiling my unfreezen code olso. What can be the problem with multi processing and cx_freeze relation..? Thanks in Advance. ---------- components: Tkinter messages: 218503 nosy: shivani priority: normal severity: normal status: open title: cx_freeze multiprocessing bug versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 08:33:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 06:33:22 +0000 Subject: [issue21486] optimize v4 & v6 netmask parsing In-Reply-To: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> Message-ID: <1400049202.91.0.0263885113543.issue21486@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: With C implementation (issue14373) functools.lru_cache is so fast as manually written specialized code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 08:44:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 06:44:40 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1400049880.55.0.00206876943198.issue21402@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not so easy, because it does not work with wantobject=False and can not work with future versions of Tk. Actually we should use self.tk instead of _default_root, but this will change the signature of _list_from_layouttuple() and _val_or_dict(). Due to the risk of breaking existing user code which uses these private functions, they should be left with old signature and new functions should be added. ---------- assignee: -> serhiy.storchaka versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 09:08:18 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 14 May 2014 07:08:18 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1400051298.7.0.699609230803.issue21488@psf.upfronthosting.co.za> Nick Coghlan added the comment: Brett, if you granted Berker commit privileges, you forgot to update the developer log and issue tracker... That said, the patch LGTM too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 09:36:16 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 14 May 2014 07:36:16 +0000 Subject: [issue21031] [patch] Add AlpineLinux to the platform module's supported distributions list In-Reply-To: <1395547536.87.0.0316178193706.issue21031@psf.upfronthosting.co.za> Message-ID: <1400052976.64.0.703836462082.issue21031@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +brett.cannon, ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 09:37:05 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 14 May 2014 07:37:05 +0000 Subject: [issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools In-Reply-To: <1395564519.98.0.0028723182567.issue21034@psf.upfronthosting.co.za> Message-ID: <1400053025.68.0.157448303355.issue21034@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +eric.araujo stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 10:21:45 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 14 May 2014 08:21:45 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1400055705.52.0.634663637941.issue21027@psf.upfronthosting.co.za> Changes by Claudiu.Popa : Added file: http://bugs.python.org/file35247/issue21027_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 10:30:14 2014 From: report at bugs.python.org (mattip) Date: Wed, 14 May 2014 08:30:14 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1400056214.87.0.259070172388.issue20160@psf.upfronthosting.co.za> mattip added the comment: Here is a fix for arguments and return values, based on the support in cffi, for python2.7 I added a test in test_win32, removed the too-early attempt to fix in callproc.c, and merged in most of the changes in lib_msvc from cffi's code base. These changes handle the following (in addition to callproc change): - fix rtype handling by converting a return-by-value struct to a pointer-sized int - fix stack byte-size calculation by checking for large pass-by-value structs, incrementing bytes by sizeof(void*) in this case - fix avalue copying by checking for large pass-by-value structs and copying the pointer not the value - fix bogus check for stack buffer < 40 bytes A similar patch for 3.4 will be posted soon. Other related issues: http://bugs.python.org/issue11835 ---------- keywords: +patch nosy: +mattip Added file: http://bugs.python.org/file35248/issue_20160_python2_7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 10:32:39 2014 From: report at bugs.python.org (mattip) Date: Wed, 14 May 2014 08:32:39 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1400056359.89.0.885613466595.issue20160@psf.upfronthosting.co.za> mattip added the comment: and here is the promised patch for tip ---------- Added file: http://bugs.python.org/file35249/issue_20160_tip.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 10:33:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 08:33:55 +0000 Subject: [issue18492] Allow all resources if not running under regrtest.py In-Reply-To: <1374161900.43.0.881425486921.issue18492@psf.upfronthosting.co.za> Message-ID: <1400056435.66.0.456688106119.issue18492@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You have convinced me. In general the approach and the patch LGTM. But I agree with Terry that flag support.regrtest_run is redundant, it duplicates a bit of information which provides support.use_resources. Instead we can rewrite support.is_resource_enabled() as return use_resources is None or resource in use_resources Introducing regrtest_run can cause inconsistency between it and use_resources. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 11:19:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 09:19:22 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1400059162.84.0.364257555982.issue21488@psf.upfronthosting.co.za> STINNER Victor added the comment: For Python 3.5, I would prefer to patch the code to support keywords instead. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 11:21:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 09:21:57 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1400059317.21.0.421186874444.issue21488@psf.upfronthosting.co.za> STINNER Victor added the comment: I sent a review on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 11:29:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 09:29:13 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1400059753.71.0.267290424743.issue21488@psf.upfronthosting.co.za> STINNER Victor added the comment: codecs_decode_encode_kw.patch: Patch for Python 3.5 adding support of keyword arguments on codecs.encode and codecs.decode. ---------- Added file: http://bugs.python.org/file35250/codecs_decode_encode_kw.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 11:32:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 09:32:29 +0000 Subject: [issue6895] locale._parse_localename fails when localename does not contain encoding information In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za> Message-ID: <1400059949.62.0.507867320393.issue6895@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For now the output of the code in msg132878 on Ubuntu is empty. May be this issue is outdated. ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 11:58:51 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 14 May 2014 09:58:51 +0000 Subject: [issue21495] Sane default for logging config In-Reply-To: <1399987976.18.0.00182198684039.issue21495@psf.upfronthosting.co.za> Message-ID: <1400061531.59.0.783087181942.issue21495@psf.upfronthosting.co.za> Vinay Sajip added the comment: Just on backward compatibility grounds, a proposal like this isn't going to be acceptable on python-dev, I believe, and I'm not even sure it's necessary to have such a thing in the stdlib: why not just use the approach you suggested for your own projects, and leave it at that? I've certainly found that preferences for configuration approaches vary a lot across people, and nothing will please everyone :-( Generally, before writing a PEP, ideas are broached on the python-ideas mailing list, then move to the python-dev mailing list when they seem to have enough mileage to do so, and the PEP discussion / life-cycle happens there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 12:01:12 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 May 2014 10:01:12 +0000 Subject: [issue9266] ctypes "ValueError: NULL pointer access" on Win7 x64 In-Reply-To: <1279198550.56.0.12735266712.issue9266@psf.upfronthosting.co.za> Message-ID: <1400061672.26.0.361430681349.issue9266@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 12:17:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 10:17:17 +0000 Subject: [issue21487] Assorted ipaddress performance improvements In-Reply-To: <1399925063.26.0.615670484521.issue21487@psf.upfronthosting.co.za> Message-ID: <1400062637.65.0.872332297511.issue21487@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Alternative implementations of _count_righthand_zero_bits(): def _count_righthand_zero_bits(number, bits): if not number: return bits return (~number & (number-1)).bit_length() or def _count_righthand_zero_bits(number, bits): if not number: return bits return (~(number | -number)).bit_length() ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 12:47:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 10:47:05 +0000 Subject: [issue21343] os.path.relpath returns inconsistent types In-Reply-To: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za> Message-ID: <1400064425.45.0.898672801949.issue21343@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this is not a bug and shouldn't be fixed in 2.7. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 12:48:52 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 10:48:52 +0000 Subject: [issue21387] Memory leaks when embedded interpreter is reinitialized In-Reply-To: <1398772537.74.0.909134635776.issue21387@psf.upfronthosting.co.za> Message-ID: <1400064532.57.0.62113982914.issue21387@psf.upfronthosting.co.za> Stefan Krah added the comment: I've run Evgeniy's example under Valgrind and changed it to import various C extensions. Unfortunately they all leak more or less, so perhaps we can revisit this when (if?) the PEP 3121 and PEP 384 changes have been implemented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 12:51:31 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 10:51:31 +0000 Subject: [issue16594] SocketServer should set SO_REUSEPORT along with SO_REUSEADDR when present In-Reply-To: <1354439249.45.0.0324812571604.issue16594@psf.upfronthosting.co.za> Message-ID: <1400064691.39.0.836420635024.issue16594@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 12:59:14 2014 From: report at bugs.python.org (Andreas van Cranenburgh) Date: Wed, 14 May 2014 10:59:14 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument In-Reply-To: <1399990392.02.0.637264652242.issue21423@psf.upfronthosting.co.za> Message-ID: <20140514105907.GD9112@unstable.nl> Andreas van Cranenburgh added the comment: Giampaolo, this patch is for ProcessPoolExecutor as well. About keyboard interrupts, if my tests are correct, they work in Python 3.3+ with both multiprocessing and concurrent.futures. (Although for the latter I have to hit ctrl-c twice). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 13:00:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 11:00:50 +0000 Subject: [issue21331] Reversing an encoding with unicode-escape returns a different result In-Reply-To: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za> Message-ID: <1400065250.54.0.152793380918.issue21331@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sworddragon, try to use content.encode('ascii', 'backslashreplace').decode('unicode-escape'). It is too late to change the unicode-escape encoding. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 13:06:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 11:06:00 +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: <1400065560.96.0.94655525429.issue21231@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree that this is not a good idea. Old-style classes are legal in Python 2 and this syntax is legal in Python 3 where it means new-style classes and in most cases there is no difference between new-style and old-style classes. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 13:36:10 2014 From: report at bugs.python.org (Ed Morley) Date: Wed, 14 May 2014 11:36:10 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe Message-ID: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> New submission from Ed Morley: A python.org 2.7.6 release of the Windows MSI installer, results in only the following python binaries in the installation directory: C:\Python27\python.exe C:\Python27\pythonw.exe In Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=957721 we would like to be able to force our 'mach' script to use Python2.7 (due to the assorted Python versions present on our CI machines), however doing so via the script shebang line breaks local developer workflows on Windows, since the default Python install doesn't include python2.7.exe and so the binary isn't found. As such, it would be great if python.exe could be symlinked to pythonX.Y.exe (and also I guess pythonX.exe) as part of the Windows installation/build - giving us parity with Unix based platforms. This can be done on Windows using mklink (http://ss64.com/nt/mklink.html), eg: c:\Python27>mklink python2.7.exe python.exe symbolic link created for python2.7.exe <<===>> python.exe c:\Python27>mklink python2.exe python.exe symbolic link created for python2.exe <<===>> python.exe c:\Python27>dir python* 10/11/2013 19:24 26,624 python.exe 14/05/2014 12:04 python2.exe [python.exe] 14/05/2014 12:04 python2.7.exe [python.exe] 10/11/2013 19:24 27,136 pythonw.exe Alternatively, just a plain copy of the binary prior to creating the MSI would be just as helpful for us too. I searched for a while to see if there were any bugs filed for this already, but the closest I could find was: * http://legacy.python.org/dev/peps/pep-0397/ - which is about a smart launcher that uses the shebang lines to run the correct Python version when multiple are installed (and thus is quite a different request to that in this bug). * and https://mail.python.org/pipermail/python-dev/2011-March/108850.html which suggests the idea as in this bug summary here, but it seems like a bug for it was never filed. Many thanks :-) ---------- components: Build, Installation, Windows messages: 218521 nosy: edmorley, loewis priority: normal severity: normal status: open title: Windows MSI installer should mklink (symlink) python.exe to python2.7.exe type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 13:38:02 2014 From: report at bugs.python.org (Ed Morley) Date: Wed, 14 May 2014 11:38:02 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1400067482.4.0.897270085553.issue21506@psf.upfronthosting.co.za> Ed Morley added the comment: Meant to add: the ActivePython release does this already - but it would be great if upstream did too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 13:45:03 2014 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 14 May 2014 11:45:03 +0000 Subject: [issue4999] multiprocessing.Queue does not order objects In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za> Message-ID: <1400067903.05.0.742062693161.issue4999@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 13:45:43 2014 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 14 May 2014 11:45:43 +0000 Subject: [issue4928] Problem with tempfile.NamedTemporaryFile In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za> Message-ID: <1400067943.99.0.889618832371.issue4928@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 14:04:57 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 14 May 2014 12:04:57 +0000 Subject: [issue21046] Document formulas used in statistics In-Reply-To: <1395630619.14.0.819197288528.issue21046@psf.upfronthosting.co.za> Message-ID: <1400069097.78.0.270776447417.issue21046@psf.upfronthosting.co.za> Ezio Melotti added the comment: > E.g. > median([x1, x2, x3, x4, x5]) = x3 > median([x1, x2, x3, x4, x5, x6]) = (x3 + x4) / 2 The docs seem to already contain similar examples for some of the functions (e.g. median()), but not for others (e.g. mean()). For these, if the formula can be expressed with a simple Python equivalent (e.g. sum(values) / len(values)), I think it would be reasonable to add it. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 14:32:52 2014 From: report at bugs.python.org (Lev Givon) Date: Wed, 14 May 2014 12:32:52 +0000 Subject: [issue21507] memory used by frozenset created from set differs from that of frozenset created from other iterable Message-ID: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> New submission from Lev Givon: Not sure if this is indicative of a bug, but I noticed that a frozenset created from a set seems to occupy a different amount of memory than a frozenset created from some other iterable. I observed this behavior with Python 2.7.5 and with Python 3.4.0 on Ubuntu 14.04 x86_64: >>> from sys import getsizeof >>> x = range(100) >>> s = set(x) >>> f0 = frozenset(x) >>> f1 = frozenset(s) >>> getsizeof(s) 8424 >>> getsizeof(f0) 8424 >>> getsizeof(f1) 4328 >>> f0==f1 True Original question on StackOverflow available at https://stackoverflow.com/questions/23618259/memory-occupied-by-set-vs-frozenset-in-python-2-7 ---------- messages: 218524 nosy: lebedov priority: normal severity: normal status: open title: memory used by frozenset created from set differs from that of frozenset created from other iterable type: resource usage versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 15:04:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 14 May 2014 13:04:09 +0000 Subject: [issue21487] Assorted ipaddress performance improvements In-Reply-To: <1399925063.26.0.615670484521.issue21487@psf.upfronthosting.co.za> Message-ID: <1400072649.09.0.000482726590861.issue21487@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Good point, this is a much faster implementation. Updated patch (and fixed the implementation to not return more than `bits`). ---------- Added file: http://bugs.python.org/file35251/ipaddr_perf2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 15:14:45 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 14 May 2014 13:14:45 +0000 Subject: [issue21507] memory used by frozenset created from set differs from that of frozenset created from other iterable In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400073285.93.0.225154822833.issue21507@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 15:17:14 2014 From: report at bugs.python.org (couplewavylines) Date: Wed, 14 May 2014 13:17:14 +0000 Subject: [issue21496] pyvenv activate_this.py In-Reply-To: <1399989170.01.0.911856918297.issue21496@psf.upfronthosting.co.za> Message-ID: <1400073434.25.0.199920066752.issue21496@psf.upfronthosting.co.za> couplewavylines added the comment: "run the command directly...would run with the venv's environment": I'm sorry I didn't realize this, the "You don?t specifically need to activate an environment..." part of the venv docs didn't sink in for me when I read it earlier. So yes, using a subprocess will do what I'm after. I don't know if the subprocess will cover the situation in that link where they're using execfile on activate_this, but I was just trying to find a common-looking use-case for activate_this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 15:20:45 2014 From: report at bugs.python.org (Stephen Paul Chappell) Date: Wed, 14 May 2014 13:20:45 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1400073645.62.0.0267508221428.issue21402@psf.upfronthosting.co.za> Stephen Paul Chappell added the comment: There is discussion of removing wantobjects in issue3015. If it gets removed, a better patch might be created for future versions of tkinter. However, accessing self.tk would probably be a good replacement for anywhere tkinter._default_root can be found (except in cases where a widget is not given a parent). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 15:28:06 2014 From: report at bugs.python.org (Matt Bachmann) Date: Wed, 14 May 2014 13:28:06 +0000 Subject: [issue21343] os.path.relpath returns inconsistent types In-Reply-To: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za> Message-ID: <1400074086.41.0.522743125204.issue21343@psf.upfronthosting.co.za> Matt Bachmann added the comment: Can you help me understand why not? If I give it two unicode strings it sometimes gives me back a unicode and sometimes gives me back a string. In python3 this does what I expect. In python27 I now have to check the type I get back because I cannot be sure what type I will be getting back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 15:41:36 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 14 May 2014 13:41:36 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1400074896.13.0.5116101392.issue21488@psf.upfronthosting.co.za> Brett Cannon added the comment: Nope, I forgot Berker had triage rights but not commit rights. ---------- assignee: berker.peksag -> docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 15:46:57 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 May 2014 13:46:57 +0000 Subject: [issue21338] Silent mode for compileall In-Reply-To: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za> Message-ID: <1400075217.19.0.617031845459.issue21338@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 15:55:02 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 14 May 2014 13:55:02 +0000 Subject: [issue21496] pyvenv activate_this.py In-Reply-To: <1399989170.01.0.911856918297.issue21496@psf.upfronthosting.co.za> Message-ID: <1400075702.85.0.578800666499.issue21496@psf.upfronthosting.co.za> Vinay Sajip added the comment: Okay, I'll close this issue. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 15:55:57 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 May 2014 13:55:57 +0000 Subject: [issue21342] multiprocessing RLock and Lock raise incorrect exceptions when releasing an unlocked lock. In-Reply-To: <1398319251.34.0.871128764935.issue21342@psf.upfronthosting.co.za> Message-ID: <1400075757.47.0.776562799119.issue21342@psf.upfronthosting.co.za> R. David Murray added the comment: As a historical note, the docs are probably correct...but at some point relatively recently we fixed the inconsistency in what was raised in the thread and threading modules, but obviously no one noticed that multiprocessing had the same issue. It could be that a comment should be added to the thread/threading code mentioning the multiprocessing clones, and vice versa. Or perhaps the code can be unified? I suspect the clones exist primarily because multiprocessing was originally an external project. ---------- nosy: +r.david.murray stage: -> patch review versions: -Python 2.7, Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 16:04:31 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 May 2014 14:04:31 +0000 Subject: [issue21345] multiprocessing.Pool._handle_workers sleeps too long In-Reply-To: <1398355364.53.0.447682013962.issue21345@psf.upfronthosting.co.za> Message-ID: <1400076271.73.0.352692671578.issue21345@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not that familiar with multiprocessing, but I'd guess it was to avoid burning cpu in a busy-wait (it seems to me that that doesn't matter during finalization, but does during normal running). Maybe it could be changed to an event wait on a shutdown event? ---------- nosy: +r.david.murray versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 16:10:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 14:10:37 +0000 Subject: [issue21347] Don't use a list argument together with shell=True in subprocess' docs In-Reply-To: <1398366522.65.0.954174735085.issue21347@psf.upfronthosting.co.za> Message-ID: <3gTHph4lyvz7Lk1@mail.python.org> Roundup Robot added the comment: New changeset 5ef9a2c711f5 by R David Murray in branch '2.7': #21347: use string not list in shell=True example. http://hg.python.org/cpython/rev/5ef9a2c711f5 New changeset 3b27f3acf0c4 by R David Murray in branch '3.4': #21347: use string not list in shell=True example. http://hg.python.org/cpython/rev/3b27f3acf0c4 New changeset 217006c5455f by R David Murray in branch 'default': Merge: #21347: use string not list in shell=True example. http://hg.python.org/cpython/rev/217006c5455f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 16:11:07 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 May 2014 14:11:07 +0000 Subject: [issue21347] Don't use a list argument together with shell=True in subprocess' docs In-Reply-To: <1398366522.65.0.954174735085.issue21347@psf.upfronthosting.co.za> Message-ID: <1400076667.9.0.108522616933.issue21347@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Akira. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 16:28:38 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 14 May 2014 14:28:38 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1400077718.94.0.150786704394.issue21506@psf.upfronthosting.co.za> Zachary Ware added the comment: A similar thought I've had is to add a feature to the PEP397 launcher, allowing it to figure out Python version from a suffix on its executable name and add symlinks to it for each installed version of Python. That way PATH wouldn't need to be modified to make every installed version accessible from a single optionless command. ---------- nosy: +steve.dower, tim.golden, zach.ware versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 16:33:43 2014 From: report at bugs.python.org (Steve) Date: Wed, 14 May 2014 14:33:43 +0000 Subject: [issue21508] C API PyArg_ParseTuple doc is innacurate Message-ID: <1400078023.63.0.359608332224.issue21508@psf.upfronthosting.co.za> New submission from Steve: PyArg_ParseTuple is defined as returning an "int", but the documentation talks about returning a true/false value, and failling on false. In addition to being inaccurate, considering that most other functions fail on !=0 ("true"), it can lead to confusion. Doc: int PyArg_ParseTuple(PyObject *args, const char *format, ...) Parse the parameters of a function that takes only positional parameters into local variables. Returns true on success; on failure, it returns false and raises the appropriate exception. ---------- assignee: docs at python components: Documentation messages: 218536 nosy: Banger, docs at python priority: normal severity: normal status: open title: C API PyArg_ParseTuple doc is innacurate type: enhancement versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 16:40:50 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 14 May 2014 14:40:50 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1400078450.45.0.650840507417.issue21506@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't deal with Python 2.7 anymore, so I have no opinion on this matter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:05:51 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 15:05:51 +0000 Subject: [issue12985] Check signed arithmetic overflow in ./configure In-Reply-To: <1316079277.71.0.960663177072.issue12985@psf.upfronthosting.co.za> Message-ID: <1400079951.24.0.675044799849.issue12985@psf.upfronthosting.co.za> Stefan Krah added the comment: I won't have time to work on this. It would also be an option to do these checks in test_capi. ---------- resolution: -> later stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:09:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 15:09:57 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <3gTK78313Xz7LnZ@mail.python.org> Roundup Robot added the comment: New changeset cc5e3b93c35a by Victor Stinner in branch '2.7': Issue #21488: Fix doc of codecs.decode() and codecs.encode(), no keyword support. http://hg.python.org/cpython/rev/cc5e3b93c35a New changeset 2e116176a81f by Victor Stinner in branch '3.4': Issue #21488: Fix doc of codecs.decode() and codecs.encode(), no keyword support. http://hg.python.org/cpython/rev/2e116176a81f New changeset 889896471498 by Victor Stinner in branch 'default': Merge 3.4: ignore change specific to 3.4 for #21488, I had a different patch for Python 3.5 http://hg.python.org/cpython/rev/889896471498 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:10:33 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 15:10:33 +0000 Subject: [issue16533] HPUX: Unable to fork() in thread In-Reply-To: <1353622712.14.0.676507060266.issue16533@psf.upfronthosting.co.za> Message-ID: <1400080233.97.0.264199258016.issue16533@psf.upfronthosting.co.za> Stefan Krah added the comment: Since this is 2.7 and an exotic system, I'm removing myself from the nosy list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:10:45 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 15:10:45 +0000 Subject: [issue16533] HPUX: Unable to fork() in thread In-Reply-To: <1353622712.14.0.676507060266.issue16533@psf.upfronthosting.co.za> Message-ID: <1400080245.13.0.819687221385.issue16533@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:10:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 15:10:59 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <3gTK8M17fZz7Lk1@mail.python.org> Roundup Robot added the comment: New changeset 6ceedbd88b5f by Victor Stinner in branch '3.4': Issue #21488: Add support of keyword arguments for codecs.encode and codecs.decode http://hg.python.org/cpython/rev/6ceedbd88b5f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:11:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 15:11:44 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1400080304.72.0.587325549681.issue21488@psf.upfronthosting.co.za> STINNER Victor added the comment: I applied all patches and added Brad Aylsworth to Misc/ACKS. Thanks Brad! Note: I adapted the change for Python 2.7: the default encoding is ASCII, not UTF-8. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:13:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 15:13:56 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <3gTKCm0xyKz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 0d38044c0b02 by Victor Stinner in branch 'default': Issue #21488: Add support of keyword arguments for codecs.encode and codecs.decode http://hg.python.org/cpython/rev/0d38044c0b02 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:14:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 15:14:34 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1400080474.81.0.448380123946.issue21488@psf.upfronthosting.co.za> STINNER Victor added the comment: Ooops, I applied codecs_decode_encode_kw.patch to the branch 3.4 instead of default :-/ I should now be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:17:00 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 May 2014 15:17:00 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <1400080620.89.0.204407364708.issue21488@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:17:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 15:17:15 +0000 Subject: [issue21497] faulthandler should handle sys.stderr being None gracefully In-Reply-To: <1399990169.45.0.873283104693.issue21497@psf.upfronthosting.co.za> Message-ID: <3gTKHb0Bb5z7Llb@mail.python.org> Roundup Robot added the comment: New changeset ddd7db7cf036 by Victor Stinner in branch '3.4': Issue #21497: faulthandler functions now raise a better error if sys.stderr is http://hg.python.org/cpython/rev/ddd7db7cf036 New changeset cb26887f9140 by Victor Stinner in branch 'default': (Merge 3.4) Issue #21497: faulthandler functions now raise a better error if http://hg.python.org/cpython/rev/cb26887f9140 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:22:32 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 15:22:32 +0000 Subject: [issue21497] faulthandler should handle sys.stderr being None gracefully In-Reply-To: <1399990169.45.0.873283104693.issue21497@psf.upfronthosting.co.za> Message-ID: <1400080952.03.0.953834321919.issue21497@psf.upfronthosting.co.za> STINNER Victor added the comment: I applied my patch, thanks for the report. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:23:27 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 15:23:27 +0000 Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0 In-Reply-To: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za> Message-ID: <1400081007.29.0.114131427725.issue18777@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:29:21 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 15:29:21 +0000 Subject: [issue16442] PATH_MAX vs MAXPATHLEN vs pathconf(..., _PC_PATH_MAX). In-Reply-To: <1352393326.63.0.0902907389394.issue16442@psf.upfronthosting.co.za> Message-ID: <1400081361.17.0.632718278648.issue16442@psf.upfronthosting.co.za> Stefan Krah added the comment: The HP-UX issue is fixed. Are we leaving this open for IRIX? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:30:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 15:30:50 +0000 Subject: [issue21490] Add Py_ABS and Py_STRINGIFY macros In-Reply-To: <1399967922.02.0.0726994682155.issue21490@psf.upfronthosting.co.za> Message-ID: <3gTKbF4X3Lz7Lmn@mail.python.org> Roundup Robot added the comment: New changeset 849efd365ab4 by Victor Stinner in branch 'default': Issue #21490: Add new C macros: Py_ABS() and Py_STRINGIFY() http://hg.python.org/cpython/rev/849efd365ab4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:31:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 15:31:25 +0000 Subject: [issue21490] Add Py_ABS and Py_STRINGIFY macros In-Reply-To: <1399967922.02.0.0726994682155.issue21490@psf.upfronthosting.co.za> Message-ID: <1400081485.46.0.530015759098.issue21490@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:32:56 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 14 May 2014 15:32:56 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1400081576.75.0.214797615309.issue21506@psf.upfronthosting.co.za> Steve Dower added the comment: As far as Python 2.7 is concerned, I will be avoiding making any changes to the installer at all. For Python 3.5 I'm trying to work out a few of the install issues, one of them being not installing into Program Files. I think symlinks may be the way to make that change work, in which case it will be trivial to add two more. That said, I prefer the py.exe launcher anyway (especially since it handles 32/64-bit slightly better than this would), mostly since I intensely dislike permanently modifying PATH for anybody :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:34:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 15:34:21 +0000 Subject: [issue16442] PATH_MAX vs MAXPATHLEN vs pathconf(..., _PC_PATH_MAX). In-Reply-To: <1352393326.63.0.0902907389394.issue16442@psf.upfronthosting.co.za> Message-ID: <1400081661.68.0.106520436635.issue16442@psf.upfronthosting.co.za> STINNER Victor added the comment: > The HP-UX issue is fixed. Are we leaving this open for IRIX? Python doesn't support IRIX. I tried to fix compilation issues on IRIX related to PATH_MAX, but there are more serious compilation issues (ex: in socketmodule.c for example if I remember correctly). I suggest to close this issue. changeset: 87113:159e51e5fc2c branch: 3.3 parent: 87102:46fc4fb2c8c5 user: Victor Stinner date: Fri Nov 15 17:09:24 2013 +0100 files: Python/pythonrun.c description: pythonrun.c: fix Py_GetPythonHome(), use Py_ARRAY_LENGTH() to get the size of the env_home buffer, not PATH_MAX+1. env_home is declared using MAXPATHLEN+1, and PATH_MAX is not declared on IRIX. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:35:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 15:35:39 +0000 Subject: [issue7424] NetBSD: segmentation fault in listextend during install In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za> Message-ID: <1400081739.67.0.311012687298.issue7424@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: segmentation fault in listextend during install -> NetBSD: segmentation fault in listextend during install _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:58:43 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 15:58:43 +0000 Subject: [issue3539] Problem with testembed make dependencies in certain circumstances In-Reply-To: <1218416155.29.0.722740811463.issue3539@psf.upfronthosting.co.za> Message-ID: <1400083123.1.0.176648785007.issue3539@psf.upfronthosting.co.za> Stefan Krah added the comment: The original problem is fixed, but a similar one exists with testembed (see msg113305 for instructions): gcc -pthread -Xlinker -export-dynamic -o Modules/_testembed Modules/_testembed.o libpython3.5dm.a -lpthread -ldl -lutil -lm gcc: error: Modules/_testembed.o: No such file or directory make: *** [Modules/_testembed] Error 1 ---------- title: Problem with pgen make dependencies in certain circumstances -> Problem with testembed make dependencies in certain circumstances versions: +Python 3.5 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 17:59:02 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 15:59:02 +0000 Subject: [issue3539] Problem with testembed make dependencies in certain circumstances In-Reply-To: <1218416155.29.0.722740811463.issue3539@psf.upfronthosting.co.za> Message-ID: <1400083142.76.0.929434097368.issue3539@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 18:01:15 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 16:01:15 +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: <1400083275.18.0.746571585511.issue20128@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 18:20:48 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 14 May 2014 16:20:48 +0000 Subject: [issue21495] Sane default for logging config In-Reply-To: <1400061531.59.0.783087181942.issue21495@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: FWIW, I agree with Vinay. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 18:51:45 2014 From: report at bugs.python.org (eryksun) Date: Wed, 14 May 2014 16:51:45 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1400086305.12.0.878189638106.issue21506@psf.upfronthosting.co.za> eryksun added the comment: How about using hard links (mklink /H) instead? It's a minor issue, but there's a bug in Explorer that breaks opening symbolic links to EXE, COM, CMD, and BAT files (exefile, comfile, cmdfile, batfile). Explorer displays the error message "the specified path does not exist". These file types have shell\open\command set to "%1" %*, i.e. the file itself (%1) is used as the command. C:\>reg query hkcr\exefile\shell\open\command /ve HKEY_CLASSES_ROOT\exefile\shell\open\command (Default) REG_EXPAND_SZ "%1" %* I assume that's because these file types can be passed directly to CreateProcess. However, the Explorer bug isn't a problem with CreateProcess, or even ShellExecuteEx. Maybe it's due to an overly strict security policy. Anyway, my 2 cents is use hard links. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 18:59:21 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 14 May 2014 16:59:21 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1400086761.14.0.032622110849.issue21506@psf.upfronthosting.co.za> Steve Dower added the comment: > there's a bug in Explorer that breaks opening symbolic links to EXE, COM, CMD, and BAT files Do you know which versions of Windows this applies to? It works fine for me (though I'm up to date), and the file associations have not changed. I've seen some suggestions that creating a symlink without the right file extension (e.g. python2 <<===>> python.exe rather than python2.exe) will fail in some cases, but that's easily avoided by getting the symlink right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 19:18:55 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 May 2014 17:18:55 +0000 Subject: [issue21301] pathlib missing Path.expandvars(env=os.environ) In-Reply-To: <1397849465.53.0.177138390921.issue21301@psf.upfronthosting.co.za> Message-ID: <1400087935.62.0.918548318005.issue21301@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch to implement expandvars() for PurePath (with tests and documentation update). ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review Added file: http://bugs.python.org/file35252/issue21301.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 19:27:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 17:27:41 +0000 Subject: [issue21075] fileinput should use stdin.buffer for "rb" mode In-Reply-To: <1395927763.6.0.283357087125.issue21075@psf.upfronthosting.co.za> Message-ID: <1400088461.96.0.756425534621.issue21075@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 19:43:40 2014 From: report at bugs.python.org (eryksun) Date: Wed, 14 May 2014 17:43:40 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1400089420.0.0.965529019519.issue21506@psf.upfronthosting.co.za> eryksun added the comment: Here's a related superuser question: http://superuser.com/q/304093 The message box shown in the older answer is what I get: http://i.stack.imgur.com/bqXBs.png The problem is only with Explorer. I can execute a symbolic link to an EXE via cmd, subprocess.Popen, os.startfile (ShellExecute), and so on. Also, Explorer only does this for the executable file types that I mentioned. It has no problem opening symbolic links to .py files; the difference is the open command line for a Python.File includes a program to run: C:\>ftype Python.File Python.File="C:\Windows\py.exe" "%1" %* It works if I change the shell\open\command for the exefile type to run via cmd /c. But that's just silly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 19:59:55 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 May 2014 17:59: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: <1400090395.63.0.875490474.issue21360@psf.upfronthosting.co.za> R. David Murray added the comment: I wonder if changing this would break any working programs. I'd like to think not, but it is certainly possible for someone to be actually depending this bug. ---------- components: +email nosy: +akuchling, barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:09:27 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 18:09:27 +0000 Subject: [issue12619] Automatically regenerate platform-specific modules In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za> Message-ID: <1400090966.99.0.0407022601667.issue12619@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:11:11 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 18:11:11 +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: <1400091071.94.0.800856895972.issue16124@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:12:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 18:12:34 +0000 Subject: [issue21075] fileinput should use stdin.buffer for "rb" mode In-Reply-To: <1395927763.6.0.283357087125.issue21075@psf.upfronthosting.co.za> Message-ID: <3gTP9s4F3fz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 7e640fefc9c1 by Serhiy Storchaka in branch '3.4': Issue #21075: fileinput.FileInput now reads bytes from standard stream if http://hg.python.org/cpython/rev/7e640fefc9c1 New changeset 4041d4077a85 by Serhiy Storchaka in branch 'default': Issue #21075: fileinput.FileInput now reads bytes from standard stream if http://hg.python.org/cpython/rev/4041d4077a85 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:17:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 18:17:41 +0000 Subject: [issue21075] fileinput should use stdin.buffer for "rb" mode In-Reply-To: <1395927763.6.0.283357087125.issue21075@psf.upfronthosting.co.za> Message-ID: <1400091461.16.0.293473786399.issue21075@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Sam for your contribution. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:21:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 18:21:50 +0000 Subject: [issue1669539] Improve Windows os.path.join (ntpath.join) "smart" joining Message-ID: <1400091710.87.0.681555503549.issue1669539@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ntpath.join() was fixed in issue19456. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:24:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 14 May 2014 18:24:56 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1400091896.3.0.709833596404.issue21402@psf.upfronthosting.co.za> Terry J. Reedy added the comment: >Due to the risk of breaking existing user code which uses these private functions, they should be left with old signature and new functions should be added. The reason we make things private is so we don't have to do this. Why would you make an exception here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:33:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 18:33:11 +0000 Subject: [issue15809] IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1400092391.37.0.772039579327.issue15809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm going to commit my patch in few days. This is not perfect solution, but I believe it is better than current state. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:41:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 18:41:01 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1400091896.3.0.709833596404.issue21402@psf.upfronthosting.co.za> Message-ID: <1908624.D9UlOgNKy6@raxxla> Serhiy Storchaka added the comment: Because there are explicit tests for these private functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:44:43 2014 From: report at bugs.python.org (Stephen Paul Chappell) Date: Wed, 14 May 2014 18:44:43 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1400093083.72.0.270654211743.issue21402@psf.upfronthosting.co.za> Stephen Paul Chappell added the comment: >Because there are explicit tests for these private functions. Does that not mean that both the functions and their explicit tests should be changed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:46:30 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 14 May 2014 18:46:30 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1400093190.54.0.104647304303.issue21506@psf.upfronthosting.co.za> Steve Dower added the comment: Apparently there's a distinction between absolute and relative symlinks. Do you see a difference between: > mklink python2.7.exe python.exe and > mklink python2.7.exe C:\Python27\python.exe ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:52:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 18:52:07 +0000 Subject: [issue20998] fullmatch isn't matching correctly under re.IGNORECASE In-Reply-To: <1395340840.43.0.0546340493094.issue20998@psf.upfronthosting.co.za> Message-ID: <3gTQ3V6fgbz7Ll3@mail.python.org> Roundup Robot added the comment: New changeset 6267428afbdb by Serhiy Storchaka in branch '3.4': Issue #20998: Fixed re.fullmatch() of repeated single character pattern http://hg.python.org/cpython/rev/6267428afbdb New changeset bcf64c1c92f6 by Serhiy Storchaka in branch 'default': Issue #20998: Fixed re.fullmatch() of repeated single character pattern http://hg.python.org/cpython/rev/bcf64c1c92f6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 20:57:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 18:57:45 +0000 Subject: [issue20998] fullmatch isn't matching correctly under re.IGNORECASE In-Reply-To: <1395340840.43.0.0546340493094.issue20998@psf.upfronthosting.co.za> Message-ID: <1400093865.66.0.49662516684.issue20998@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Matthew for your contribution. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 21:38:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 May 2014 19:38:11 +0000 Subject: [issue21487] Assorted ipaddress performance improvements In-Reply-To: <1399925063.26.0.615670484521.issue21487@psf.upfronthosting.co.za> Message-ID: <1400096291.63.0.879549218673.issue21487@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as second alternative is few percents faster then first one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 21:39:55 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 14 May 2014 19:39:55 +0000 Subject: [issue19625] IDLE 2.7 should use UTF-8 as it's default encoding In-Reply-To: <1384613631.52.0.52309466252.issue19625@psf.upfronthosting.co.za> Message-ID: <1400096395.33.0.800818410131.issue19625@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For the benefit of anyone finding this in a search, I fixed the title to match the actual request. UTF-8 *is* already the default encoding in 3.x, and upgrading to 3.x if at all possible is the best solution to unicode problems. ---------- nosy: +terry.reedy title: IDLE should use UTF-8 as it's default encoding -> IDLE 2.7 should use UTF-8 as it's default encoding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 22:07:54 2014 From: report at bugs.python.org (Rose Ames) Date: Wed, 14 May 2014 20:07:54 +0000 Subject: [issue20977] pyflakes: undefined "ctype" in 2 except blocks in the email module In-Reply-To: <1395226153.72.0.859360673019.issue20977@psf.upfronthosting.co.za> Message-ID: <1400098074.2.0.95471982283.issue20977@psf.upfronthosting.co.za> Rose Ames added the comment: Thanks guys! Added minimal tests necessary to expose the bug. ---------- Added file: http://bugs.python.org/file35253/expose_bug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 22:21:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 14 May 2014 20:21:46 +0000 Subject: [issue15809] 2.7 IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1400098906.02.0.98976557678.issue15809@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It took me awhile to re-recognize ??? ?? ???????: as 'made in konsole'. I agree that the discrepancy between Idle shell and console is a bug relative to a general goal of having them work as nearly the same as possible and sensible. > This bug is critical for non-ASCII-only users of IDLE. This bug, like many others involving non-Ascii chars, has already been fixed in 3.x, though it is not only a 2 versus 3 issue. Given that there are technical limits to imitating the console, we could have closed this issue as already fixed, "wont fix" in 2.7, upgrade to a version that has the fix. However, since this is also a within 2.7, console versus Idle issue, improvement would be good. The +coding cookie, -1 line hack induces a non-obvious dependency between files that I think should be documented by comments such as # run.cleanup_traceback() compensates for added line # compensation for coding cookie added in pyshel..runsource() I think it ok to push less than perfect patches that make definite improvements and do not preclude possibly better patches in the future. I have not seen any comment from alex whether this fixes his particular example on his machine, but if you are convinced that this fixes some problems and only causes a micro slowdown of working uses, go ahead. ---------- title: IDLE console uses incorrect encoding. -> 2.7 IDLE console uses incorrect encoding. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 22:32:52 2014 From: report at bugs.python.org (eryksun) Date: Wed, 14 May 2014 20:32:52 +0000 Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za> Message-ID: <1400099572.56.0.733615130779.issue21506@psf.upfronthosting.co.za> eryksun added the comment: Using a relative target in the link isn't the problem for me here. (See issue 13702 for another problem with relative links.) I'm in the same boat as commenter weberc2. Same symptom; apparently a different problem. I'm using an absolute path for the target: C:\Program Files\Python\Scripts>mklink python2.7.exe "C:\Program Files\Python\Python27\python.exe" symbolic link created for python2.7.exe <<===>> C:\Program Files\Python\Python27\python.exe (Mirror the --user layout in %AppData%.) This works fine from cmd, but not Explorer. Anyway, the link would be added to support shell scripts that use shebangs for environments such as MSYS, so executing with Explorer isn't the goal anyway. The shortcut in the start menu would target python.exe, not the symbolic/hard link. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 22:32:52 2014 From: report at bugs.python.org (Kristian Benoit) Date: Wed, 14 May 2014 20:32:52 +0000 Subject: [issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks Message-ID: <1400099572.93.0.56172954955.issue21509@psf.upfronthosting.co.za> New submission from Kristian Benoit: I'm trying to parse a json and keep getting ValueError. File reports the file as being "UTF-8 Unicode (with BOM) text", vim reports it as UTF-8, ... json.load docs says it support UTF-8 out of the box. Here's a link to the file : http://donnees.ville.sherbrooke.qc.ca/storage/f/2014-03-10T17%3A45%3A18.959Z/matieres-residuelles.json ---------- files: matieres.json messages: 218573 nosy: Kristian.Benoit priority: normal severity: normal status: open title: json.load fails to read UTF-8 file with (BOM) Byte Order Marks type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file35254/matieres.json _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 23:37:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 May 2014 21:37:35 +0000 Subject: [issue21488] codecs.encode/decode documentation inconsistency In-Reply-To: <1399937850.38.0.349005624478.issue21488@psf.upfronthosting.co.za> Message-ID: <3gTTkQ5n2xz7Ljq@mail.python.org> Roundup Robot added the comment: New changeset 0a6f0aaeb96a by Victor Stinner in branch '2.7': Issue #21488: Oops, the patch for codecs.encode/decode doc was written by http://hg.python.org/cpython/rev/0a6f0aaeb96a New changeset 91dca6b9ef0f by Victor Stinner in branch '3.4': Issue #21488: Oops, the patch for codecs.encode/decode doc was written by http://hg.python.org/cpython/rev/91dca6b9ef0f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 23:38:28 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 May 2014 21:38:28 +0000 Subject: [issue21363] io.TextIOWrapper always closes wrapped files In-Reply-To: <1398603389.33.0.793055654008.issue21363@psf.upfronthosting.co.za> Message-ID: <1400103508.13.0.488902350513.issue21363@psf.upfronthosting.co.za> R. David Murray added the comment: I think detach is the correct way to to this, so I'm closing the issue. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 23:40:23 2014 From: report at bugs.python.org (Armin Ronacher) Date: Wed, 14 May 2014 21:40:23 +0000 Subject: [issue21363] io.TextIOWrapper always closes wrapped files In-Reply-To: <1398603389.33.0.793055654008.issue21363@psf.upfronthosting.co.za> Message-ID: <1400103623.47.0.218224445012.issue21363@psf.upfronthosting.co.za> Armin Ronacher added the comment: Detach "destroys" the stream, so it's not a solution. I can't just randomly destroy global state just because it's convenient. This is what I am doing now which seems borderline insane: https://github.com/mitsuhiko/click/blob/master/click/_compat.py#L31 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 23:42:11 2014 From: report at bugs.python.org (Armin Ronacher) Date: Wed, 14 May 2014 21:42:11 +0000 Subject: [issue21363] io.TextIOWrapper always closes wrapped files In-Reply-To: <1398603389.33.0.793055654008.issue21363@psf.upfronthosting.co.za> Message-ID: <1400103731.53.0.242962095314.issue21363@psf.upfronthosting.co.za> Armin Ronacher added the comment: Ah. Misread. This is about detaching the underlying stream from TextIOWrapper. I assume this could be done in the __del__ so that would work. I'm checking this now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 23:45:23 2014 From: report at bugs.python.org (Armin Ronacher) Date: Wed, 14 May 2014 21:45:23 +0000 Subject: [issue21363] io.TextIOWrapper always closes wrapped files In-Reply-To: <1398603389.33.0.793055654008.issue21363@psf.upfronthosting.co.za> Message-ID: <1400103923.87.0.372001202.issue21363@psf.upfronthosting.co.za> Armin Ronacher added the comment: I can confirm that calling detach() in __del__ within an except block solves the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 23:49:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 21:49:58 +0000 Subject: [issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks In-Reply-To: <1400099572.93.0.56172954955.issue21509@psf.upfronthosting.co.za> Message-ID: <1400104198.9.0.0755359538288.issue21509@psf.upfronthosting.co.za> STINNER Victor added the comment: In Python 2, json.loads() accepts str and unicode types. You can support JSON starting with a UTF-8 BOM using the Python codec "utf-8-sig". Example: >>> codecs.BOM_UTF8 + b'{\n}' '\xef\xbb\xbf{\n}' >>> json.loads(codecs.BOM_UTF8 + b'{\n}') Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads return _default_decoder.decode(s) File "/usr/lib64/python2.7/json/decoder.py", line 365, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode raise ValueError("No JSON object could be decoded") ValueError: No JSON object could be decoded >>> json.loads((codecs.BOM_UTF8 + b'{\n}').decode('utf-8-sig')) {} ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 14 23:54:27 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 May 2014 21:54:27 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1400104467.31.0.515398076175.issue21364@psf.upfronthosting.co.za> R. David Murray added the comment: The issue of (mixed) string and binary input/output on the standard streams is still a bit of a work in progress, I think, both documentation wise and code wise. So I'm not sure we know yet what the best practice is to recommend here. I think I agree with Armin, though. I think mentioning reading binary from sys.stdin.buffer is fine, but suggesting replacing the streams is bad. If someone figures that out on their own, it's on their own head, but I don't think we should suggest it. That said, that shutdown error message is probably a bug of one sort or another. ---------- nosy: +r.david.murray versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 00:05:20 2014 From: report at bugs.python.org (Armin Ronacher) Date: Wed, 14 May 2014 22:05:20 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1400105120.84.0.326764877864.issue21364@psf.upfronthosting.co.za> Armin Ronacher added the comment: Sidestepping: The shutdown message is a related issue. TextIOWrapper tends to internally log errors apparently which is super annoying and probably should be fixed. I encountered the same problem with sockets disconnecting wrapped in TextIOWrapper always writing some dummy traceback to stderr which I can't silence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 00:18:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 22:18:50 +0000 Subject: [issue21507] set and frozenset constructor should use operator.length_hint to guess the size of the iterator In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400105930.13.0.182632478399.issue21507@psf.upfronthosting.co.za> STINNER Victor added the comment: frozenset constructor has different implementations depending on the input type: set (or frozenset), dict or iterator. The constructor preallocates the frozenset for set and dict, but not for generic iterator and so the set may have a suboptimal size. Attached patch set_length_hint.patch optimizes also the 3rd case using operator.length_hint (PyObject_LengthHint in C). Since it is an optimization, I prefer to only apply it to Python 3.5 to limit the risk of regression. ---------- keywords: +patch nosy: +haypo title: memory used by frozenset created from set differs from that of frozenset created from other iterable -> set and frozenset constructor should use operator.length_hint to guess the size of the iterator versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file35255/set_length_hint.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 00:19:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 22:19:08 +0000 Subject: [issue21507] set and frozenset constructor should use operator.length_hint to guess the size of the iterator In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400105948.3.0.991184794177.issue21507@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 00:28:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 22:28:53 +0000 Subject: [issue21504] can the subprocess module war using os.wait4 and so return usage? In-Reply-To: <1400035246.64.0.2270855198.issue21504@psf.upfronthosting.co.za> Message-ID: <1400106533.38.0.413278792286.issue21504@psf.upfronthosting.co.za> STINNER Victor added the comment: I guess that you mean "Popen" when you write "Pipe"? Even if Popen has a high-level wait() method implemented with os.waitpid(), you are free to use a low-level function using the pid attribute. proc = subprocess.Popen(...) os.wait4(proc.pid, ...) > have an new data member, rusage, make the resource usage available to the caller. I don't know how to get the rusage of a specific child process, but you can use resource.getrusage(resource.RUSAGE_CHILDREN) which gives the usage of *all* child processes. Again, you have the pid, and so you are free to use any function to retrieve the resource usage of the child process. See also this project which can help you: https://pypi.python.org/pypi/psutil I don't think that the subprocess should be modified to your use case, it's already possible to implement you use cases without modify it. Python is a (very) portable language, and it's very hard to provide the same API for such low-level metrics (rusage). I don't think that Windows provides exactly the same data for example. You can build your own module on top of subprocess and other modules like psutil. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 00:34:37 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 22:34:37 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1400106877.11.0.917645440687.issue21027@psf.upfronthosting.co.za> STINNER Victor added the comment: $ ./python -m difflib -u a.py b.py ... sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='a.py' mode='r' encoding='UTF-8'> sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='b.py' mode='r' encoding='UTF-8'> It looks like files are not closed. I would prefer to have the unified output (-u) by default. I don't think that Python should mimick exactly UNIX tools. tarfile has now a command line interface, but options are different. For example, it's -e to extract instead of -x. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 00:40:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 May 2014 22:40:28 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1400107228.32.0.826643627195.issue21027@psf.upfronthosting.co.za> STINNER Victor added the comment: The HTML output contains an encoding in the : The problem is that sys.stdout may use a different encoding. For example, my locale encoding is UTF-8. So "python -m difflib -um a.py b.py > test.html" produces an HTML file encoded in UTF-8 but announcing a ISO 8859-1 header. There are different options to fix this issue: * drop the --html command line option * drop the invalid Content-Type header * add an option to write the diff into a file, use UTF-8 to encode this file and emit a correct HTTP header (announce UTF-8) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 01:04:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 14 May 2014 23:04:14 +0000 Subject: [issue14198] Backport parts of the new memoryview documentation In-Reply-To: <1330939816.35.0.731110214123.issue14198@psf.upfronthosting.co.za> Message-ID: <1400108654.84.0.5512160991.issue14198@psf.upfronthosting.co.za> Stefan Krah added the comment: This is actually a lot of work, I don't think I'll have time for it. Please just reopen if you think there's a chance that someone will take the task. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 01:13:20 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 May 2014 23:13:20 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1400109200.86.0.893504694546.issue21027@psf.upfronthosting.co.za> Berker Peksag added the comment: > The HTML output contains an encoding in the : > See issue2052 for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 02:52:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 00:52:14 +0000 Subject: [issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks In-Reply-To: <1400099572.93.0.56172954955.issue21509@psf.upfronthosting.co.za> Message-ID: <1400115134.73.0.607080570576.issue21509@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 03:09:19 2014 From: report at bugs.python.org (donald petravick) Date: Thu, 15 May 2014 01:09:19 +0000 Subject: [issue21504] can the subprocess module war using os.wait4 and so return usage? In-Reply-To: <1400106533.38.0.413278792286.issue21504@psf.upfronthosting.co.za> Message-ID: donald petravick added the comment: Victor, thanks so much for reading my ticket and contacting me. I prototyped what makes sense to me by subclassing subprocess.Popen and Over-ridden the wait method to do what I suggested. Proof of concept attached. \ It?s a bit of a hack since I cribbed code from Popen.wait(). Now that you?ve made me think harder, The use case that stood out was the case where I called the communicate() method which both handles IO and the termination of the process AFAICT. I _do_ understand the portability argument you are making (and am clueless about what?s to be done with windows). ? Thanks ? Don On 5/14/14, 5:28 PM, "STINNER Victor" wrote: > >STINNER Victor added the comment: > >I guess that you mean "Popen" when you write "Pipe"? > >Even if Popen has a high-level wait() method implemented with >os.waitpid(), you are free to use a low-level function using the pid >attribute. > >proc = subprocess.Popen(...) >os.wait4(proc.pid, ...) > >> have an new data member, rusage, make the resource usage available to >>the caller. > >I don't know how to get the rusage of a specific child process, but you >can use resource.getrusage(resource.RUSAGE_CHILDREN) which gives the >usage of *all* child processes. Again, you have the pid, and so you are >free to use any function to retrieve the resource usage of the child >process. See also this project which can help you: >https://pypi.python.org/pypi/psutil > >I don't think that the subprocess should be modified to your use case, >it's already possible to implement you use cases without modify it. >Python is a (very) portable language, and it's very hard to provide the >same API for such low-level metrics (rusage). I don't think that Windows >provides exactly the same data for example. > >You can build your own module on top of subprocess and other modules like >psutil. > >---------- >nosy: +haypo > >_______________________________________ >Python tracker > >_______________________________________ > ---------- Added file: http://bugs.python.org/file35256/subprocess4.pyc _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: subprocess4.pyc Type: application/octet-stream Size: 1402 bytes Desc: not available URL: From report at bugs.python.org Thu May 15 04:08:21 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 15 May 2014 02:08:21 +0000 Subject: [issue21507] set and frozenset constructor should use operator.length_hint to guess the size of the iterator In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400119701.62.0.579289347615.issue21507@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I think the argument against using PyObject_LengthHint for the general iterable case is that for inputs other than sets or dicts, the assumption is that significant deduplication will occur. With your patch, if I run: myset = frozenset([0] * 1000000) it will allocate space for, if I'm reading it correctly, two million entries, and use exactly one of them. Obviously not the common case, but preallocating when you have no idea how much duplication will occur seems like a bad idea. With a set or dict, you know it's already deduplicated, so preallocation is always a good thing, but for the general case, you'll be using more memory than necessary much of the time. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 04:18:32 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 15 May 2014 02:18:32 +0000 Subject: [issue21508] C API PyArg_ParseTuple doc is innacurate In-Reply-To: <1400078023.63.0.359608332224.issue21508@psf.upfronthosting.co.za> Message-ID: <1400120312.28.0.766994433431.issue21508@psf.upfronthosting.co.za> Josh Rosenberg added the comment: You'd prefer it say it returns 1 on success and 0 on failure? Or non-zero on success, zero on failure? Is true/false that bad? After all, C says 0 is false, all other integer values are true; phrasing it as zero vs. non-zero may be slightly more technically accurate, but it's also a bit less readable, while 1 vs. 0 constrains the implementation (so you couldn't introduce a third "success but with additional info" state, similar to the third possible return from a "O&" converter function). ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 06:51:06 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 15 May 2014 04:51:06 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1400129466.39.0.274191524137.issue21027@psf.upfronthosting.co.za> Raymond Hettinger added the comment: After more thought, I think this should remain in tools as a demo. We don't have an objective to create command-line tools to compete with existing well developed, tested tools. For the most part, our command line tools exposed through the -m option are few in number and mostly limited to things that aid development or don't have a readily available alternative. I recommend closing this to avoid feature creep. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 07:19:05 2014 From: report at bugs.python.org (Jayanth Koushik) Date: Thu, 15 May 2014 05:19:05 +0000 Subject: [issue21510] fma documentation should provide better example. Message-ID: <1400131145.93.0.338142878224.issue21510@psf.upfronthosting.co.za> New submission from Jayanth Koushik: The documentation for decimal.fma provides an example which fails to illustrate the most important feature of the function i.e. single rounding. In fact: Decimal(2).fma(3, 5) == Decimal(2)*3 + 5 An example such as this would make it much more clear: >>> getcontext().prec = 2 >>> getcontext().rounding = ROUND_DOWN >>> Decimal('1.5')*Decimal('1.5') + Decimal('1.05') Decimal('3.2') >>> Decimal('1.5').fma(Decimal('1.5'), Decimal('1.05')) Decimal('3.3') ---------- assignee: docs at python components: Documentation messages: 218592 nosy: docs at python, jayanthkoushik priority: normal severity: normal status: open title: fma documentation should provide better example. type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 09:03:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 07:03:28 +0000 Subject: [issue21507] set and frozenset constructor should use operator.length_hint to guess the size of the iterator In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400137408.81.0.451782949688.issue21507@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree with Josh's arguments. Similar idea was already proposed and rejected (issue17338). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 09:08:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 07:08:40 +0000 Subject: [issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks In-Reply-To: <1400099572.93.0.56172954955.issue21509@psf.upfronthosting.co.za> Message-ID: <1400137720.67.0.62313321932.issue21509@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Currently json.load/loads don't support binary input. See issue17909 and issue19837. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 09:12:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 May 2014 07:12:01 +0000 Subject: [issue21507] set and frozenset constructor should use operator.length_hint to guess the size of the iterator In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400137921.65.0.986342118984.issue21507@psf.upfronthosting.co.za> STINNER Victor added the comment: "I think the argument against using PyObject_LengthHint for the general iterable case is that for inputs other than sets or dicts, the assumption is that significant deduplication will occur." Oh... I'm dumb :) Sorry. Another option for frozenset only: we may adjust the internal size when the frozenset is created from an iterator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 09:25:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 May 2014 07:25:05 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1400138705.77.0.150420194125.issue21027@psf.upfronthosting.co.za> STINNER Victor added the comment: > After more thought, I think this should remain in tools as a demo. I disagree, I like the command line interface. It's very useful on Windows for example. It's also useful on UNIX embedded devices where Python is installed, but only a few UNIX tools. If you are not convinced, please see this amazing talk of David Beazley at Pycon 2014: http://pyvideo.org/video/2645/discovering-python The patch only adds a few lines to difflib.py. IMO difflib CLI is even more useful than tarfile CLI ;-) It's not like no other Python module has a CLI. Modules with a CLI of Python 3.5: aifc base64 calendar cgi code compileall cProfile dis doctest filecmp fileinput formatter ftplib getopt gzip imaplib imghdr inspect locale mailcap mimetypes modulefinder netrc nntplib pdb pickle pickletools platform poplib pprint profile pstats pyclbr py_compile pydoc quopri random runpy shlex site smtpd smtplib sndhdr sre_constants symbol symtable sysconfig tabnanny tarfile telnetlib textwrap timeit tokenize token trace turtle uu webbrowser zipfile ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 09:26:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 May 2014 07:26:10 +0000 Subject: [issue19837] Wire protocol encoding for the JSON module In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za> Message-ID: <1400138770.11.0.985716606198.issue19837@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 09:26:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 May 2014 07:26:13 +0000 Subject: [issue17909] Autodetecting JSON encoding In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za> Message-ID: <1400138773.79.0.928509574172.issue17909@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 09:26:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 07:26:14 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400138774.55.0.515048816946.issue13916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This issue was mainly resolved in issue12892. The surrogatepass error handler now works with UTF-16* and UTF-32* encodings. But for other encodings it behaves as for UTF-8 (preserve old behavior). Should we change the behavior for non-UTF encodings end raise an exception (as for "strict")? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 10:01:28 2014 From: report at bugs.python.org (Peter Kruse) Date: Thu, 15 May 2014 08:01:28 +0000 Subject: [issue19186] expat symbols should be namespaced in pyexpat again In-Reply-To: <1381151097.4.0.844657685559.issue19186@psf.upfronthosting.co.za> Message-ID: <1400140888.89.0.682442007949.issue19186@psf.upfronthosting.co.za> Peter Kruse added the comment: Fascinating, you are right, very good, thanks for your time and looking into this. Peter ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 11:36:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 09:36:08 +0000 Subject: [issue15809] 2.7 IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1400146568.76.0.801850826437.issue15809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Alternative solution is to force UTF-8 in IDLE console. But I think this will be more surprising, especially for Windows users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 11:47:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 09:47:15 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400147235.76.0.0226203670206.issue13916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which disallows the surrogatepass handler for non-utf encodings. Please test it on Windows. ---------- type: behavior -> enhancement versions: +Python 3.5 -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 12:04:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 May 2014 10:04:06 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400148246.77.0.0627545342764.issue13916@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka wrote: > Here is a patch I don't see your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 12:40:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 10:40:09 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400150409.76.0.473750815292.issue13916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry. ---------- keywords: +patch Added file: http://bugs.python.org/file35257/surrogatepass_non_utf.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 13:22:18 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 15 May 2014 11:22:18 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400152938.6.0.906055628598.issue13916@psf.upfronthosting.co.za> Martin v. L?wis added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 13:35:11 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 15 May 2014 11:35:11 +0000 Subject: [issue21510] fma documentation should provide better example. In-Reply-To: <1400131145.93.0.338142878224.issue21510@psf.upfronthosting.co.za> Message-ID: <1400153711.65.0.390192493869.issue21510@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 13:37:04 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 15 May 2014 11:37:04 +0000 Subject: [issue21510] fma documentation should provide better example. In-Reply-To: <1400131145.93.0.338142878224.issue21510@psf.upfronthosting.co.za> Message-ID: <1400153824.63.0.901174680173.issue21510@psf.upfronthosting.co.za> Mark Dickinson added the comment: I wouldn't want to drop the simple example: I suspect that many of those looking at fma won't have the first idea what it does, and that first example shows clearly that it's a fused multiply-add. But +1 for an example that demonstrates the single rounding, either in the online docs or the docstring (or both). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 13:37:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 May 2014 11:37:54 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <3gTrN16DDJz7Lkw@mail.python.org> Roundup Robot added the comment: New changeset 5e98a50e0f55 by Serhiy Storchaka in branch 'default': Issue #13916: Disallowed the surrogatepass error handler for non UTF-* http://hg.python.org/cpython/rev/5e98a50e0f55 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 13:40:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 11:40:10 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400154010.89.0.97524359561.issue13916@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 13:41:03 2014 From: report at bugs.python.org (Jayanth Koushik) Date: Thu, 15 May 2014 11:41:03 +0000 Subject: [issue21510] fma documentation should provide better example. In-Reply-To: <1400131145.93.0.338142878224.issue21510@psf.upfronthosting.co.za> Message-ID: <1400154063.78.0.495867988579.issue21510@psf.upfronthosting.co.za> Jayanth Koushik added the comment: @Mark: I agree. And perhaps it is also worth mentioning (on an unrelated note), that the decimal fma is not based on the internal cmath fma (it could not be) and unlike the cmath fma, it is no faster than an unfused multiply-add. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 14:35:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 12:35:56 +0000 Subject: [issue21487] Assorted ipaddress performance improvements In-Reply-To: <1399925063.26.0.615670484521.issue21487@psf.upfronthosting.co.za> Message-ID: <1400157356.88.0.067207342707.issue21487@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I find logical operations on negative numbers confusing in Python, so I'd rather stick with the first implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 14:38:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 12:38:58 +0000 Subject: [issue17909] Autodetecting JSON encoding In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za> Message-ID: <1400157538.81.0.146503258133.issue17909@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: All dependencies for this issue are resolved now. Here is updated patch, synchronized with tip. ---------- Added file: http://bugs.python.org/file35258/json_detect_encoding_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 14:39:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 12:39:43 +0000 Subject: [issue17909] Autodetecting JSON encoding In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za> Message-ID: <1400157583.37.0.882460241566.issue17909@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30133/json_detect_encoding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 14:43:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 12:43:42 +0000 Subject: [issue21486] optimize v4 & v6 netmask parsing In-Reply-To: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> Message-ID: <1400157822.36.0.940964899367.issue21486@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What I want to say, the patch LGTM, but after committing issue14373 we should simplify the code by using functools.lru_cache(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 14:49:10 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 12:49:10 +0000 Subject: [issue21486] optimize v4 & v6 netmask parsing In-Reply-To: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> Message-ID: <1400158150.02.0.857380660919.issue21486@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, using lru_cache(maxsize=None) would enable a simple infinite cache like in the patch. But it's not like a lot of code would be saved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 15:12:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 May 2014 13:12:01 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400159521.27.0.644506361025.issue13916@psf.upfronthosting.co.za> STINNER Victor added the comment: It makes sense to restrict surrogatepass to UTF-* encodings. UTF-8, UTF-16 and UTF-32 encoders reject surrogate characters, but not UTF-7. Is it a bug? I'm asking because PyCodec_SurrogatePassErrors() doesn't support UTF-7. IMO your change is important enough to be mentionned in What's new Python 3.5 document, and maybe also in the documentation of the codecs module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 15:47:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 May 2014 13:47:06 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400161626.96.0.88488176702.issue13916@psf.upfronthosting.co.za> STINNER Victor added the comment: Windows buildbots are unhappy. http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8355/steps/test/logs/stdio ====================================================================== ERROR: test_surrogatepass_handler (test.test_codecs.CP65001Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py", line 883, in test_surrogatepass_handler self.assertEqual("abc\ud800def".encode("cp65001", "surrogatepass"), UnicodeEncodeError: 'CP_UTF8' codec can't encode character '\ud800' in position 3: invalid character ====================================================================== FAIL: test_encode (test.test_codecs.CP65001Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py", line 818, in test_encode encoded = text.encode('cp65001', errors) UnicodeEncodeError: 'CP_UTF8' codec can't encode character '\udc80' in position 0: invalid character During handling of the above exception, another exception occurred: Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py", line 821, in test_encode 'errors=%r: %s' % (text, errors, err)) AssertionError: Unable to encode '\udc80' to cp65001 with errors='surrogatepass': 'CP_UTF8' codec can't encode character '\udc80' in position 0: invalid character ====================================================================== FAIL: test_cp1252 (test.test_codecs.CodePageTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py", line 2849, in test_cp1252 (b'[\x98]', 'surrogatepass', None), File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py", line 2781, in check_decode codecs.code_page_decode, cp, raw, errors, True) AssertionError: UnicodeDecodeError not raised by code_page_decode ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 17:11:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 15:11:49 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400166709.51.0.671795848912.issue13916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch, which adds support for cp65001 and fixes test_cp1252. Please test it on Windows Vista. Lone surrogates are not illegal in UTF-7 (see RFC 1642), so error handler is not called and explicit support of UTF-7 is not needed. Could you please help with documenting this change in What's new Python 3.5 document? I don't think this change is worth special mentioning in codecs documentation, it is already documented that surrogatepass is supported only for utf-8, utf-16* and utf-32*. ---------- Added file: http://bugs.python.org/file35259/surrogatepass_cp_utf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 17:13:47 2014 From: report at bugs.python.org (Steve) Date: Thu, 15 May 2014 15:13:47 +0000 Subject: [issue21508] C API PyArg_ParseTuple doc is innacurate In-Reply-To: <1400078023.63.0.359608332224.issue21508@psf.upfronthosting.co.za> Message-ID: <1400166827.18.0.642641732438.issue21508@psf.upfronthosting.co.za> Steve added the comment: I would prefer the function to return "bool". But what I prefer is irrelevant, what counts is accuracy and clarity. And to this end, the return type and the comment have to match. For a int return value, the document should mention a condition relative to an integer value (e.g.: ==0, !=0, ==-1, <0, ==42, etc). In this particular case, to minimize the changes, success should be defined as !=0 and failure ==0. Although there is a bigger problem that I mentioned in that the Python C API uses two different return value standards: in most places, ==0 is success, in this case (and some other places) ==0 is a failure. As for "implementation constraints" I don't see how making the documentation accurate affects that in any way. If ever the implementation is expanded, the documentation will need to change. The only alternative is to make the doc vague or simply wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 17:23:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 May 2014 15:23:26 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400167406.88.0.51666648889.issue13916@psf.upfronthosting.co.za> STINNER Victor added the comment: > Here is a patch, which adds support for cp65001 The name of the encoding is "cp65001", not something like "cp-utf8". And there is no alias like "cp_65001", there is only "cp65001". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 18:07:28 2014 From: report at bugs.python.org (Chris Rebert) Date: Thu, 15 May 2014 16:07:28 +0000 Subject: [issue17909] Autodetecting JSON encoding In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za> Message-ID: <1400170048.91.0.337169252678.issue17909@psf.upfronthosting.co.za> Chris Rebert added the comment: You'll need to also update the "Character Encodings" subsection of the json docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 18:23:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 May 2014 16:23:16 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1400167406.88.0.51666648889.issue13916@psf.upfronthosting.co.za> Message-ID: <82374481.FRY6Zd5sSy@raxxla> Serhiy Storchaka added the comment: But an exception reports about CP_UTF8. ---------- title: disallow the "surrogatepass" handler for non utf-* encodings -> disallow the "surrogatepass" handler for non utf-* encodings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 18:37:35 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Thu, 15 May 2014 16:37:35 +0000 Subject: [issue21511] Thinko in Lib/quopri.py Message-ID: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za> New submission from Paul Sokolovsky: Lib/quopri.py for version 3.3..3.5-tip contains following code: ESCAPE = b'=' ... line = input.readline() if not line: break i, n = 0, len(line) if n > 0 and line[n-1:n] == b'\n': ... elif i+1 < n and line[i+1] == ESCAPE: So, ESCAPE is defined as bytes, we see that "line" is read as bytes, and characters are accessed using idiom like "line[n-1:n]", but then it uses "line[i+1]", which returns int and thus will never be equal to ESCAPE. I'm not sure what exact semantic condition that branch represents, for me it looks like "==" sequence to be decoded as "=". But I don't see such encoding variant in http://en.wikipedia.org/wiki/Quoted-printable . Either way, replacing that condition with "and False", still passes test_quopri.py ---------- components: Library (Lib) messages: 218618 nosy: pfalcon priority: normal severity: normal status: open title: Thinko in Lib/quopri.py type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 19:50:18 2014 From: report at bugs.python.org (Ryder Lewis) Date: Thu, 15 May 2014 17:50:18 +0000 Subject: [issue21512] time module becomes None after raise SystemExit Message-ID: <1400176218.84.0.180838501812.issue21512@psf.upfronthosting.co.za> New submission from Ryder Lewis: I'm not sure if this is a bug or expected behavior, but basically what I want to do is log the timestamp when an application exits. Sample script to illustrate the issue: ==== try.py ==== import time class A(): def __init__(self): print("Initializing A. The time is {}".format(time.time())) def __del__(self): if time is None: print("time is None!") else: print("Deleting A. The time is {}".format(time.time())) a = A() raise SystemExit() ===== When running this script multiple times, there are 3 possible outcomes: ==== outcome #1 (happens about 25% of my trial runs, what I would expect is correct behavior) ==== Initializing A. The time is 1400175810.4806361 Deleting A. The time is 1400175810.483156 ==== outcome #2 (happens about 50% of my trial runs) ==== Initializing A. The time is 1400175814.1646852 time is None! ==== outcome #3 (happens about 25% of my trial runs) ==== Initializing A. The time is 1400175809.6802816 Exception ignored in: > Traceback (most recent call last): File "./try.py", line 12, in __del__ TypeError: 'NoneType' object is not callable ---------- components: Interpreter Core messages: 218619 nosy: ryder.lewis priority: normal severity: normal status: open title: time module becomes None after raise SystemExit type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 19:52:30 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 15 May 2014 17:52:30 +0000 Subject: [issue21512] time module becomes None after raise SystemExit In-Reply-To: <1400176218.84.0.180838501812.issue21512@psf.upfronthosting.co.za> Message-ID: <1400176350.2.0.564485884641.issue21512@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +benjamin.peterson, pitrou resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 20:11:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 18:11:49 +0000 Subject: [issue21512] time module becomes None after raise SystemExit In-Reply-To: <1400176218.84.0.180838501812.issue21512@psf.upfronthosting.co.za> Message-ID: <1400177509.13.0.360502811535.issue21512@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, let's call it a limitation rather than a bug. When creating a global variable (such as "a" in your example), that variable is kept alive at least as long as the module containing it. However, modules usually live until very late in the interpreter shutdown process, *especially* the __main__ module. So, by the time "a" gets garbage-collected, other globals or modules may already have been wiped. Unfortunately, I don't think there's much we can do to improve this. The answer to your specific problem is to use the atexit module instead, since an atexit callback is guaranteed to be called with a normal execution environment, before it starts being garbage-collected. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 20:12:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 18:12:28 +0000 Subject: [issue21512] time module becomes None after raise SystemExit In-Reply-To: <1400176218.84.0.180838501812.issue21512@psf.upfronthosting.co.za> Message-ID: <1400177548.17.0.976111173378.issue21512@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: not a bug -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 20:19:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 May 2014 18:19:51 +0000 Subject: [issue21486] optimize v4 & v6 netmask parsing In-Reply-To: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> Message-ID: <3gV1Hp0Fb3z7Lkp@mail.python.org> Roundup Robot added the comment: New changeset 2158614e1607 by Antoine Pitrou in branch 'default': Issue #21486: Optimize parsing of netmasks in ipaddress.IPv4Network and ipaddress.IPv6Network. http://hg.python.org/cpython/rev/2158614e1607 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 20:21:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 May 2014 18:21:57 +0000 Subject: [issue21487] Assorted ipaddress performance improvements In-Reply-To: <1399925063.26.0.615670484521.issue21487@psf.upfronthosting.co.za> Message-ID: <3gV1LF1CrNz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 2711677cf874 by Antoine Pitrou in branch 'default': Issue #21487: Optimize ipaddress.summarize_address_range() and ipaddress.{IPv4Network,IPv6Network}.subnets(). http://hg.python.org/cpython/rev/2711677cf874 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 20:34:12 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 15 May 2014 18:34:12 +0000 Subject: [issue15809] 2.7 IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1400178852.52.0.317641493929.issue15809@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Idle 3.x has Martin's patch, except that the 'if' clause is merely commented out rather than removed. (Perhaps someone wanted to test the removal first. It should now be deleted.) My 2.7 Idle has Default Source Encoding ... [x] None. Since there is nothing for this in either config-main.def, I presume it is the default -- at least for Windows. But Martin says it is not relevant. 'Surprising' suggests that you think or know that doing the same in 2.7 might introduce other discrepancies from console behavior. I am reluctant to do that, though it is possible that it might make Idle *better* than the console. I would definitely be reluctant to do something more wide-ranging than your patch without extensive tests, and even that patch should have some tests, some of which pass now and continue to pass, and other that fail now and pass with the patch. Irdb said "As a Windows user, currently I can't print u'????' in interactive mode and get an "Unsupported characters in input" error because my default system encoding (cp1256) can't encode Russian.)" Idle 2.7 >>> u'????' Unsupported characters in input Console 2.7 >>> u'????' u'????' >>> u'????'[0] == '?' True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 20:40:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 May 2014 18:40:59 +0000 Subject: [issue20826] Faster implementation to collapse consecutive ip-networks In-Reply-To: <1393771140.68.0.719869740699.issue20826@psf.upfronthosting.co.za> Message-ID: <3gV1mB5dpQz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 8867874a2b7d by Antoine Pitrou in branch 'default': Issue #20826: Optimize ipaddress.collapse_addresses(). http://hg.python.org/cpython/rev/8867874a2b7d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 21:02:36 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 15 May 2014 19:02:36 +0000 Subject: [issue15809] 2.7 IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1400180556.46.0.48716755417.issue15809@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- nosy: -loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 21:05:45 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 19:05:45 +0000 Subject: [issue20826] Faster implementation to collapse consecutive ip-networks In-Reply-To: <1393771140.68.0.719869740699.issue20826@psf.upfronthosting.co.za> Message-ID: <1400180745.11.0.557528085632.issue20826@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've now committed this. exhuma, if you have any further observations or results, don't hesitate to post them! ---------- resolution: -> fixed stage: patch review -> commit review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 21:05:59 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 19:05:59 +0000 Subject: [issue21487] Assorted ipaddress performance improvements In-Reply-To: <1399925063.26.0.615670484521.issue21487@psf.upfronthosting.co.za> Message-ID: <1400180759.86.0.972248884247.issue21487@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 Thu May 15 21:06:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 19:06:11 +0000 Subject: [issue21486] optimize v4 & v6 netmask parsing In-Reply-To: <1399919085.99.0.439392773232.issue21486@psf.upfronthosting.co.za> Message-ID: <1400180771.23.0.380107518408.issue21486@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 Thu May 15 22:39:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 May 2014 20:39:47 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <3gV4PG5wMZz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 4621bb82ceec by Antoine Pitrou in branch '3.4': Issue #21364: remove recommendation of broken pattern. http://hg.python.org/cpython/rev/4621bb82ceec New changeset dbf728f9a2f0 by Antoine Pitrou in branch 'default': Issue #21364: remove recommendation of broken pattern. http://hg.python.org/cpython/rev/dbf728f9a2f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 22:40:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 20:40:42 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1400186442.59.0.0433761030719.issue21364@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report, Armin. I've removed that recommendation and changed the surrounding wording to insist that standard streams are always text streams. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 22:44:56 2014 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 15 May 2014 20:44:56 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1400186696.42.0.554658773365.issue21364@psf.upfronthosting.co.za> Armin Ronacher added the comment: To avoid further problems may I also recommend documenting how exactly people are supposed to wrap sys.stdout and so forth. Clearly putting a StringIO there is insufficient as StringIO does not have a buffer. Something like this maybe? import io buf = io.BytesIO() sys.stdout = io.TextIOWrapper(buf, encoding='utf-8', errors='strict', # or surrogate-escape as this is the default for stdout now? not sure line_buffering=True ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 22:47:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 20:47:13 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1400186696.42.0.554658773365.issue21364@psf.upfronthosting.co.za> Message-ID: <1400186830.2316.23.camel@fsol> Antoine Pitrou added the comment: > To avoid further problems may I also recommend documenting how exactly > people are supposed to wrap sys.stdout and so forth. Clearly putting > a StringIO there is insufficient as StringIO does not have a buffer. I would like to know of some situations where you want to write some code that accesses standard streams as binary *and* don't control the application setup (i.e. library code rather than application code). It seems to me that a library should take the binary streams as parameters rather than force the use of stdin/stdout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 23:24:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 21:24:38 +0000 Subject: [issue21513] speed up some ipaddress properties Message-ID: <1400189077.88.0.327979647169.issue21513@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Some properties on IPv4Address and IPv6Address instantiate one or several network objects each time they are computed. Instead these characteristic networks can be computed once and for all at module import. Patch attached. (note: the lru_cache() decorator seems to mitigate this in micro-benchmarks, but the common pattern is not to call .is_private on always the same address :-)) ---------- components: Library (Lib) files: ipaddr_props.patch keywords: patch messages: 218630 nosy: ncoghlan, pitrou, pmoody, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: speed up some ipaddress properties type: performance versions: Python 3.5 Added file: http://bugs.python.org/file35260/ipaddr_props.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 23:40:11 2014 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 15 May 2014 21:40:11 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1400190011.03.0.49957828122.issue21364@psf.upfronthosting.co.za> Armin Ronacher added the comment: > I would like to know of some situations where you want to write some > code that accesses standard streams as binary *and* don't control the > application setup (i.e. library code rather than application code). It > seems to me that a library should take the binary streams as parameters > rather than force the use of stdin/stdout. The same situations people wrapped streams before on python 2: * code.py users. Werkzeug's traceback system implements a remote python shell through it. * any system that wants to unittest shell scripts on a high level. * any system that wants to execute arbitrary python code and then capture whatever output it did. This is for instance what I see Sphinx users frequently do (or doctests) In fact, the reasons people wrap sys.stdout/sys.stderr on 2.x are the same reasons why people would do it on 3.x: they have arbitrary code they did not write and they want to capture what it does. Since you do not know if that is binary or text you need a stream object that behaves the same way as the default one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 23:50:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 May 2014 21:50:57 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1400190011.03.0.49957828122.issue21364@psf.upfronthosting.co.za> Message-ID: <1400190654.2316.27.camel@fsol> Antoine Pitrou added the comment: > The same situations people wrapped streams before on python 2: > > * code.py users. Werkzeug's traceback system implements a remote python > shell through it. > * any system that wants to unittest shell scripts on a high level. > * any system that wants to execute arbitrary python code and then > capture whatever output it did. This is for instance what I see > Sphinx users frequently do (or doctests) I see, I misunderstood you. You actually want to get back the bytes output of e.g. stdout, right? You could indeed use a TextIOWrapper wrapping a BytesIO object. Or of course another possibility is to do the encoding yourself, e.g. sys.stdout.getvalue().encode('utf-8', 'surrogateescape'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 23:52:31 2014 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 15 May 2014 21:52:31 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1400190751.0.0.342992765778.issue21364@psf.upfronthosting.co.za> Armin Ronacher added the comment: Pretty much, yes. Just that you probably want 'replace' instead. surrogate-escape does not do anything useful here I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 23:53:05 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 15 May 2014 21:53:05 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1400190785.35.0.537195403789.issue21364@psf.upfronthosting.co.za> R. David Murray added the comment: Note that in 3.4 we have contextlib.replace_stdout, but it doesn't give any examples of how to construct file-like objects that will work well with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 15 23:55:06 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 15 May 2014 21:55:06 +0000 Subject: [issue21364] Documentation Recommends Broken Pattern In-Reply-To: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za> Message-ID: <1400190906.49.0.0144709881219.issue21364@psf.upfronthosting.co.za> R. David Murray added the comment: I mean redirect_stdout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 02:43:00 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 16 May 2014 00:43:00 +0000 Subject: [issue21513] speed up some ipaddress properties In-Reply-To: <1400189077.88.0.327979647169.issue21513@psf.upfronthosting.co.za> Message-ID: <1400200980.92.0.47663952042.issue21513@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 02:46:32 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 16 May 2014 00:46:32 +0000 Subject: [issue21508] C API PyArg_ParseTuple doc is innacurate In-Reply-To: <1400078023.63.0.359608332224.issue21508@psf.upfronthosting.co.za> Message-ID: <1400201192.35.0.465995291459.issue21508@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Changing the docs isn't the main hurdle; the problem is that if we told people they could test == 1, rather than != 0, then new success return codes couldn't be added without a long period of warning. I don't think the convention is consistently 0 means success BTW. Frankly, 0 means success is just confusing in general (since it reverses the normal C convention, even if it agrees with the errno convention). bool is sadly out, since Python is forever stuck in 1990, and will never know the joys of C99. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 02:51:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 16 May 2014 00:51:00 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <3gV9z73V9Wz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset 0a6d51ccff54 by Terry Jan Reedy in branch '2.7': Issue #18104: revise docstrings, remove obsolete comments. http://hg.python.org/cpython/rev/0a6d51ccff54 New changeset 6d2982ff441f by Terry Jan Reedy in branch '3.4': Issue #18104: revise docstrings, remove obsolete comments. http://hg.python.org/cpython/rev/6d2982ff441f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 03:01:30 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 16 May 2014 01:01:30 +0000 Subject: [issue21507] set and frozenset constructor should use operator.length_hint to guess the size of the iterator In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400202090.74.0.0174382140536.issue21507@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Not sure how much that really helps. If I understand you correctly, it would be a memory optimization that would require a round of rehashing to use? If you wanted to make a change that got "guaranteed" better performance, you might add support for dict's dict_keys and dict_items objects (since those have the same uniqueness guarantees as a set or dict, and I could easily see someone creating sets from them to remove the link to the original dict). If you wanted to get crazy, you might add preallocation support for collections.abc abstract classes equivalent to the built-ins, specifically, Set, Mapping, KeysView and ItemsView. That's probably not a good idea though, since it ends up calling out to Python code more (slowing you down for the general case) and it's probably not as safe, since a user-defined implementation of those abstract classes might not strictly adhere to the same uniqueness or hashability contracts the built-ins provide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 03:41:58 2014 From: report at bugs.python.org (Alextp) Date: Fri, 16 May 2014 01:41:58 +0000 Subject: [issue21046] Document formulas used in statistics In-Reply-To: <1395630619.14.0.819197288528.issue21046@psf.upfronthosting.co.za> Message-ID: <1400204518.21.0.182578800312.issue21046@psf.upfronthosting.co.za> Alextp added the comment: @Ezio: of course, much of these funcs CANNOT be expressed as simple formulas. Only with some text. I shown example descriptions for almost all- above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 04:39:43 2014 From: report at bugs.python.org (akira) Date: Fri, 16 May 2014 02:39:43 +0000 Subject: [issue17909] Autodetecting JSON encoding In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za> Message-ID: <1400207983.09.0.241343275669.issue17909@psf.upfronthosting.co.za> akira added the comment: Both json standard (ECMA-404) [1] and the new json rfc 7159 [2] do not mention the encoding detection. [1] http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf [2] https://tools.ietf.org/html/rfc7159#section-8.1 >From the rfc: > JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encoding is UTF-8, and JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the maximum number of implementations; there are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32). Implementations MUST NOT add a byte order mark to the beginning of a JSON text. In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error. ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 06:20:11 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 04:20:11 +0000 Subject: [issue17909] Autodetecting JSON encoding In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za> Message-ID: <1400214011.78.0.403321149039.issue17909@psf.upfronthosting.co.za> Chris Rebert added the comment: I agree that the state of encoding detection in the new RFC seems unclear, given that the old RFC prefaced the part about the encoding detection with: > Since the first two characters of a JSON text will always be ASCII > characters But in the new RFC: > Appendix A. Changes from RFC 4627 [...] > o Changed the definition of "JSON text" so that it can be any JSON > value, removing the constraint that it be an object or array. Thus, > "?_?" whose 2nd character is decidedly non-ASCII, is now a valid JSON text (i.e. standalone JSON document). There seems to have been a thread about encoding detection in the RFC 7159 working group, but I don't have the time to read through it all: > Re: [Json] JSON: remove gap between Ecma-404 and IETF draft > http://www.ietf.org/mail-archive/web/json/current/msg01936.html It eventually leads to a dedicated sub-thread: > [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) > http://www.ietf.org/mail-archive/web/json/current/msg01959.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 06:31:09 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 04:31:09 +0000 Subject: [issue18820] json.dump() ignores its 'default' option when serializing dictionary keys In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za> Message-ID: <1400214669.31.0.637094412974.issue18820@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 06:32:14 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 04:32:14 +0000 Subject: [issue19361] Specialize exceptions thrown by JSON parser In-Reply-To: <1382527334.08.0.362620105205.issue19361@psf.upfronthosting.co.za> Message-ID: <1400214734.08.0.408989344027.issue19361@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 06:42:02 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 04:42:02 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1400215322.42.0.684496825286.issue13212@psf.upfronthosting.co.za> Chris Rebert added the comment: Note that, per the new JSON RFC 7159 (https://tools.ietf.org/html/rfc7159 ), top-level non-collection values are now de-jure permissible in JSON: > Appendix A. Changes from RFC 4627 > o Changed the definition of "JSON text" so that it can be any JSON > value, removing the constraint that it be an object or array. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 06:45:26 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 04:45:26 +0000 Subject: [issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks In-Reply-To: <1400099572.93.0.56172954955.issue21509@psf.upfronthosting.co.za> Message-ID: <1400215526.97.0.749832616312.issue21509@psf.upfronthosting.co.za> Chris Rebert added the comment: The new JSON RFC now at least mentions BOM handling: https://tools.ietf.org/html/rfc7159#section-8.1 : > Implementations MUST NOT add a byte order mark to the beginning of a > JSON text. In the interests of interoperability, implementations > that parse JSON texts MAY ignore the presence of a byte order mark > rather than treating it as an error. ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 06:52:48 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 04:52:48 +0000 Subject: [issue21514] update json module docs in light of RFC 7159 & ECMA-404 Message-ID: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za> New submission from Chris Rebert: json module docs: https://docs.python.org/3/library/json.html New superseding JSON RFC: https://tools.ietf.org/html/rfc7159 Errata to the new RFC: http://www.rfc-editor.org/errata_search.php?rfc=7159 ECMA-404: http://www.ecma-international.org/publications/standards/Ecma-404.htm These updated specs are of particular relevance to the Standard Compliance section of the json module docs. There are also a bunch of new interoperability notes in the RFC that could probably bear repeating in the module's docs. ---------- assignee: docs at python components: Documentation messages: 218644 nosy: cvrebert, docs at python priority: normal severity: normal status: open title: update json module docs in light of RFC 7159 & ECMA-404 versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 07:13:53 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 05:13:53 +0000 Subject: [issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons In-Reply-To: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za> Message-ID: <1400217233.97.0.421780384284.issue21401@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 07:16:59 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 05:16:59 +0000 Subject: [issue1043134] Add preferred extensions for MIME types Message-ID: <1400217419.89.0.74956600561.issue1043134@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 07:51:44 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 05:51:44 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1400219504.93.0.951183508345.issue1521950@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 07:54:47 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 05:54:47 +0000 Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is confusing In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za> Message-ID: <1400219687.92.0.314003658909.issue13826@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 07:55:22 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 16 May 2014 05:55:22 +0000 Subject: [issue13197] subprocess: move shell arguments to a separate keyword param In-Reply-To: <1318851671.68.0.276363356463.issue13197@psf.upfronthosting.co.za> Message-ID: <1400219722.82.0.197080789598.issue13197@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 09:15:07 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 16 May 2014 07:15:07 +0000 Subject: [issue21514] update json module docs in light of RFC 7159 & ECMA-404 In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za> Message-ID: <1400224507.86.0.508952633642.issue21514@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, pitrou, rhettinger stage: -> needs patch type: -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 09:25:36 2014 From: report at bugs.python.org (Abhilash Raj) Date: Fri, 16 May 2014 07:25:36 +0000 Subject: [issue634412] RFC 2387 in email package Message-ID: <1400225136.75.0.899170754114.issue634412@psf.upfronthosting.co.za> Abhilash Raj added the comment: I would like to work on this issue, but I would need a little help to start working on this feature. ---------- nosy: +abhilash.raj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 09:50:16 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 16 May 2014 07:50:16 +0000 Subject: [issue21046] Document formulas used in statistics In-Reply-To: <1395630619.14.0.819197288528.issue21046@psf.upfronthosting.co.za> Message-ID: <1400226616.12.0.166695737821.issue21046@psf.upfronthosting.co.za> Ezio Melotti added the comment: Do you want to propose a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 10:07:25 2014 From: report at bugs.python.org (Tal Einat) Date: Fri, 16 May 2014 08:07:25 +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: <1400227645.07.0.575729673813.issue20177@psf.upfronthosting.co.za> Tal Einat added the comment: Regarding the handling of time_t arguments which can be None, I agree that the second version (without custom convertors) is simpler and clearer while having no disadvantage that I can see. I'd like to review the rest of the patches, but you mention changes to the AC policy regarding 3.4 and 3.5 and I can't find a reference to these changes or to the new policy. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 11:03:06 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 16 May 2014 09:03:06 +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: <1400230986.49.0.459496624556.issue20177@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 11:17:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 May 2014 09:17:21 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? Message-ID: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> New submission from STINNER Victor: Linux 3.11 introduced a new file flag "O_TMPFILE". The flag is exposed in Python, see the issue #18673. "O_TMPFILE is a new open(2)/openat(2) flag that makes easier the creation of secure temporary files. Files opened with the O_TMPFILE flag are created but they are not visible in the filesystem. And as soon as they are closed, they get deleted - just as a file you would have opened and unlinked." http://kernelnewbies.org/Linux_3.11#head-8be09d59438b31c2a724547838f234cb33c40357 Does it make sense to use this flag in tempfile.TemporaryFile? Attached patch is a work-in-progress patch for tempfile. > if hasattr(_os, 'O_TMPFILE'): > _O_TMPFILE = _os.O_TMPFILE > elif _sys.platform == 'linux': > __O_TMPFILE = 0o20000000 > _O_TMPFILE = (__O_TMPFILE | _os.O_DIRECTORY) The second if should be removed. I used it because my Linux kernel (3.14) supports the flag, but the constant is not defined yet in C headers of my C library (glibc 2.18). > flags = (flags | _O_TMPFILE) & ~_os.O_CREAT O_CREAT is incompatible with O_TMPFILE. Bonus point of the flag: no need to compute a random name! Just pass the temporary directory. To do: test the patch on Linux < 3.11 to see how the flag is interpreted. If the flag is ignored, we open the directory in write mode! That's insafe. If the flag raises an error, we should fallback to the current implementation and remember that the flag is not supported. I implemented something similar for O_CLOEXEC and SOCK_CLOEXEC flags (PEP 433). ---------- files: tempfile_o_tmpfile.patch keywords: patch messages: 218648 nosy: haypo, neologix priority: normal severity: normal status: open title: Use Linux O_TMPFILE flag in tempfile.TemporaryFile? versions: Python 3.5 Added file: http://bugs.python.org/file35261/tempfile_o_tmpfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 11:34:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 May 2014 09:34:47 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400232887.54.0.873241283241.issue21515@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think we can use this by default, or it will break the expected semantics of temporary files under Unix (visible by other processes). ---------- nosy: +georg.brandl, ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 11:47:35 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 May 2014 09:47:35 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400233655.44.0.800841081169.issue21515@psf.upfronthosting.co.za> STINNER Victor added the comment: "I don't think we can use this by default, or it will break the expected semantics of temporary files under Unix (visible by other processes)." I proposed to change TemporaryFile, not NamedTemporaryFile. Do you mean that other processes are supposed to have access to the temporary file descriptor? Access through /proc/pid/fd/? O_TMPFILE should increase the security because there is no more race condition between os.open() and os.unlink() (window where an attack can access the file). My patch uses O_EXCL. It makes possible to use linkat() to create a path for the temporary file (I didn't try it, but I read that it's possible). I don't know if using O_EXCL should be the default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 12:17:09 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 16 May 2014 10:17:09 +0000 Subject: [issue21046] Document formulas used in statistics In-Reply-To: <1400226616.12.0.166695737821.issue21046@psf.upfronthosting.co.za> Message-ID: <20140516101650.GP4273@ando> Steven D'Aprano added the comment: On Fri, May 16, 2014 at 07:50:16AM +0000, Ezio Melotti wrote: > Do you want to propose a patch? I'm really not sure that I agree with this request. I'm currently sitting on the fence, undecided, about 60% against and 40% in favour of explicitly documenting the formulae. This is not Mathworld or Wikipedia, and it is easy to google for "variance" to find out what it means. This request orginally came from somebody who claimed he didn't know what the functions were from the names (mean, median, variance) but would recognise them from the formulae. Given how hard it is to accurately portray mathematical formulae in plain text, and how many different versions of the mathematical formulae there are, I don't think that will apply to very many people. There's no good way to write mathematical functions *accurately* in ASCII text. I can write mean(L) = sum(L)/len(L), for example, that's quite trivial. But it's not the usual mathematical formula. If the OP doesn't recognise the name "mean", will he recognise that non-standard formula? Should the docs include ? = ?x?n? But even that's not quite accurate -- where's the subscript on the x? The reader needs to understand the formula, and they aren't going to get that here. They probably have to go read Mathworld or Wikipedia regardless. The problem is compounded with variance. Which of these should we write? ?? = ?(x - ?)? ? n s? = ?x? ? n - ?? s[n]? = ?(x - a)? ? n Var(X) = E[X-?)?] Var(X) = E[X?] - (E[X])? or something else? What do other statistics packages do? I wouldn't want to do *less* -- if it is common for other stats packages to show the formula, then I would agree we should do the same. R doesn't seem to do so: http://stat.ethz.ch/R-manual/R-devel/library/base/html/mean.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 12:44:40 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 16 May 2014 10:44:40 +0000 Subject: [issue21046] Document formulas used in statistics In-Reply-To: <1395630619.14.0.819197288528.issue21046@psf.upfronthosting.co.za> Message-ID: <1400237080.08.0.807491197947.issue21046@psf.upfronthosting.co.za> Ezio Melotti added the comment: >From msg214692 it seems to me that Alex wants "Python-friendly" formulas or examples, rather than mathematical formulas. Most functions seems to already have them, so I was asking for a patch to get a better idea of which functions he thinks should be improved and how. As an example, itertools docs have simple "formulas" explaining what the function does and an example in the table at the top, and (possibly approximate) Python equivalents for most of the functions: https://docs.python.org/dev/library/itertools.html While the Python equivalent are probably not needed here, some simple formulas/examples might be OK, but I would have to see what exactly Alex is proposing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 13:21:10 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 May 2014 11:21:10 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400239270.73.0.451510847296.issue21515@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I proposed to change TemporaryFile, not NamedTemporaryFile. Ah, sorry. Then it sounds ok. (I couldn't find any documentation for O_TMPFILE, though) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 13:25:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 May 2014 11:25:09 +0000 Subject: [issue21507] set and frozenset constructor should use operator.length_hint to guess the size of the iterator In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400239509.55.0.154907732277.issue21507@psf.upfronthosting.co.za> Antoine Pitrou added the comment: AFAIU, Lev merely posted this because he feared it might be indicative of a bug. Since it isn't a bug but the by-product of a feature, I propose to close this issue as "not a bug". Regardless, thank you for posting this report! We appreciate the concern. ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 14:01:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 May 2014 12:01:46 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400241706.03.0.38493678506.issue13916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which tests encoding name with "cp65001" instead of "CP_UTF8". I can't test on Windows and don't know which of two patches are correct. ---------- Added file: http://bugs.python.org/file35262/surrogatepass_cp65001.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 14:16:58 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Fri, 16 May 2014 12:16:58 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1400242618.13.0.953014247069.issue21027@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Attached the new version of the patch which removes the resource warnings. Raymond, I disagree on certain points. `difflib -m` does help the development, especially for platforms where there aren't many readily available alternatives (like Windows). I gave an example for this in my first message, where you can't modify the PATH, nor install additional software. Also, you say that this should remain in tools as a demo. Wouldn't be better to have that demo well tested in stdlib and in a place where you can easy access it? This way, the user doesn't have to reimplement the wheel everytime he needs the differences between two files. And we are not competing with well developed, tested tools. By this argument, having `-m zipfile` and `-m tarfile` is redundant, because we can always use zip and tar instead. ---------- Added file: http://bugs.python.org/file35263/issue21027_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 14:32:42 2014 From: report at bugs.python.org (Glenn Langford) Date: Fri, 16 May 2014 12:32:42 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1400243562.6.0.886330474783.issue13299@psf.upfronthosting.co.za> Glenn Langford added the comment: In abstract, I like the namedtuple interface for sqlite3 as well. One caution is that the approach suggested at http://peter-hoffmann.com/2010/python-sqlite-namedtuple-factory.html can have a dramatic impact on performance. For one DB-intensive application, I experienced 20+ seconds run time with the row factory (under 3.4), versus sub second without (identified with cProfile). Many thousands of calls to namedtuple_factory were not good. :) ---------- nosy: +glangford _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 14:48:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 16 May 2014 12:48:58 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <3gVTvZ0vpnz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 8ee2b73cda7a by Victor Stinner in branch 'default': Issue #13916: Fix surrogatepass error handler on Windows http://hg.python.org/cpython/rev/8ee2b73cda7a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 14:54:46 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 May 2014 12:54:46 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400244886.39.0.688509633686.issue13916@psf.upfronthosting.co.za> STINNER Victor added the comment: > But an exception reports about CP_UTF8. Oh, that's my fault! And it is a bug: "CP_UTF8" is the Windows constant, but it is not a valid Python codec name. Attached patch cp_encoding_name.patch fixes this issue. I don't think that Py_LOWER() is needed because the encoding name of Unicode errors from the code page codec is "cpXXX". It cannot be "CPXXX", except if you pass create manually an Unicode error exception. What do you think? Py_LOWER or not? ---------- Added file: http://bugs.python.org/file35264/cp_encoding_name.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 14:55:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 May 2014 12:55:51 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400244951.11.0.134859155619.issue21515@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like O_TMPFILE is supported by tmpfs (3.11), ext3 (3.11), ext4 (3.11), XFS (3.15). It looks like BTRFS will also support the O_TMPFILE: https://btrfs.wiki.kernel.org/index.php/Project_ideas#Implement_O_TMPFILE_support -- It looks like os.open() fails with OSError(95, 'Operation not supported') if the filesystem of the directory doesn't support TMPFILE. In this case, a fallback to the current implementation should be enough. I don't think that we need to remember that the directory doesn't support TMPFILE. The directory may be on a different filesystem at the next call. haypo at smithers$ ~/prog/python/default/python Python 3.5.0a0 (default:5e98a50e0f55, May 16 2014, 10:44:10) >>> import tempfile >>> tempfile._O_TMPFILE 4259840 >>> f=tempfile.TemporaryFile(dir='.') Traceback (most recent call last): File "", line 1, in File "/home/haypo/prog/python/default/Lib/tempfile.py", line 507, in TemporaryFile fd = _os.open(dir, flags, 0o600) OSError: [Errno 95] Operation not supported: '.' haypo at smithers$ df . Sys. de fichiers Taille Utilis? Dispo Uti% Mont? sur 192.168.0.42:/test 96G 9,1G 83G 10% /home/haypo/nfs ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 15:08:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 May 2014 13:08:03 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400245683.82.0.0577063821098.issue21515@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like open() ignores O_TMPFILE (0o20000000) on old Linux kernels. Test on Linux 3.2: >>> fd=os.open("/tmp", os.O_RDWR | O_TMPFILE, 0o600) Traceback (most recent call last): File "", line 1, in OSError: [Errno 21] Is a directory: '/tmp' >>> fd=os.open("/tmp", os.O_RDWR | os.O_DIRECTORY, 0o600) Traceback (most recent call last): File "", line 1, in OSError: [Errno 21] Is a directory: '/tmp' So we should catch OSError(21, "Is a directory: '/tmp'") and fallback to the current implementation (random name, unlink), and remember that the kernel version is too old. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 15:53:37 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 16 May 2014 13:53:37 +0000 Subject: [issue21047] html.parser.HTMLParser: convert_charrefs should become True by default In-Reply-To: <1395638238.78.0.969546304297.issue21047@psf.upfronthosting.co.za> Message-ID: <1400248417.82.0.97832821331.issue21047@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch to set the default "convert_charrefs" value to True (with documentation and whatsnew updates). ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review Added file: http://bugs.python.org/file35265/issue21047.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 16:25:15 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 16 May 2014 14:25:15 +0000 Subject: [issue21047] html.parser.HTMLParser: convert_charrefs should become True by default In-Reply-To: <1395638238.78.0.969546304297.issue21047@psf.upfronthosting.co.za> Message-ID: <1400250315.6.0.594422745848.issue21047@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 16:40:35 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 16 May 2014 14:40:35 +0000 Subject: [issue634412] RFC 2387 in email package Message-ID: <1400251235.97.0.0769164724131.issue634412@psf.upfronthosting.co.za> R. David Murray added the comment: There is some support for this in the new email policies. Take a look at the new examples in the 3.4 email documentation in particular. The additional thing I would like to see is support in the content manager that recognizes multipart/related and makes it easy to manage one. I have to find time to look at it again myself before I can provide my ideas of what the API should be. Maybe you could take a look at the docs and examples and how the contentmanager works, and see if you have thoughts or questions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 16:40:49 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 16 May 2014 14:40:49 +0000 Subject: [issue634412] RFC 2387 in email package Message-ID: <1400251249.41.0.937024212686.issue634412@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 16:45:36 2014 From: report at bugs.python.org (Thomas Heller) Date: Fri, 16 May 2014 14:45:36 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on readonly directories (Windows) Message-ID: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za> New submission from Thomas Heller: On Windows, pathlib.Path(...).is_dir() crashes on readonly directories while os.path.isdir(...) works fine. Example on Windows7: Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:24:06) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os.path, pathlib >>> os.path.isdir("c:\\Users\\admin") True >>> pathlib.Path("c:\\Users\\admin").is_dir() Traceback (most recent call last): File "", line 1, in File "C:\Python34\lib\pathlib.py", line 1197, in is_dir return S_ISDIR(self.stat().st_mode) File "C:\Python34\lib\pathlib.py", line 1045, in stat return self._accessor.stat(self) File "C:\Python34\lib\pathlib.py", line 323, in wrapped return strfunc(str(pathobj), *args) PermissionError: [WinError 5] Zugriff verweigert: 'c:\\Users\\admin' >>> This probably affects other methods that call stat() internally. ---------- components: Library (Lib) messages: 218664 nosy: theller priority: normal severity: normal status: open title: pathlib.Path(...).is_dir() crashes on readonly directories (Windows) type: crash versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 16:52:22 2014 From: report at bugs.python.org (Thomas Heller) Date: Fri, 16 May 2014 14:52:22 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on some directories (Windows) In-Reply-To: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za> Message-ID: <1400251942.21.0.780008806962.issue21516@psf.upfronthosting.co.za> Thomas Heller added the comment: Well, not 'readonly' directories but directories where the user has no access rights. I corrected the title of this bug. ---------- title: pathlib.Path(...).is_dir() crashes on readonly directories (Windows) -> pathlib.Path(...).is_dir() crashes on some directories (Windows) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 16:57:31 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 16 May 2014 14:57:31 +0000 Subject: [issue21503] Use test_both() consistently throughout test_importlib In-Reply-To: <1400027129.06.0.740257439061.issue21503@psf.upfronthosting.co.za> Message-ID: <1400252251.54.0.296357441705.issue21503@psf.upfronthosting.co.za> Brett Cannon added the comment: I see you noticed my shift in strategy after I realized part way through a cleaner way of doing things. =) LGTM I don't love the formatting of the test_both() lines, but I think that one is just an aesthetic thing that will never make people happy -- weird line wrapping or really long lines -- so just leave it as-is in your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 17:10:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 May 2014 15:10:23 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400245683.82.0.0577063821098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400253021.2317.0.camel@fsol> Antoine Pitrou added the comment: > So we should catch OSError(21, "Is a directory: '/tmp'") and fallback > to the current implementation (random name, unlink), and remember that > the kernel version is too old. Just catch any OSError? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 17:19:15 2014 From: report at bugs.python.org (Glenn Langford) Date: Fri, 16 May 2014 15:19:15 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1400253555.38.0.34666238848.issue13299@psf.upfronthosting.co.za> Glenn Langford added the comment: ...if I understand the proposed caching scheme, then repeated executions of the query SELECT a,b,c FROM table would result in cache hits, since the column names remain the same. I'm guessing this would resolve the performance problem in the app I saw, but it would be good to verify that performance is broadly similar with/without named tuples. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 17:19:55 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 16 May 2014 15:19:55 +0000 Subject: [issue21503] Use test_both() consistently throughout test_importlib In-Reply-To: <1400252251.54.0.296357441705.issue21503@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > I don't love the formatting of the test_both() lines, but I think that one is just an aesthetic thing that will never make people happy -- weird line wrapping or really long lines -- so just leave it as-is in your patch. Yeah, I went with the formatting that I did because I found it a little easier to follow (stronger separation between elements) and visually distinguish in the code. It was also a little easier to grep/search for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 17:20:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 May 2014 15:20:53 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400253653.52.0.932524063843.issue21515@psf.upfronthosting.co.za> STINNER Victor added the comment: > Just catch any OSError? If possible, I would prefer to not retry O_TMPFILE each time if the kernel version does not support the flag. Pseudo-code: -- if o_tmpfile_supported: try: fd = os.open(dir, os.O_TMPFILE | ...) except IsADirectoryError: # Linux kernel older than 3.11 ignores O_TMPFILE flag o_tmpfile_supported = False except OSError: # the filesystem doesn't support O_TMPFILE pass else: return io.open(fd, ...) # fallback to unsafe but portable implementation # current code generating a name and using unlink --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 17:29:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 May 2014 15:29:19 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400253653.52.0.932524063843.issue21515@psf.upfronthosting.co.za> Message-ID: <1400254156.2317.1.camel@fsol> Antoine Pitrou added the comment: > > Just catch any OSError? > > If possible, I would prefer to not retry O_TMPFILE each time if the kernel version does not support the flag. How likely it is to have a glibc flag that's not supported by the kernel (on a normal setup, not a self-compiled distro)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 17:30:22 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 16 May 2014 15:30:22 +0000 Subject: [issue21503] Use test_both() consistently throughout test_importlib In-Reply-To: <1400027129.06.0.740257439061.issue21503@psf.upfronthosting.co.za> Message-ID: <1400254222.96.0.188366637669.issue21503@psf.upfronthosting.co.za> Eric Snow added the comment: FWIW, this change was motivated by the importlib backport (I found some time to work on it). The import_importlib()/test_both() approach definitely makes backporting the tests easier (thanks for that). BTW, thanks for also consolidating the various test_importlib util modules. That also helped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 17:56:25 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 16 May 2014 15:56:25 +0000 Subject: [issue19610] setup.py does not allow a tuple for classifiers In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1400255785.12.0.81577323183.issue19610@psf.upfronthosting.co.za> Berker Peksag added the comment: > A patch to detect bad type for classifiers in the check command would > also be acceptable for 3.5, or to catch it earlier, a check in the > Distribution class. Thanks for the idea, ?ric. New patch attached. ---------- stage: needs patch -> patch review versions: -Python 2.7, Python 3.4 Added file: http://bugs.python.org/file35266/issue19610_catch_distribution.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 18:49:51 2014 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 16 May 2014 16:49:51 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on some directories (Windows) In-Reply-To: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za> Message-ID: <1400258991.23.0.425556836775.issue21516@psf.upfronthosting.co.za> Matthew Barnett added the comment: I wouldn't call it a crash. It's an exception. ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 18:55:34 2014 From: report at bugs.python.org (akira) Date: Fri, 16 May 2014 16:55:34 +0000 Subject: [issue6445] Add check parameter to subprocess.Popen.communicate In-Reply-To: <1247131793.49.0.582429022768.issue6445@psf.upfronthosting.co.za> Message-ID: <1400259334.04.0.84503599406.issue6445@psf.upfronthosting.co.za> akira added the comment: subprocess.check_output() could be used in "communicate() + check process exit status" one-liners. It returns child process output (stdout) and raises an exception if the returncode is not zero. It is available since Python 2.7 (3.1) If you don't want to raise an error for non-zero exit status; you could define a helper function: def status_output(*args, **kwargs): try: return 0, check_output(*args, **kwargs) except CalledProcessError as e: return e.returncode, e.output > The CalledProcessError requires a cmd argument, which means also adding a cmd member to Popen objects. Popen.args is available since Python 3.3, see issue #21353 ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 19:45:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 16 May 2014 17:45:12 +0000 Subject: [issue21503] Use test_both() consistently throughout test_importlib In-Reply-To: <1400027129.06.0.740257439061.issue21503@psf.upfronthosting.co.za> Message-ID: <3gVcTM6Y94z7LjS@mail.python.org> Roundup Robot added the comment: New changeset 34d65746d5ca by Eric Snow in branch 'default': Issue #21503: Use test_both() consistently in test_importlib. http://hg.python.org/cpython/rev/34d65746d5ca ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 19:46:12 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 16 May 2014 17:46:12 +0000 Subject: [issue21503] Use test_both() consistently throughout test_importlib In-Reply-To: <1400027129.06.0.740257439061.issue21503@psf.upfronthosting.co.za> Message-ID: <1400262372.69.0.145191042781.issue21503@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 20:01:13 2014 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 16 May 2014 18:01:13 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on some directories (Windows) In-Reply-To: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za> Message-ID: <1400263273.22.0.429843893115.issue21516@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 20:41:34 2014 From: report at bugs.python.org (Trip Volpe) Date: Fri, 16 May 2014 18:41:34 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400265694.68.0.54009110654.issue2506@psf.upfronthosting.co.za> Changes by Trip Volpe : ---------- nosy: +Trip.Volpe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 20:54:23 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 May 2014 18:54:23 +0000 Subject: [issue21468] NNTPLib connections become corrupt after long periods of activity In-Reply-To: <1399738998.21.0.285283528599.issue21468@psf.upfronthosting.co.za> Message-ID: <1400266463.57.0.409239650425.issue21468@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 20:56:20 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 May 2014 18:56:20 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400266580.71.0.414262180712.issue21477@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Idle: improve idle_test,htest -> Idle: improve idle_test.htest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 20:58:22 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 May 2014 18:58:22 +0000 Subject: [issue21484] More clarity needed about difference between "x += e" and "x = x + e" In-Reply-To: <1399913881.84.0.586979222354.issue21484@psf.upfronthosting.co.za> Message-ID: <1400266702.78.0.375621435547.issue21484@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 20:59:45 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 May 2014 18:59:45 +0000 Subject: [issue21495] Sane default for logging config In-Reply-To: <1399987976.18.0.00182198684039.issue21495@psf.upfronthosting.co.za> Message-ID: <1400266785.94.0.686939124529.issue21495@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- components: +Library (Lib) stage: -> test needed type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 21:06:22 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 May 2014 19:06:22 +0000 Subject: [issue21495] Sane default for logging config In-Reply-To: <1399987976.18.0.00182198684039.issue21495@psf.upfronthosting.co.za> Message-ID: <1400267182.1.0.407781322121.issue21495@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Moving discussion to python-ideas was the right thing to do. I am closing this for the present as there is no concrete accepted idea to write a patch for. Thomas, if that changes, you can re-open. ---------- nosy: +terry.reedy resolution: -> later stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 21:16:40 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 May 2014 19:16:40 +0000 Subject: [issue21511] Thinko in Lib/quopri.py In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za> Message-ID: <1400267800.29.0.586030179786.issue21511@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Senthil, David, I hope one of you understands this. I looks like a minor fix. ---------- nosy: +orsenthil, r.david.murray, terry.reedy stage: -> test needed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 21:22:01 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 16 May 2014 19:22:01 +0000 Subject: [issue21511] Thinko in Lib/quopri.py In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za> Message-ID: <1400268121.68.0.0562478872175.issue21511@psf.upfronthosting.co.za> R. David Murray added the comment: We should resolve issue 18022 before we decide how to "fix" this. ---------- dependencies: +Inconsistency between quopri.decodestring() and email.quoprimime.decode() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 21:43:12 2014 From: report at bugs.python.org (Jean-Paul Calderone) Date: Fri, 16 May 2014 19:43:12 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400269392.07.0.355577345746.issue2506@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 21:49:26 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Fri, 16 May 2014 19:49:26 +0000 Subject: [issue21511] Thinko in Lib/quopri.py In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za> Message-ID: <1400269766.79.0.791978902142.issue21511@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: This is minor issue indeed, uncovered when trying to run quopri.py with MicroPython http://micropython.org . I now worked around this on MicroPython side, but otherwise I set to report any issues I've seen with MicroPython porting, in the hope that MicroPython effort is good member of Python community. If the original report is unclear, feel free to point to any vague spots, and I'll elaborate on it. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 22:05:02 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 16 May 2014 20:05:02 +0000 Subject: [issue21511] Thinko in Lib/quopri.py In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za> Message-ID: <1400270702.52.0.492492561983.issue21511@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks. It's very clear. What isn't clear is if the line should be made to work as apparently intended, or removed :) (My guess at this point without re-reading the RFCs is that it should be removed.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 22:08:49 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 16 May 2014 20:08:49 +0000 Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za> Message-ID: <1400270929.21.0.675627144964.issue21112@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 22:10:11 2014 From: report at bugs.python.org (eryksun) Date: Fri, 16 May 2014 20:10:11 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on some directories (Windows) In-Reply-To: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za> Message-ID: <1400271011.17.0.797428545598.issue21516@psf.upfronthosting.co.za> eryksun added the comment: nt._isdir calls GetFileAttributes. CPython's stat implementation calls CreateFile to get a handle to pass to GetFileInformationByHandle. If it can't get a valid handle, it falls back to calling FindFirstFileW to get the file information, but only for ERROR_SHARING_VIOLATION. Shouldn't this include ERROR_ACCESS_DENIED? win32_xstat_impl_w http://hg.python.org/cpython/file/04f714765c13/Modules/posixmodule.c#l1742 ---------- nosy: +eryksun type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 16 23:05:43 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 16 May 2014 21:05:43 +0000 Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za> Message-ID: <1400274343.23.0.398029708732.issue21112@psf.upfronthosting.co.za> Larry Hastings added the comment: Berker: do you consider your diff ready to go in, or is it an "early" diff (like a work-in-progress)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 00:37:47 2014 From: report at bugs.python.org (eryksun) Date: Fri, 16 May 2014 22:37:47 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on some directories (Windows) In-Reply-To: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za> Message-ID: <1400279867.63.0.580532949055.issue21516@psf.upfronthosting.co.za> eryksun added the comment: > but only for ERROR_SHARING_VIOLATION. Shouldn't this > include ERROR_ACCESS_DENIED? To clarify, I meant that I think it should fall back to using FindFirstFile for either error, not that ERROR_SHARING_VIOLATION somehow includes ERROR_ACCESS_DENIED. (Proofreading? What's that?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 02:41:50 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 17 May 2014 00:41:50 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400287310.0.0.638179878815.issue7776@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I am glad that issues with 3rdparty libs which dependent on the previous wrong behavior has been resolved. As indicated previously, I think, it makes sense to have this in 2.7 as well. I created a patch and tested it 2.7 and it is all good. I plan to commit it before the next 2.7 update (which should be tomorrow). ---------- priority: release blocker -> high Added file: http://bugs.python.org/file35267/7776-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 03:17:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 May 2014 01:17:12 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on some directories (Windows) In-Reply-To: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za> Message-ID: <1400289432.5.0.122056227105.issue21516@psf.upfronthosting.co.za> Antoine Pitrou added the comment: When you say "os.path.isdir(...) works fine", you mean it's returning False? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 03:18:04 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 May 2014 01:18:04 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on some directories (Windows) In-Reply-To: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za> Message-ID: <1400289484.29.0.29692944418.issue21516@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Apparently os.path.isdir() has been special-cased under Windows to use other, native APIs (see #11583). ---------- nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 03:52:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 May 2014 01:52:00 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <3gVqH40LTQz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 568041fd8090 by Senthil Kumaran in branch '2.7': Backport Fix for Issue #7776: Fix ``Host:'' header and reconnection when using http.client.HTTPConnection.set_tunnel(). http://hg.python.org/cpython/rev/568041fd8090 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 03:53:59 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 17 May 2014 01:53:59 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400291639.15.0.827042334564.issue7776@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is fixed in 2.7 as well here (changeset 568041fd8090). We shall close this ticket after @dstufft pulls in the updated pip for 3.4 Thanks! ---------- priority: high -> release blocker versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 03:59:07 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 17 May 2014 01:59:07 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400254156.2317.1.camel@fsol> Message-ID: Nick Coghlan added the comment: Reasonably common, I believe. For example, Red Hat ships a Developer Toolset, so you may be building with an up to date gcc on RHEL 6 or 7, but still support deploying against the older kernel in RHEL 5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 04:05:43 2014 From: report at bugs.python.org (Donald Stufft) Date: Sat, 17 May 2014 02:05:43 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400292343.26.0.75032522664.issue7776@psf.upfronthosting.co.za> Donald Stufft added the comment: Requests has been released and I've pulled it into the pip tree. I'll be releasing tonight probably, or maybe tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 04:06:27 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 17 May 2014 02:06:27 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400292387.83.0.262616722607.issue21515@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 04:06:44 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 17 May 2014 02:06:44 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400292404.88.0.264038840945.issue7776@psf.upfronthosting.co.za> Larry Hastings added the comment: I tag 3.4.1 final in less than 24 hours. I really would prefer that the embedded pip not contain such, uh, fresh software. But let's try it and hope for the best. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 04:09:05 2014 From: report at bugs.python.org (Donald Stufft) Date: Sat, 17 May 2014 02:09:05 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400292545.67.0.252286575158.issue7776@psf.upfronthosting.co.za> Donald Stufft added the comment: Well you're the RM Larry :) I'll do whatever you think is best. I would greatly prefer it if the pip shipped with CPython 3.4.1 wasn't broken with proxies. I think the choices are 1) Ship it with the new pip, I can give a delta of the differences if that is helpful. 2) Roll back the patch that broke the behavior 3) Ship with broken pip + proxy behavior Whichever you think is the better option is fine with me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 04:42:11 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 17 May 2014 02:42:11 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400294531.26.0.913951023063.issue7776@psf.upfronthosting.co.za> Larry Hastings added the comment: Yeah, I'd like to see the diff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 04:53:11 2014 From: report at bugs.python.org (Donald Stufft) Date: Sat, 17 May 2014 02:53:11 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400295191.57.0.499587692258.issue7776@psf.upfronthosting.co.za> Donald Stufft added the comment: I just released pip 1.5.6. The ensurepip package currently has 1.5.4 inside of it. 1.5.5 has been out for 2 weeks or so and there haven't been any reported regressions. The only difference between 1.5.5 and 1.5.6 is that requests has been upgraded. Here's the changelog items for 1.5.5 and 1.5.6: https://github.com/pypa/pip/blob/master/CHANGES.txt#L1-L20 Here's the diff from 1.5.5 to 1.5.6: https://github.com/pypa/pip/compare/1.5.5...1.5.6 Here's the diff from 1.5.4 to 1.5.6: https://github.com/pypa/pip/compare/1.5.4...1.5.6 If you want me to update the bundled ensurepip let me know what branch I should do it on. I'm going to go ahead and do it for 3.5 though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 05:07:04 2014 From: report at bugs.python.org (Donald Stufft) Date: Sat, 17 May 2014 03:07:04 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400296024.34.0.906601745216.issue7776@psf.upfronthosting.co.za> Donald Stufft added the comment: Just FYI, I upgraded setuptools and pip in 3.5: http://hg.python.org/cpython/rev/acb5cc616052 http://hg.python.org/cpython/rev/308ff6a5ce67 If you decide to go that way dunno if you can just cherry pick or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 05:34:21 2014 From: report at bugs.python.org (Andrew Harrington) Date: Sat, 17 May 2014 03:34:21 +0000 Subject: [issue21517] installer Python default setting fails with mac Python Launcher Message-ID: <1400297661.67.0.596645362447.issue21517@psf.upfronthosting.co.za> New submission from Andrew Harrington: I installed Python 3.4 on my Mac (OSX 10.9.2), with the option to make python 3.4 my default python3, so which python3 prints /Library/Frameworks/Python.framework/Versions/3.4/bin/python3 which is fine. A terminal then brings up python 3.4, fine. However the Python Launcher uses /usr/bin/python3 and the Python 3,4 install script does not change that. (I had it pointing to python 3.3 before, and it remained that way after installing Python 3.4.) Since the Python Launcher is a pretty standard way to start Python, this would be nice to fix, or at least in the installer have a comment that the something more needs to be set! ---------- assignee: ronaldoussoren components: Macintosh messages: 218697 nosy: Andrew.Harrington, ronaldoussoren priority: normal severity: normal status: open title: installer Python default setting fails with mac Python Launcher type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 06:34:59 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 17 May 2014 04:34:59 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400301299.42.0.644462840759.issue7776@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I prefer we update the ensurepip in 3.4.1 That will be helpful too since 3.5 has the fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 08:57:21 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 17 May 2014 06:57:21 +0000 Subject: [issue21517] installer Python default setting fails with mac Python Launcher In-Reply-To: <1400297661.67.0.596645362447.issue21517@psf.upfronthosting.co.za> Message-ID: <1400309841.96.0.672402558609.issue21517@psf.upfronthosting.co.za> Ned Deily added the comment: Python.org installers do not install anything to /usr/bin; they do, by default, install symbolic links in /usr/local/bin. Python 3 installers set the symlink "/usr/local/bin/python3" to the most recently installed version. The Python Launcher app has several open design issues, including whether it should be included at all. Currently, each version of Python (from python.org) installs its own copy of Python Launcher.app but they all share the same preference file. You can set the path to your preferred interpreter version by launching Python Launcher.app and then, in the Preferences pane, selecting the file type (e.g. "Python Script") and typing the interpreter path into the "Interpreter:" text box (e.g. "/usr/local/bin/python3.4"), rather than using any of the preset defaults in the pulldown list. ---------- nosy: +ned.deily resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 15:18:52 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 17 May 2014 13:18:52 +0000 Subject: [issue21385] in debug mode, compile(ast) fails with an assertion error if an AST node has no line number information In-Reply-To: <1398762010.89.0.992252148712.issue21385@psf.upfronthosting.co.za> Message-ID: <1400332732.32.0.153585274998.issue21385@psf.upfronthosting.co.za> R. David Murray added the comment: Victor: in the production code discussed in the original posting, there *are* line numbers, and they are meaningful; they just aren't monotonically increasing. I believe the request here is to simply remove the assert. (If we did that, we'd have to also add tests that python itself was generating monotonically increasing line number, and make some doc changes.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 15:26:21 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 17 May 2014 13:26:21 +0000 Subject: [issue21386] ipaddress.IPv4Address.is_global not implemented In-Reply-To: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za> Message-ID: <1400333181.5.0.646445118605.issue21386@psf.upfronthosting.co.za> R. David Murray added the comment: The patch looks correct to me, but we also need tests. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 15:46:14 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 17 May 2014 13:46:14 +0000 Subject: [issue21391] shutil uses both os.path.abspath and an 'import from' of abspath In-Reply-To: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> Message-ID: <1400334374.34.0.121128574845.issue21391@psf.upfronthosting.co.za> R. David Murray added the comment: I'd prefer to get rid of it, otherwise we might get requests to add all the other os.path functions to the shutil namespace, and I don't think having that kind of "more than one way to do it" serves anyone. I suppose we'll have to deprecate it first if we do get rid of it :(. ---------- nosy: +r.david.murray title: PATCH: using the abspath shortcut in Lib/shutil -> shutil uses both os.path.abspath and an 'import from' of abspath _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 16:04:07 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 17 May 2014 14:04:07 +0000 Subject: [issue21397] tempfile.py: Fix grammar in docstring, comment typos In-Reply-To: <1398854871.81.0.354739462705.issue21397@psf.upfronthosting.co.za> Message-ID: <1400335446.99.0.191711747747.issue21397@psf.upfronthosting.co.za> R. David Murray added the comment: 'below' doesn't make sense at all if you view it via pydoc. There is only one unsafe function left, mktemp. Here is an alternate patch that takes advantage of that fact. ---------- nosy: +r.david.murray Added file: http://bugs.python.org/file35268/tempfile-docstring.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 17:04:13 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 17 May 2014 15:04:13 +0000 Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on Fedora 18 In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za> Message-ID: <1400339053.27.0.226067517269.issue18540@psf.upfronthosting.co.za> R. David Murray added the comment: Milan: using 'localhost' is incorrect, since the string 'localhost' will not always resolve to the local host IP, while passing None to getaddrinfo will. It is significant that the example fails. We need a test for this case (the imap tests have been historically very poor, though we've improved that somewhat in the past few years). Although it is a low-probability thing, someone might be depending on self.host being '' by default, so I think the better (and simpler) fix is to convert '' to None in the _create_socket method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 17:07:00 2014 From: report at bugs.python.org (Kristian Benoit) Date: Sat, 17 May 2014 15:07:00 +0000 Subject: [issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks In-Reply-To: <1400099572.93.0.56172954955.issue21509@psf.upfronthosting.co.za> Message-ID: <1400339220.28.0.730315077335.issue21509@psf.upfronthosting.co.za> Kristian Benoit added the comment: I added code to skip the bom if present when encoding is either None or "utf-8". The problem I have with Victor's solution is that users don't know these files are not plain UTF-8. Most text editor says it's utf-8 encoded, how can a user figure out there 3 hidden bytes at the start of the file ? Kristian ---------- keywords: +patch Added file: http://bugs.python.org/file35269/json.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 18:05:33 2014 From: report at bugs.python.org (Andrew Harrington) Date: Sat, 17 May 2014 16:05:33 +0000 Subject: [issue21517] installer Python default setting fails with mac Python Launcher In-Reply-To: <1400309841.96.0.672402558609.issue21517@psf.upfronthosting.co.za> Message-ID: Andrew Harrington added the comment: I see not messing with /usr/bin. Your note about Python Launcher would be a nice addition to the Mac installer notes. I would encourage that before closing this. On Sat, May 17, 2014 at 1:57 AM, Ned Deily wrote: > > Ned Deily added the comment: > > Python.org installers do not install anything to /usr/bin; they do, by > default, install symbolic links in /usr/local/bin. Python 3 installers set > the symlink "/usr/local/bin/python3" to the most recently installed > version. The Python Launcher app has several open design issues, including > whether it should be included at all. Currently, each version of Python > (from python.org) installs its own copy of Python Launcher.app but they > all share the same preference file. You can set the path to your preferred > interpreter version by launching Python Launcher.app and then, in the > Preferences pane, selecting the file type (e.g. "Python Script") and typing > the interpreter path into the "Interpreter:" text box (e.g. > "/usr/local/bin/python3.4"), rather than using any of the preset defaults > in the pulldown list. > > ---------- > nosy: +ned.deily > resolution: -> works for me > stage: -> resolved > status: open -> closed > > _______________________________________ > 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 May 17 18:13:33 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 17 May 2014 16:13:33 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1400343213.12.0.741082347224.issue15014@psf.upfronthosting.co.za> R. David Murray added the comment: OK, I've finally had time to review this, sorry for the delay. The impalib mechanism is tailored to how imap works (that's the whole thing about "continuation response". smtplib auth works a bit differently, and your adaptation looks OK to me. The accompanying docstrings are a bit confusing, though, since they copy the imaplib language, which isn't entirely applicable. Instead of talking about a 'continuation response', it should talk about a '334 challenge response', I think. Also, both the imaplib and smptlib methods are named after the corresponding command names in the protocol. So for imaplib we have 'authenticate', but for smtplib it should be 'auth'. I also think we should expose the supported auth methods as part of the public API. I think exposing the preferred auth list is premature, since if we are going to do that we need to have a way to add elements to that list for the users's own auth methods and we don't have that. So let's confine this issue to adding the 'auth' method and using it in the login method. The tests should include a new test of calling the auth method directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 18:17:42 2014 From: report at bugs.python.org (Kristian Benoit) Date: Sat, 17 May 2014 16:17:42 +0000 Subject: [issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks In-Reply-To: <1400099572.93.0.56172954955.issue21509@psf.upfronthosting.co.za> Message-ID: <1400343462.71.0.905268238903.issue21509@psf.upfronthosting.co.za> Changes by Kristian Benoit : Added file: http://bugs.python.org/file35270/json.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 19:12:40 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sat, 17 May 2014 17:12:40 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg Message-ID: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> New submission from Claudiu.Popa: Hello. While working on issue8579, I noticed that there is no way to detach a key from the registry, loaded with LoadKey function. The attached patch exposes RegUnLoadKeyW as winreg.UnloadKey. Also, this patch adds a new script in the test folder, windows_helper.py, which could be an useful addition for testing Windows specific issues, like acquiring / releasing a privilege. ---------- components: Library (Lib) files: winreg_unload_key.patch keywords: patch messages: 218708 nosy: Claudiu.Popa priority: normal severity: normal status: open title: Expose RegUnloadKey in winreg type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35271/winreg_unload_key.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 19:15:10 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 17 May 2014 17:15:10 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1400346910.14.0.318852392233.issue21518@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 20:11:40 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sat, 17 May 2014 18:11:40 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1400350300.56.0.876669533604.issue21518@psf.upfronthosting.co.za> Claudiu.Popa added the comment: It needs administrator elevation for running the test. I'll update the patch to skip the test if the user doesn't have elevation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 20:25:53 2014 From: report at bugs.python.org (Thomas Heller) Date: Sat, 17 May 2014 18:25:53 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on some directories (Windows) In-Reply-To: <1400289432.5.0.122056227105.issue21516@psf.upfronthosting.co.za> Message-ID: <5377AA17.6060105@ctypes.org> Thomas Heller added the comment: > When you say "os.path.isdir(...) works fine", you mean it's returning False? As shown in the original report (http://bugs.python.org/issue21516#msg218664) os.path.isdir() returns True; which is correct since c:\Users\admin is a directory on my machine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 20:48:25 2014 From: report at bugs.python.org (Steffen Ullrich) Date: Sat, 17 May 2014 18:48:25 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1400352505.29.0.620906477277.issue21430@psf.upfronthosting.co.za> Steffen Ullrich added the comment: Data transport in SSL is not done with plain TCP, but with encoded frames inside TCP. To get decoded data one has to first receive the full frame, even if one is only interested in the first bytes. Example: - server does an SSL_write with 200 bytes. This will result in a frame which contain all the 200 bytes. - if the client does a SSL_read (e.g. recv) to get 100 bytes the underlying SSL stack will read the full frame, but return only 100 bytes of the 200 bytes. - if the client then would call select to check if more data are available this would fail, because select checks the data on the socket only. But pending would return that there are still 100 bytes available for read in the SSL stack. So to make use of select with SSL the application would have to check first with pending, if there are already buffered data, and only if there are no buffered data it should call select to check if there are data on the socket. But, one could skip the call of pending if all SSL_read (recv) are at least 16k, because this is the maximum size of an SSL frame and SSL_read will not read more than one SSL frame at a time (actually I'm not sure if python calls only SSL_read once within recv, but I assume so). You might have a look at the examples and documentation for non-blocking I/O for Perls IO::Socket::SSL package (disclaimer: I'm the maintainer): http://search.cpan.org/~sullr/IO-Socket-SSL-1.987/lib/IO/Socket/SSL.pm ---------- nosy: +noxxi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 21:12:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 May 2014 19:12:57 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1400353977.76.0.853349315537.issue21430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > So to make use of select with SSL the application would have to check first > with pending, if there are already buffered data, What's the point of checking? Just call SSL_read() and catch the SSL_ERROR_WANT_{READ,WRITE} to determine that no data is available; as a bonus it also tells you whether you have to select() for read or for write. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 21:39:01 2014 From: report at bugs.python.org (Bas Wijnen) Date: Sat, 17 May 2014 19:39:01 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1400355541.0.0.515464542416.issue21430@psf.upfronthosting.co.za> Bas Wijnen added the comment: After trying to use this, I think ssl.pending is a valuable function that should be supported and documented. My use case is a half-synchronous system, where I want most calls to block but asynchronous events are possible as well. Switching the socket between blocking and non-blocking all the time is annoying and results in code that is harder to read. With ssl.pending, I can simply repeat the read as long as data is pending. Setting my buffer size high might technically work, but that seems too fragile. I don't like using an undocumented function either, but I'm hoping that gets fixed. ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 22:52:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 May 2014 20:52:35 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper In-Reply-To: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> Message-ID: <3gWJb65PGnz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 3024ad49f00e by Brian Quinlan in branch 'default': Issue #21362: concurrent.futures does not validate that max_workers is proper http://hg.python.org/cpython/rev/3024ad49f00e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 17 22:53:32 2014 From: report at bugs.python.org (Brian Quinlan) Date: Sat, 17 May 2014 20:53:32 +0000 Subject: [issue21362] concurrent.futures does not validate that max_workers is proper In-Reply-To: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za> Message-ID: <1400360012.56.0.122572885361.issue21362@psf.upfronthosting.co.za> Brian Quinlan added the comment: Committed, thanks for the fix! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 00:07:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 May 2014 22:07:43 +0000 Subject: [issue10744] ctypes arrays have incorrect buffer information (PEP-3118) In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za> Message-ID: <3gWLFp5Sy4z7LjV@mail.python.org> Roundup Robot added the comment: New changeset 44dac2e7fcb8 by Benjamin Peterson in branch '2.7': support pep 3118 format strings for ctypes objects with nontrivial shapes (closes #10744) http://hg.python.org/cpython/rev/44dac2e7fcb8 New changeset 22938bf57161 by Benjamin Peterson in branch '3.4': support pep 3118 format strings for ctypes objects with nontrivial shapes (closes #10744) http://hg.python.org/cpython/rev/22938bf57161 New changeset ea9193340d6c by Benjamin Peterson in branch 'default': merge 3.4 (#10744) http://hg.python.org/cpython/rev/ea9193340d6c ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 00:36:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 May 2014 22:36:20 +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: <3gWLtq2cmjz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 060cfd049d14 by Stefan Krah in branch 'default': Issue #20186: memoryobject.c: add function signatures. http://hg.python.org/cpython/rev/060cfd049d14 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 00:39:59 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 17 May 2014 22:39:59 +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: <1400366399.44.0.366575154912.issue20186@psf.upfronthosting.co.za> Stefan Krah added the comment: memoryobject.c is converted with a minimal patch (I would like to keep 100% code coverage for the file). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 00:41:05 2014 From: report at bugs.python.org (Steffen Ullrich) Date: Sat, 17 May 2014 22:41:05 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1400366465.51.0.501057367372.issue21430@psf.upfronthosting.co.za> Steffen Ullrich added the comment: > What's the point of checking? Just call SSL_read() and catch the SSL_ERROR_WANT_{READ,WRITE} to determine that no data is available; as a bonus it also tells you whether you have to select() for read or for write. A common scenario with non-blocking sockets is to have lots of sockets at the same time and a central select loop. And whenever a socket gets ready it usually reads only as much as is needed for its current task and then returns to the select-loop. I was trying to point out that for SSL enabled sockets this approach will no longer work and might cause odd stalling of connections, because select will not show the socket as readable although data are there for read. I don't think it is enough to just document pending, but it should be documented that the behavior with SSL sockets with select differs from the behavior one is used from normal TCP sockets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 00:46:20 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 May 2014 22:46:20 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1400366465.51.0.501057367372.issue21430@psf.upfronthosting.co.za> Message-ID: <1400366778.2337.9.camel@fsol> Antoine Pitrou added the comment: > I was trying to point out that for SSL enabled sockets this approach > will no longer work and might cause odd stalling of connections, > because select will not show the socket as readable although data are > there for read. You are right, this is worth mentioning in the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 00:52:13 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 17 May 2014 22:52:13 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1400367133.57.0.0831863041007.issue19980@psf.upfronthosting.co.za> Mark Lawrence added the comment: I propose the following. help('') returns help on strings in the same way that help([]) and help({}) returns help on lists and dicts respectively, further help(''.method) returns help on the string method or an attribute error, so this appears to me consistent. help('doh') returns enhanced output along the lines Terry suggested in msg206157. help('module') gives the path to the module as well as the help output, if any, as I think this could be useful in cases where you're looking for problems and have a stdlib module masked by a file of your own. Thoughts? If we can come to an agreement I'll try and work up a patch. Note that I've tried looking at the test code and it didn't make much sense to me, pointers welcome. I've also just signed the contributor's agreement. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 00:57:01 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 May 2014 22:57:01 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <3gWMLh5Zhmz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset b820b1b282b2 by Antoine Pitrou in branch '3.4': Issue #21430: additions to the description of non-blocking SSL sockets http://hg.python.org/cpython/rev/b820b1b282b2 New changeset 077e64b23592 by Antoine Pitrou in branch 'default': Issue #21430: additions to the description of non-blocking SSL sockets http://hg.python.org/cpython/rev/077e64b23592 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 01:49:50 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 17 May 2014 23:49:50 +0000 Subject: [issue21385] in debug mode, compile(ast) fails with an assertion error if an AST node has no line number information In-Reply-To: <1398762010.89.0.992252148712.issue21385@psf.upfronthosting.co.za> Message-ID: <1400370590.43.0.442500835593.issue21385@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Summary of this post: compile currently checks user input with assert; this is a bug that should be changed. I re-read astlinenotest.py and realized that FunctionDef is included in '*' and not some omitted import. (The latter is common for code posted on python-list, if not here. This illustrates why PEP 8 deprecates 'import *'; import ast ... ast.FunctionDef would have been clear on first reading.) So I ran the module in installed 3.4 and repository debug 3.5 and got the assert with the latter. "It seems to me that when the lnotab was created, no one even had in mind that there would be an actually useful AST module that would be used for code generation." I am pretty sure this is correct. I suspect that the assert in question was originally intended to test the logic of the internal syntax tree line number generation. But now it also tests user input, which I and may others think is a bad idea. A solution between removing the assert (and the internal check) and converting it to, say, ValueError("decreasing line no in input ast"), and thereby stopping code that now normally and legitimately works, would be to skip the asserts when the compile input is an ast instead of code. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 02:22:19 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 18 May 2014 00:22:19 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400372539.86.0.6842072109.issue7776@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 02:26:14 2014 From: report at bugs.python.org (Donald Stufft) Date: Sun, 18 May 2014 00:26:14 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400372774.32.0.864715989191.issue7776@psf.upfronthosting.co.za> Donald Stufft added the comment: @larry Is there anything else I need to do? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 02:48:22 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 18 May 2014 00:48:22 +0000 Subject: [issue21391] shutil uses both os.path.abspath and an 'import from' of abspath In-Reply-To: <1398851506.17.0.252002971676.issue21391@psf.upfronthosting.co.za> Message-ID: <1400374102.3.0.993999606794.issue21391@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch to deprecate the shutil.abspath function. ---------- nosy: +berker.peksag Added file: http://bugs.python.org/file35272/issue21391.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 03:20:43 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 18 May 2014 01:20:43 +0000 Subject: [issue2052] Allow changing difflib._file_template character encoding. In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za> Message-ID: <1400376043.82.0.42248187474.issue2052@psf.upfronthosting.co.za> Berker Peksag added the comment: Attaching a new version of issue2052_html5.diff. Changes: - Switch from px to em in CSS - Cleanup markup a bit (e.g. delete redundant colgroup tags) ---------- Added file: http://bugs.python.org/file35273/issue2052_html5_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 03:37:10 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 18 May 2014 01:37:10 +0000 Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za> Message-ID: <1400377030.85.0.576414637384.issue21112@psf.upfronthosting.co.za> Berker Peksag added the comment: > Berker: do you consider your diff ready to go in, or is it an "early" > diff (like a work-in-progress)? I tested my patch with test_expectedFailure.py again. The patch is not really fixes the problem described in msg215240. So, I consider it a WIP patch for now. Sorry for the noise. Here is the output on Python 3.3: $ python3.3 -m unittest discover -v test_fails (test_expectedFailure.TestControl) ... FAIL test_passes (test_expectedFailure.TestControl) ... ok ====================================================================== FAIL: test_fails (test_expectedFailure.TestControl) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/berker/projects/cpython-default/playground/test_expectedFailure.py", line 9, in test_fails self.assertFalse(True) AssertionError: True is not false ---------------------------------------------------------------------- Ran 2 tests in 0.001s FAILED (failures=1) And here is the output on Python 3.5 (with issue21112.diff patch): $ ./../python -m unittest discover -v test_fails (test_expectedFailure.TestControl) ... FAIL test_passes (test_expectedFailure.TestControl) ... ok test_fails (test_expectedFailure.TestTreatment) ... expected failure test_passes (test_expectedFailure.TestTreatment) ... unexpected success ====================================================================== FAIL: test_fails (test_expectedFailure.TestControl) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/berker/projects/cpython-default/playground/test_expectedFailure.py", line 9, in test_fails self.assertFalse(True) AssertionError: True is not false ---------------------------------------------------------------------- Ran 4 tests in 0.002s FAILED (failures=1, expected failures=1, unexpected successes=1) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 03:40:13 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 18 May 2014 01:40:13 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400377213.14.0.975621078787.issue7776@psf.upfronthosting.co.za> Senthil Kumaran added the comment: @dstufft - should you commit it in 3.4 branch (since the change is already in 3.5) and then wait for larry's approval or rejection? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 04:59:08 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 18 May 2014 02:59:08 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400381948.37.0.151786717199.issue7776@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, this has my blessing to be merged for 3.4.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 04:59:18 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 18 May 2014 02:59:18 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400381958.14.0.00192062256932.issue7776@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 05:14:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 18 May 2014 03:14:52 +0000 Subject: [issue21470] Better seeding for the random module In-Reply-To: <1399755385.94.0.749648968305.issue21470@psf.upfronthosting.co.za> Message-ID: <1400382892.16.0.983868792011.issue21470@psf.upfronthosting.co.za> Larry Hastings added the comment: (If the past few weeks have taught us *anything*, it's that we can't look to OpenSSL to learn best practices.) ---------- nosy: +larry stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 05:24:56 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 18 May 2014 03:24:56 +0000 Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za> Message-ID: <1400383496.73.0.266582152726.issue21112@psf.upfronthosting.co.za> Larry Hastings added the comment: Considering that I'm tagging 3.4.1 within an hour or two, and we don't have a patch yet, I'd say that this is too late to go into 3.4.1. But I'm happy to consider it for a future 3.4.x revision. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 05:54:02 2014 From: report at bugs.python.org (Alexey Gorshkov) Date: Sun, 18 May 2014 03:54:02 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1400385242.73.0.0783850417275.issue21430@psf.upfronthosting.co.za> Alexey Gorshkov added the comment: >Issue #21430: additions to the description of non-blocking SSL sockets I do not see any mention of .pending() in Your commit. Is this some personal hate to subject? Are You going to document this method or not? Documenting it on line of text. If You are not going to document this method, will You accept my patch for documentation adding this method? Simply saying: This issue is here, people wand documentation for what must be documented for over a 5 years now (http://bugs.python.org/issue1251). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 07:08:23 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 18 May 2014 05:08:23 +0000 Subject: [issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za> Message-ID: <1400389703.07.0.474315808375.issue20362@psf.upfronthosting.co.za> Berker Peksag added the comment: I've added missing self._formatMessage() functions to assertRegex and assertNotRegex asserts. ---------- keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review versions: -Python 3.3 Added file: http://bugs.python.org/file35274/issue20362.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 07:54:15 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sun, 18 May 2014 05:54:15 +0000 Subject: [issue21519] IDLE : Bug in keybinding validity check Message-ID: <1400392455.89.0.13094614924.issue21519@psf.upfronthosting.co.za> New submission from Saimadhav Heblikar: Steps to reproduce the bug: 1. IDLE > options > configure idle > keys 2. Try to replace a keybinding for an action with that of another action which has more than one keybinding. For eg : Default binding of copy= . So, try to replace any other keybinding with 3. This change is accepted Now the binding will be assigned to two actions. This bug only applies if the other action has more than one binding. In case the other action has only one binding, an error is raised(as expected). Attaching a patch to fix this issue. ---------- components: IDLE files: keybinding.diff keywords: patch messages: 218734 nosy: sahutd, terry.reedy priority: normal severity: normal status: open title: IDLE : Bug in keybinding validity check type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file35275/keybinding.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 08:46:00 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 18 May 2014 06:46:00 +0000 Subject: [issue21520] Erroneous zipfile test failure if the string 'bad' appears in pwd Message-ID: <1400395560.62.0.305002510991.issue21520@psf.upfronthosting.co.za> New submission from Larry Hastings: If you extract current Python (3.4 or trunk) into a directory, and anywhere in the name of the directory is the string "bad", such as /tmp/badtest /home/baddison/src/python then test_write_filtered_python_package() in Lib/test/test_zipfile.py will fail. The reason is, the third subtest uses a "filterfunc" to ignore certain files, and its test to ignore files is effectively "bad" in fn ("fn" is an ill-conceived abbreviation for "filename") This is overbroad. Changing it to "Lib/test/bad" in fn prevents this error. I'm creating this issue just to remind myself to fix it. 3.4.1 is tagged and I didn't want to re-cut the release, but I didn't feel like pushing it while 3.4.1 hadn't landed in trunk yet. ---------- assignee: larry components: Tests messages: 218735 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Erroneous zipfile test failure if the string 'bad' appears in pwd type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 09:49:39 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 18 May 2014 07:49:39 +0000 Subject: [issue21520] Erroneous zipfile test failure if the string 'bad' appears in pwd In-Reply-To: <1400395560.62.0.305002510991.issue21520@psf.upfronthosting.co.za> Message-ID: <1400399379.69.0.495524201123.issue21520@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 10:55:40 2014 From: report at bugs.python.org (rovf) Date: Sun, 18 May 2014 08:55:40 +0000 Subject: [issue21521] Tkinter + OSX + Spaces : Multiple file dialogues created Message-ID: <1400403340.1.0.400733156313.issue21521@psf.upfronthosting.co.za> New submission from rovf: I'm running this on OSX 10.6 (SnowLeopard) with the OSX "Spaces" feature enabled (i.e. several virtual desktops). This is my (complete) program: from tkinter.filedialog import asksaveasfilename pathname=asksaveasfilename(initialdir='.',title='gaga') This has the following odd behaviours: - The file dialogue opens, but when I switch to another space, the file dialogue is open there too, as a *separate* file dialogue. I.e., when I go back to the original space, select a file and exit the dialogue, my program continues running (for instance, when called from an interactive python shell, I get the prompt again), but on the other space, the dialogue is still open. - I also noticed that the parameter initialdir='.' is NOT honoured, i.e. the file dialogue starts on the topmost directory. BTW, the same behaviour is also in Python 2.6. ---------- components: Tkinter messages: 218736 nosy: rovf priority: normal severity: normal status: open title: Tkinter + OSX + Spaces : Multiple file dialogues created type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 11:17:54 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 18 May 2014 09:17:54 +0000 Subject: [issue21521] Tkinter + OSX + Spaces : Multiple file dialogues created In-Reply-To: <1400403340.1.0.400733156313.issue21521@psf.upfronthosting.co.za> Message-ID: <1400404674.72.0.932288002186.issue21521@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 11:33:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 May 2014 09:33:22 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1400405602.4.0.83775980718.issue21430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not intending to document the pending() method. Apparently the only people wanting to use it are/were confused about how exactly to write non-blocking SSL code, which is not a good hint. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 11:52:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 18 May 2014 09:52:48 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400406768.62.0.300352761155.issue21515@psf.upfronthosting.co.za> STINNER Victor added the comment: tempfile_o_tmpfile2.patch: Updated patch to handle OS errors. I'm not sure that __O_TMPFILE has the same value on all architectures. The O_TMPFILE flag was added to fcntl.h in the glibc 2.19 (released the 8 Feb 2014): https://sourceware.org/git/?p=glibc.git;a=commit;h=ffdd31816a67f48697ea4d6b852e58d2886d42ca My Linux Fedora 20 uses the glibc 2.18. I removed the hardcoded constant from my patch. Add this to Lib/tempfile.py to test manually if you have a glibc older than 2.19: # after "if hasattr(_os, 'O_TMPFILE'):" elif _sys.platform == 'linux': __O_TMPFILE = 0o20000000 _O_TMPFILE = (__O_TMPFILE | _os.O_DIRECTORY) ---------- Added file: http://bugs.python.org/file35276/tempfile_o_tmpfile2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 11:53:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 18 May 2014 09:53:21 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400406801.2.0.999869779359.issue21515@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file35276/tempfile_o_tmpfile2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 12:01:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 18 May 2014 10:01:16 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1400407276.66.0.289430784414.issue21515@psf.upfronthosting.co.za> STINNER Victor added the comment: (Oops, I made a mistake, the hardcoded constant was still present in my patch 2.) Patch 3 uses tempfile._O_TMPFILE_WORKS variable to check if the O_TMPFILE flag is avaialble and works. Use "os.O_TMPFILE = 0o20000000 | os.O_DIRECTORY" to try my patch with glibc older than 2.19. ---------- Added file: http://bugs.python.org/file35277/tempfile_o_tmpfile3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 12:51:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 May 2014 10:51:04 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1400410264.41.0.315088469789.issue13916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have no opinion. ---------- assignee: serhiy.storchaka -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 14:25:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 May 2014 12:25:59 +0000 Subject: [issue21522] Add more tkinter tests Message-ID: <1400415959.04.0.266142881924.issue21522@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which adds tests for Listbox.itemconfigure(), PanedWindow.paneconfigure() and several tests for Menu.entryconfigure(). ---------- assignee: serhiy.storchaka components: Tests, Tkinter files: test_tkinter_configure.patch keywords: patch messages: 218741 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add more tkinter tests type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35278/test_tkinter_configure.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 14:31:45 2014 From: report at bugs.python.org (Andrew Dalke) Date: Sun, 18 May 2014 12:31:45 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions Message-ID: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> New submission from Andrew Dalke: Python's compiler has quadratic-time time behavior based on the number of "and" or "or" expressions. A profile shows that stackdepth_walk is calling itself in a stack at least 512 levels deep. (My profiler doesn't go higher than that.) I've reduced it to a simple test case. Compiling functions of the form def f(x): x * x # Repeat N times takes linear time in the number of lines N, while functions of the form def g(x): x and x # Repeat N times takes quadratic time in N. Here's an example of running the attached demonstration code on a fresh build of Python from version control: Results from 3.5.0a0 (default:de01f7c37b53, May 18 2014, 13:18:43) num using using tests '*' 'and' 100 0.002 0.002 200 0.003 0.004 400 0.005 0.010 800 0.012 0.040 1600 0.023 0.133 3200 0.042 0.906 6400 0.089 5.871 12800 0.188 27.581 25600 0.404 120.800 The same behavior occurs when I replace 'and' with 'or'. The same behavior also occurs under Python 2.7.2, 3.3.5, 3.4.0. (I don't have builds of 3.1 or 3.2 for testing.) However, the demonstration code shows linear time under Python 2.6.6: Results from 2.6.6 (r266:84374, Aug 31 2010, 11:00:51) num using using tests '*' 'and' 100 0.003 0.001 200 0.002 0.002 400 0.006 0.008 800 0.010 0.010 1600 0.019 0.022 3200 0.039 0.045 6400 0.085 0.098 12800 0.176 0.203 25600 0.359 0.423 51200 0.726 0.839 I came across this problem because my code imports a large machine-generated module. It was originally written for Python 2.6, where it worked just fine. When I tried to import it under new Pythons, the import appeared to hang, and I killed it after a minute or so. As a work-around, I have re-written the code generator to use chained if-statements instead of the short-circuit and operator. ---------- components: Interpreter Core files: quadratic_shortcircuit_compilation.py messages: 218742 nosy: dalke priority: normal severity: normal status: open title: quadratic-time compilation in the number of 'and' or 'or' expressions type: performance versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35279/quadratic_shortcircuit_compilation.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 15:20:26 2014 From: report at bugs.python.org (jorispilot) Date: Sun, 18 May 2014 13:20:26 +0000 Subject: [issue21524] Allowing to pass pathlib.Path object in mimetypes.guess_type function Message-ID: <1400419226.75.0.292765982231.issue21524@psf.upfronthosting.co.za> Changes by jorispilot : ---------- components: Library (Lib) nosy: jorispilot priority: normal severity: normal status: open title: Allowing to pass pathlib.Path object in mimetypes.guess_type function type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 15:48:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 May 2014 13:48:56 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1400420936.55.0.781082930218.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch synchronized with tip and fixed support of Tcl <8.5. ---------- Added file: http://bugs.python.org/file35280/tkinter_bignum_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 16:36:10 2014 From: report at bugs.python.org (Roger Luethi) Date: Sun, 18 May 2014 14:36:10 +0000 Subject: [issue21386] ipaddress.IPv4Address.is_global not implemented In-Reply-To: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za> Message-ID: <1400423770.1.0.0309332606355.issue21386@psf.upfronthosting.co.za> Roger Luethi added the comment: New patch includes tests. Lightly tested with Python 3.4 (because trunk doesn't build for me right now): tests fail without patch, pass with patch. Patch re-diffed against trunk. ---------- Added file: http://bugs.python.org/file35281/ipv4addr_global2-hg.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 17:49:10 2014 From: report at bugs.python.org (Bas Wijnen) Date: Sun, 18 May 2014 15:49:10 +0000 Subject: [issue21430] Document ssl.pending() In-Reply-To: <1399230346.59.0.136279071434.issue21430@psf.upfronthosting.co.za> Message-ID: <1400428150.26.0.711411746446.issue21430@psf.upfronthosting.co.za> Bas Wijnen added the comment: Alexey: please be more civil. Antoine: In that case, can you please explain how you would recommend me to implement my use case, where most of my calls are master-initiated and blocking, but some slave-initiated events must be non-blocking? Should I make a lot of calls to sslsocket.setblocking() to switch it on and off all the time? AFAIK that is a system call (or isn't it?); while that won't make any real difference in performance in Python, it doesn't feel right to make system calls when there's technically no need for it. Also, as I suggested previously, if you don't document the method, could you please add the word "pending" somewhere in the text? This ensures people looking for documentation of what they see in the source will find this explanation. It may also be good to add a note to the source code that this function should not be used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 18:03:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 18 May 2014 16:03:32 +0000 Subject: [issue21520] Erroneous zipfile test failure if the string 'bad' appears in pwd In-Reply-To: <1400395560.62.0.305002510991.issue21520@psf.upfronthosting.co.za> Message-ID: <1400429012.13.0.0626934679.issue21520@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's an eye-wateringly-thorough description of the bug for the sake of posterity. The test code in question is test_write_filtered_python_package() in Lib/test/test_zipfile.py. This function uses PyZipFile to build a zipfile from the contents of the "Lib/test" directory. PyZipFile scans for .py files, then compiles them into .pyc or .pyo files and adds the compiled result. The test code actually reuses the PyZipFile object three times: The first try succeeds, but raises some warnings because of some deliberately troublesome files in that directory that upset the compiler. These files all contain the substring "bad" in their name, like "Lib/test/bad_coding.py". The warnings are written to stdout; the test captures stdout and scans for the errors. When this function is done, the zipfile contains .pyc files of all the files in Lib/test except for the ones with the substring "bad" in their name. The second try succeeds, but ignores every file because of a "filterfunc" passed in that always returns False. It's effectively a no-op--no files are added to the zipfile. The test then scans the output to make sure no warnings were issued. The third try succeeds. It uses the "filterfunc" parameter to selectively skip the "bad" files, then scans stdout to ensure that no warnings were issued there. However, since it's re-adding all the other files to the zipfile, this does issue a zillion UserWarning assert warnings. The code suppresses these with a "self.assertWarns(UserWarning)" context manager. So here's the bug. If you untarred Python into "/tmp/goodidea", then the test works as expected. But if you untar Python into "/tmp/badidea", then the filterfunc in the third test ignores *every* file, because *every* file contains the substring "bad". Therefore it never adds a single file. And therefore it never fires the UserWarning about redundantly adding a file. Since UserWarning is never issued, and the test is supposed to issue it, the assertWarns context manager flags the test as a failure. The easy fix: change the filterfunc to be far more selective, only filtering out paths containing the substring "Lib/test/bad". This would still fail if you untarred Python to "/tmp/Lib/test/bad/", but hopefully nobody will do *that*. Perhaps a still-better approach would be lambda path: os.path.basename(path).startswith("bad") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 18:04:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 May 2014 16:04:31 +0000 Subject: [issue21525] Accept lists in Tkinter Message-ID: <1400429071.94.0.00909655456626.issue21525@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There is very common error when user pass list instead tuple to Tkinter. Some functions accept both tuple and list, some functions reject list, but many functions silently convert non-tuple value to str (e.g. [1, 2] -> '[1, 2]' instead of expected Tcl representation '{1 2}'). The proposed patch adds support of Python lists in all Tkinter functions which accept tuples. ---------- assignee: serhiy.storchaka components: Tkinter files: tkinter_accept_lists.patch keywords: patch messages: 218747 nosy: gpolo, loewis, serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Accept lists in Tkinter type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35282/tkinter_accept_lists.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 18:07:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 May 2014 16:07:27 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1400429247.06.0.27941026578.issue16840@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 19:15:38 2014 From: report at bugs.python.org (Thomas Guettler) Date: Sun, 18 May 2014 17:15:38 +0000 Subject: [issue21495] Sane default for logging config In-Reply-To: <1399987976.18.0.00182198684039.issue21495@psf.upfronthosting.co.za> Message-ID: <1400433338.93.0.317909817287.issue21495@psf.upfronthosting.co.za> Thomas Guettler added the comment: Just for the record. Here are the discussions about this topic on the python-ideas mailing list: https://mail.python.org/pipermail/python-ideas/2014-May/027839.html https://mail.python.org/pipermail/python-ideas/2014-May/027858.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 19:58:57 2014 From: report at bugs.python.org (Ian Cordasco) Date: Sun, 18 May 2014 17:58:57 +0000 Subject: [issue17994] Change necessary in platform.py to support IronPython In-Reply-To: <1368714285.1.0.952125974829.issue17994@psf.upfronthosting.co.za> Message-ID: <1400435937.11.0.834269504397.issue17994@psf.upfronthosting.co.za> Ian Cordasco added the comment: I missed the fact that the user gave me the information from sys.version: https://stackoverflow.com/questions/16545027/ironpython-error-in-url-request?noredirect=1#comment23847257_16545027 I'll throw together a failing test with this and run it against 2.7, and the 3.x branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 20:04:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 May 2014 18:04:03 +0000 Subject: [issue9673] Entry Widget Not Editable under Windows XP In-Reply-To: <1282672182.44.0.886074830019.issue9673@psf.upfronthosting.co.za> Message-ID: <1400436243.01.0.610068208314.issue9673@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 20:11:48 2014 From: report at bugs.python.org (Daniel Greenfeld) Date: Sun, 18 May 2014 18:11:48 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1400436708.17.0.794905389918.issue21145@psf.upfronthosting.co.za> Daniel Greenfeld added the comment: For what it's worth, I just released cached-property on PyPI and someone suggested I join the discussion here. Package: https://pypi.python.org/pypi/cached-property Repo: https://github.com/pydanny/cached-property Notes: * 92% test coverage, albeit with a simple, arguably naive test. * I plan to increase the coverage to 100%. * I'm not entirely sure where to give credit for the original implementation. Right now I think it's Bottle, but I'm not certain. See https://github.com/pydanny/cached-property/issues/1 ---------- nosy: +pydanny _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 20:34:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 May 2014 18:34:35 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <1400438075.18.0.171747232324.issue21523@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 21:29:31 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 18 May 2014 19:29:31 +0000 Subject: [issue21520] Erroneous zipfile test failure if the string 'bad' appears in pwd In-Reply-To: <1400395560.62.0.305002510991.issue21520@psf.upfronthosting.co.za> Message-ID: <1400441371.12.0.47105161649.issue21520@psf.upfronthosting.co.za> Ned Deily added the comment: Testing for "Lib/test/bad" isn't correct either since the test will fail when the tests are run from an installed Python rather than just from a build directory. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 21:38:18 2014 From: report at bugs.python.org (Steve Dower) Date: Sun, 18 May 2014 19:38:18 +0000 Subject: [issue19866] tests aifc, sunau and wave failures on a fresh Win64 installation In-Reply-To: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za> Message-ID: <1400441898.46.0.800602096866.issue19866@psf.upfronthosting.co.za> Steve Dower added the comment: I noticed the same thing testing the 2.7.7rc1 installer, so I've got a fix for 2.7.7. The same issue exists for imghdrdata (which was added quite recently, it seems). Patch attached - any concerns? ---------- keywords: +patch nosy: +benjamin.peterson, steve.dower Added file: http://bugs.python.org/file35283/testdata.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 21:46:48 2014 From: report at bugs.python.org (Steve Dower) Date: Sun, 18 May 2014 19:46:48 +0000 Subject: [issue19866] tests aifc, sunau and wave failures on a fresh Win64 installation In-Reply-To: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za> Message-ID: <1400442408.77.0.795034631051.issue19866@psf.upfronthosting.co.za> Steve Dower added the comment: FWIW, the installers are about 130kb larger with the files included. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 21:47:55 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 18 May 2014 19:47:55 +0000 Subject: [issue21507] memory used by frozenset created from set differs from that of frozenset created from other iterable In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400442475.09.0.85312072709.issue21507@psf.upfronthosting.co.za> STINNER Victor added the comment: I restore the original title, my title was a mistake. ---------- title: set and frozenset constructor should use operator.length_hint to guess the size of the iterator -> memory used by frozenset created from set differs from that of frozenset created from other iterable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 22:41:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 May 2014 20:41:31 +0000 Subject: [issue21526] Support new booleans in Tkinter Message-ID: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Recent Tcl versions (since 8.5) no longer use internal "boolean" type. Instead they use "booleanString" type (but looks as only internally). Here is a patch which add support for "booleanString" Tcl type in case when it leaks to user. There are no any new tests because there is no simple way (if any) to create pure Tcl boolean object. ---------- assignee: serhiy.storchaka components: Tkinter files: tkinter_newboolean.patch keywords: patch messages: 218755 nosy: gpolo, loewis, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Support new booleans in Tkinter type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35284/tkinter_newboolean.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 22:47:11 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 18 May 2014 20:47:11 +0000 Subject: [issue20483] Missing network resource checks in test_urllib2 & test_smtplib In-Reply-To: <1391317175.95.0.400221944155.issue20483@psf.upfronthosting.co.za> Message-ID: <1400446031.61.0.390140882071.issue20483@psf.upfronthosting.co.za> Berker Peksag added the comment: I couldn't reproduce it either. I also tried related urllib and urllib2 tests: - test_urllib (passed) - test_urllibnet (skipped - Use of the 'network' resource not enabled) - test_urllib_response (passed) - test_urllib2net (skipped - Use of the 'network' resource not enabled) - test_urllib2_localnet (passed) ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 18 23:39:02 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 18 May 2014 21:39:02 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1400449142.63.0.642966946327.issue21518@psf.upfronthosting.co.za> Claudiu.Popa added the comment: This version of the patch skips the test if the privileges can't be acquired. ---------- Added file: http://bugs.python.org/file35285/issue21518.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 00:30:37 2014 From: report at bugs.python.org (eryksun) Date: Sun, 18 May 2014 22:30:37 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1400452237.27.0.991890811347.issue21518@psf.upfronthosting.co.za> eryksun added the comment: ctypes LibraryLoader instances cache CDLL/WinDLL instances, which cache function pointers. Using the global ctypes.cdll and ctypes.windll loaders can lead to conflicting definitions for restype, argtypes, and errcheck. I suggest using a private LibraryLoader in windows_helper, e.g.: windll = ctypes.LibraryLoader(ctypes.WinDLL) ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 00:32:20 2014 From: report at bugs.python.org (Brett Cannon) Date: Sun, 18 May 2014 22:32:20 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1400452340.19.0.0664104018147.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: Here is an implementation of importlib.util.module_from_spec(). With this it makes PEP 451 conceptually work like: spec = importlib.util.find_spec(name) module = importlib.util.module_from_spec(spec) spec.loader.exec_module(module) About the only other thing I can think of that people might still want is something like `importlib.util.load(spec)` so that they don't even need to care about whether load_module() or exec_module() is defined, but that can be a separate issue if it turns out people actually want something like that. ---------- keywords: +patch stage: test needed -> commit review Added file: http://bugs.python.org/file35286/module_from_spec.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 00:36:55 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 May 2014 22:36:55 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1400452615.82.0.76419705996.issue21145@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Does this work for you? >>> class X: ... @property ... @functools.lru_cache(None) ... def get_x(self): ... print("computing") ... return 5 ... >>> x = X() >>> x.get_x computing 5 >>> x.get_x 5 ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 00:39:12 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sun, 18 May 2014 22:39:12 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1400452752.16.0.723086969197.issue21145@psf.upfronthosting.co.za> Alex Gaynor added the comment: Will that implementation cause a memory leak? Won't the lru_cache have a dict mapping {self: result}, meaning that `self` will live forever, instead of storing result in self.__dict__, where the lifetimes are correct. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 00:40:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 May 2014 22:40:23 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1400452752.16.0.723086969197.issue21145@psf.upfronthosting.co.za> Message-ID: <1400452821.2346.0.camel@fsol> Antoine Pitrou added the comment: > Will that implementation cause a memory leak? Won't the lru_cache have > a dict mapping {self: result}, meaning that `self` will live forever, > instead of storing result in self.__dict__, where the lifetimes are > correct. Oh, you're right. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 00:47:47 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 18 May 2014 22:47:47 +0000 Subject: [issue21527] concurrent.futures.ThreadPoolExecutor does not use a default value Message-ID: <1400453267.44.0.909455514702.issue21527@psf.upfronthosting.co.za> New submission from Claudiu.Popa: As the title says, ThreadPoolExecutor does not use a default value for max_workers parameter, as ProcessPoolExecutor does. When the user does not care about the number of workers and wants only for something to run in background, he has to write code like this: if processes: executor = ProcessPoolExecutor() elif threads: executor = ThreadPoolExecutor(1) # or any other value This situation can also occur when the class is passed as a factory function: def create_pool(executor_factory): if executor_factory is process pool: executor = executor_factory() else: executor = executor_factory(1) This patch proposes using the number of cores as the default value for max_workers. For instance, multiprocessing.pool.ThreadPool uses the same value. ---------- components: Library (Lib) files: concurrent_futures_workers.patch keywords: patch messages: 218763 nosy: Claudiu.Popa, bquinlan priority: normal severity: normal status: open title: concurrent.futures.ThreadPoolExecutor does not use a default value type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35287/concurrent_futures_workers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 00:55:12 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 18 May 2014 22:55:12 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1400453712.84.0.178536331434.issue21518@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Thanks. Here's the updated version. Also, I only tested it on Windows 8.1. I'll try to find another machine with an older OS for testing it. ---------- Added file: http://bugs.python.org/file35288/issue21518_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 01:16:57 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 18 May 2014 23:16:57 +0000 Subject: [issue9673] Entry Widget Not Editable under Windows XP In-Reply-To: <1282672182.44.0.886074830019.issue9673@psf.upfronthosting.co.za> Message-ID: <1400455017.89.0.280290832974.issue9673@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The reverenced post did not give a runnable minimal example with the claimed bug, but only described more complex code at a now dead link. The following from http://effbot.org/tkinterbook/entry.htm works on my Win7 machine. import tkinter as tk master = tk.Tk() e = tk.Entry(master) e.pack() e.focus_set() def callback(): print(e.get()) b = tk.Button(master, text="get", width=10, command=callback) b.pack() tk.mainloop() ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 01:33:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 May 2014 23:33:34 +0000 Subject: [issue19866] tests aifc, sunau and wave failures on a fresh Win64 installation In-Reply-To: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za> Message-ID: <3gX06P3cbFz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 5318bf3e70a6 by Benjamin Peterson in branch '2.7': include test data in the windows installer, so tests don't fail (closes #19866) http://hg.python.org/cpython/rev/5318bf3e70a6 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 01:34:06 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 18 May 2014 23:34:06 +0000 Subject: [issue19866] tests aifc, sunau and wave failures on a fresh Win64 installation In-Reply-To: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za> Message-ID: <1400456046.88.0.568680356123.issue19866@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I applied the patch to my release branch, so it will make it into 2.7.7 final. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 01:43:57 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 18 May 2014 23:43:57 +0000 Subject: [issue21525] Accept lists in Tkinter In-Reply-To: <1400429071.94.0.00909655456626.issue21525@psf.upfronthosting.co.za> Message-ID: <1400456637.47.0.730799990215.issue21525@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Sounds like a good idea to me. The code looks pretty straightforward as far as I understood it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 01:49:08 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sun, 18 May 2014 23:49:08 +0000 Subject: [issue21528] Fix a number of typos in the documentation Message-ID: <1400456947.04.0.361173205763.issue21528@psf.upfronthosting.co.za> New submission from Alex Gaynor: Attached patch is against the default branch, and fixes a number of typos. ---------- assignee: docs at python components: Documentation files: typos.diff keywords: needs review, patch messages: 218769 nosy: alex, docs at python priority: normal severity: normal status: open title: Fix a number of typos in the documentation versions: Python 3.5 Added file: http://bugs.python.org/file35289/typos.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 01:52:35 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 18 May 2014 23:52:35 +0000 Subject: [issue6671] webbrowser doesn't respect xfce default browser In-Reply-To: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za> Message-ID: <1400457155.9.0.667257788752.issue6671@psf.upfronthosting.co.za> Berker Peksag added the comment: Attaching a patch that checks both XDG_CURRENT_DESKTOP and DESKTOP_SESSION env vars for XFCE. ---------- nosy: +berker.peksag stage: test needed -> patch review versions: +Python 3.5 -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file35290/issue6671.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 02:41:00 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 19 May 2014 00:41:00 +0000 Subject: [issue21529] JSON module: reading arbitrary process memory Message-ID: <1400460059.59.0.206542140717.issue21529@psf.upfronthosting.co.za> New submission from Benjamin Peterson: (Copy paste from the security list) Python 2 and 3 are susceptible to arbitrary process memory reading by a user or adversary due to a bug in the _json module caused by insufficient bounds checking. The sole prerequisites of this attack are that the attacker is able to control or influence the two parameters of the default scanstring function: the string to be decoded and the index. The bug is caused by allowing the user to supply a negative index value. The index value is then used directly as an index to an array in the C code; internally the address of the array and its index are added to each other in order to yield the address of the value that is desired. However, by supplying a negative index value and adding this to the address of the array, the processor's register value wraps around and the calculated value will point to a position in memory which isn't within the bounds of the supplied string, causing the function to access other parts of the process memory. Let me clarify: This is Python-3.4.0/Modules/_json.c: 1035 static PyObject * 1036 scanner_call(PyObject *self, PyObject *args, PyObject *kwds) 1037 { 1038 /* Python callable interface to scan_once_{str,unicode} */ 1039 PyObject *pystr; 1040 PyObject *rval; 1041 Py_ssize_t idx; 1042 Py_ssize_t next_idx = -1; 1043 static char *kwlist[] = {"string", "idx", NULL}; 1044 PyScannerObject *s; 1045 assert(PyScanner_Check(self)); 1046 s = (PyScannerObject *)self; 1047 if (!PyArg_ParseTupleAndKeywords(args, kwds, "On:scan_once", kwlist, &pystr, &idx)) 1048 return NULL; 1049 1050 if (PyUnicode_Check(pystr)) { 1051 rval = scan_once_unicode(s, pystr, idx, &next_idx); 1052 } 1053 else { 1054 PyErr_Format(PyExc_TypeError, 1055 "first argument must be a string, not %.80s", 1056 Py_TYPE(pystr)->tp_name); 1057 return NULL; 1058 } 1059 PyDict_Clear(s->memo); 1060 if (rval == NULL) 1061 return NULL; 1062 return _build_rval_index_tuple(rval, next_idx); 1063 } As you can see on line 1047, ParseTuple takes an 'n' as an argument for 'end', which, as can be learned from this page ( https://docs.python.org/3/c-api/arg.html ), means: n (int) [Py_ssize_t] Convert a Python integer to a C Py_ssize_t. This means it accepts a SIGNED integer value, thus allowing a negative value to be supplied as the 'end' parameter. Then onto scanstring_unicode_once to which execution gets transferred through line 1051 of the code above. 922 static PyObject * 923 scan_once_unicode(PyScannerObject *s, PyObject *pystr, Py_ssize_t idx, Py_ssize_t *next_idx_ptr) 924 { 925 /* Read one JSON term (of any kind) from PyUnicode pystr. 926 idx is the index of the first character of the term 927 *next_idx_ptr is a return-by-reference index to the first character after 928 the number. 929 930 Returns a new PyObject representation of the term. 931 */ 932 PyObject *res; 933 void *str; 934 int kind; 935 Py_ssize_t length; 936 937 if (PyUnicode_READY(pystr) == -1) 938 return NULL; 939 940 str = PyUnicode_DATA(pystr); 941 kind = PyUnicode_KIND(pystr); 942 length = PyUnicode_GET_LENGTH(pystr); 943 944 if (idx >= length) { 945 raise_stop_iteration(idx); 946 return NULL; 947 } Here we see that 'length' is set to the length of the string parameter. This will always be a positive value. On line 945 it is checked whether idx is equal or higher than length; this can never be true in the case of a negative index value. 949 switch (PyUnicode_READ(kind, str, idx)) { PyUnicode_READ is defined as follows ( in Python-3.4.0/Include/unicodeobject.h ): 516 /* Read a code point from the string's canonical representation. No checks 517 or ready calls are performed. */ 518 #define PyUnicode_READ(kind, data, index) \ 519 ((Py_UCS4) \ 520 ((kind) == PyUnicode_1BYTE_KIND ? \ 521 ((const Py_UCS1 *)(data))[(index)] : \ 522 ((kind) == PyUnicode_2BYTE_KIND ? \ 523 ((const Py_UCS2 *)(data))[(index)] : \ 524 ((const Py_UCS4 *)(data))[(index)] \ 525 ) \ 526 )) Here we can see that index, which is negative in our example, is used as an array index. Since it is negative, it will internally wrap around and point to an address BELOW the address of 'data'. So, if a certain negative value (such as -0x7FFFFFFF) is supplied and data[index] will effectively point to an invalid or read-protected page in memory, the Python executable will segfault. But there's more. Instead of making it point to an invalid page, let's make it point to something valid: 1 from json import JSONDecoder 2 j = JSONDecoder() 3 a = "99448866" 4 b = "88445522" 5 diff = id(a) - id(b) 6 print("Difference is " + hex(diff)) 7 print j.raw_decode(b) 8 print j.raw_decode(b, diff) Output of this script is: Difference is -0x30 (88445522, 8) (99448866, -40) The difference between the address of 'a' and the address of 'b' is calculated and supplied as an index to the raw_decode function. Internally the address wraps around and we get to see the contents of 'a' while having supplied 'b' as a parameter. We can use this harvester to scan memory for valid JSON strings: 1 from json import JSONDecoder 2 j = JSONDecoder() 3 a = "x" * 1000 4 for x in range(0, 600000): 5 try: 6 print j.raw_decode(a, 0 - x) 7 except: 8 pass There is one drawback, however. We cannot decode strings in this manner because: 296 static PyObject * 297 scanstring_unicode(PyObject *pystr, Py_ssize_t end, int strict, Py_ssize_t *next_end_ptr) 298 { 299 /* Read the JSON string from PyUnicode pystr. 300 end is the index of the first character after the quote. 301 if strict is zero then literal control characters are allowed 302 *next_end_ptr is a return-by-reference index of the character 303 after the end quote 304 305 Return value is a new PyUnicode 306 */ 307 PyObject *rval = NULL; 308 Py_ssize_t len; 309 Py_ssize_t begin = end - 1; 310 Py_ssize_t next /* = begin */; 311 const void *buf; 312 int kind; 313 PyObject *chunks = NULL; 314 PyObject *chunk = NULL; 315 316 if (PyUnicode_READY(pystr) == -1) 317 return 0; 318 319 len = PyUnicode_GET_LENGTH(pystr); 320 buf = PyUnicode_DATA(pystr); 321 kind = PyUnicode_KIND(pystr); 322 323 if (end < 0 || len < end) { 324 PyErr_SetString(PyExc_ValueError, "end is out of bounds"); 325 goto bail; this code actually performs a bounds check by asserting that end (which is our index) isn't negative. However, I succesfully ran harvesting tests that could extract JSON-encoded arrays of numerical values (such as [10, 20, 40, 70] ) from the process memory without any problem or difficulty. Given the ubiquity of JSON parsing in Python applications and the limited amount of prequisites and conditions under which this bug can be exploited, it is evident that this issue could have serious security implications in some cases. Here is a patch for 3.4.0: --- _json_old.c 2014-04-12 17:47:08.749012372 +0200 +++ _json.c 2014-04-12 17:44:52.253011645 +0200 @@ -941,7 +941,7 @@ kind = PyUnicode_KIND(pystr); length = PyUnicode_GET_LENGTH(pystr); - if (idx >= length) { + if ( idx < 0 || idx >= length) { raise_stop_iteration(idx); return NULL; } And here is a patch for 2.7.6: --- _json_old.c 2014-04-12 17:57:14.365015601 +0200 +++ _json.c 2014-04-12 18:04:25.149017898 +0200 @@ -1491,7 +1491,7 @@ PyObject *res; char *str = PyString_AS_STRING(pystr); Py_ssize_t length = PyString_GET_SIZE(pystr); - if (idx >= length) { + if ( idx < 0 || idx >= length) { PyErr_SetNone(PyExc_StopIteration); return NULL; } @@ -1578,7 +1578,7 @@ PyObject *res; Py_UNICODE *str = PyUnicode_AS_UNICODE(pystr); Py_ssize_t length = PyUnicode_GET_SIZE(pystr); - if (idx >= length) { + if ( idx < 0 || idx >= length) { PyErr_SetNone(PyExc_StopIteration); return NULL; } Here is a script that checks whether the Python binary that executes it is vulnerable: 1 from json import JSONDecoder 2 j = JSONDecoder() 3 4 a = '128931233' 5 b = "472389423" 6 7 if id(a) < id(b): 8 x = a 9 y = b 10 else: 11 x = b 12 y = a 13 14 diff = id(x) - id(y) 15 16 try: 17 j.raw_decode(y, diff) 18 print("Vulnerable") 19 except: 20 print("Not vulnerable") Please let me know what your thoughts on this are and when you think it will be fixed. Thank you. Note: I haven't shared this vulnerability with anyone and I won't do so until the bug has been fixed. Guido Vranken ---------- components: Extension Modules, Library (Lib) messages: 218771 nosy: benjamin.peterson priority: critical severity: normal status: open title: JSON module: reading arbitrary process memory type: security versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 02:42:12 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 19 May 2014 00:42:12 +0000 Subject: [issue21529] JSON module: reading arbitrary process memory In-Reply-To: <1400460059.59.0.206542140717.issue21529@psf.upfronthosting.co.za> Message-ID: <1400460132.17.0.918966687573.issue21529@psf.upfronthosting.co.za> Benjamin Peterson added the comment: http://hg.python.org/cpython/rev/50c07ed1743d http://hg.python.org/cpython/rev/a8facac493ef ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 02:44:06 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 19 May 2014 00:44:06 +0000 Subject: [issue20620] Update the min()/max() docs for the new default argument In-Reply-To: <1392322129.66.0.847659571757.issue20620@psf.upfronthosting.co.za> Message-ID: <1400460246.0.0.118880492579.issue20620@psf.upfronthosting.co.za> Berker Peksag added the comment: Rebased patch. ---------- versions: +Python 3.5 Added file: http://bugs.python.org/file35291/issue20620_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 02:44:21 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 19 May 2014 00:44:21 +0000 Subject: [issue20620] Update the min()/max() docs for the new default argument In-Reply-To: <1392322129.66.0.847659571757.issue20620@psf.upfronthosting.co.za> Message-ID: <1400460261.32.0.432003027627.issue20620@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file34081/issue20620.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 02:45:05 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 19 May 2014 00:45:05 +0000 Subject: [issue21530] Integer overflow in strop Message-ID: <1400460305.46.0.189795458549.issue21530@psf.upfronthosting.co.za> New submission from Benjamin Peterson: (copy paste from security list) """ Integer overflow in strop.expandtabs: Aside: I took a look at python over the weekend as I saw the the Internet Bug Bounty [ https://hackerone.com/python ] are now offering bounties for security bugs + patches for python. It's quite unclear from their site what they consider to be a valid bug under their program (they say 'arbitrary code execution' but I guess just saying "ctypes" would be cheating.) Anyway, here's a bug in a string handling function which might be reachable in some "sandboxed python" environments, and maybe (at a stretch) remotely if someone were to offer "expanding-tabs-in-strings"-as-a-service... Bug: Modules/stropmodule.c static PyObject * strop_expandtabs(PyObject *self, PyObject *args) ... i = j = old_j = 0; e = string + stringlen; for (p = string; p < e; p++) { if (*p == '\t') { j += tabsize - (j%tabsize); if (old_j > j) { PyErr_SetString(PyExc_OverflowError, "new string is too long"); return NULL; } old_j = j; } else { j++; if (*p == '\n') { i += j; <-- missing check here j = 0; } } } ... out = PyString_FromStringAndSize(NULL, i+j); ... i = 0; q = PyString_AS_STRING(out); for (p = string; p < e; p++) { if (*p == '\t') { j = tabsize - (i%tabsize); i += j; while (j-- > 0) *q++ = ' '; } else { *q++ = *p; i++; if (*p == '\n') i = 0; } } ... There's no check preventing i from overflowing, meaning that a string consisting of multiple tabs spread over multiple lines combined with a large tabsize can cause the allocation of an undersized string buffer. With some simple heap manipulation the length of the copy into this buffer can be controlled, and it's pretty easy to corrupt memory in such a way as to gain native code execution: [h1|----------][h2|\t\n\t\n....][h3|----------] h1: PyStringObject header of undersized buffer h2: PyStringObject header of tabstring By grooming the heap such that this allocation pattern is achieved when the expandtabs function starts expanding the h2 string into the h1 inline buffer it will overflow into the string being expanded, overwriting the tabs in the original string with spaces so that the second loop won't expand them anymore. By carefully crafting the string to expand and choosing the tabsize you can limit the extent of the memory corruption to chosen objects. Getting code execution is simply a matter of pointing the ob_type field of the h2 string header to a controlled address with a fake struct _typeobject. The struct contains the following function pointers which will be called when their corrisponing python function is called: destructor tp_dealloc; printfunc tp_print; getattrfunc tp_getattr; setattrfunc tp_setattr; cmpfunc tp_compare; reprfunc tp_repr; Run this email as a script for a very simple crashing PoC for 32-bit python 2.7 which should crash at at address near 0x20202020 (since the ob_type field will be overwritten with spaces.) No idea if the heap manipulation used here will work on other platforms but it should be easy to do. Patch: You've actually already patched this bug in a copy-and-paste version of this function... In fact there seem to be at least three versions of expandtabs; transmogrify.h and stropmodule.c are both vulnerable; stringobject.c isn't. I'm not familiar enough with the code to know when each version will be used. The patch is to use the stringobject.c implementation which does the overflow check correctly, but here's a quick patch (for the 2.7 branch) which will do the job: --- a/Modules/stropmodule.c Sun Mar 30 16:43:11 2014 -0400 +++ b/Modules/stropmodule.c Mon Mar 31 00:36:57 2014 +0200 @@ -624,6 +624,11 @@ } else { j++; if (*p == '\n') { + if (i > PY_SSIZE_T_MAX - j){ + PyErr_SetString(PyExc_OverflowError, + "new string is too long"); + return NULL; + } i += j; j = 0; } Cheers, Ian Beer """ import strop strs = [] for i in range(20): strs.append('\t\n' * 0x10000 + 'A' * 0x1000000) for i in range(20): print hex(id(strs[i])) strs[14] = None strop.expandtabs(strs[15], 0x10001) print strs[15] ---------- components: Extension Modules, Library (Lib) messages: 218774 nosy: benjamin.peterson priority: critical severity: normal status: open title: Integer overflow in strop type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 02:45:40 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 19 May 2014 00:45:40 +0000 Subject: [issue21530] Integer overflow in strop In-Reply-To: <1400460305.46.0.189795458549.issue21530@psf.upfronthosting.co.za> Message-ID: <1400460340.38.0.916251197189.issue21530@psf.upfronthosting.co.za> Benjamin Peterson added the comment: 5dabc2d2f776 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 02:51:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 19 May 2014 00:51:07 +0000 Subject: [issue12387] IDLE save keyboard shortcut problem In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za> Message-ID: <1400460667.87.0.287718124959.issue12387@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Reading the Tk Wiki page, it appears that Shift undoes ShiftLock except on Mac, where it does nothing. So there is effectively only ^a and ^A, etc. Looking as the Get New Keys dialog, the Basic Key Binding Entry pane says "New keys .." plural, but as far as I can tell, only one new key can be entered. Moreover, Control-Key-a and Control-Shift-Key-A are possible, but not Control-Key-A. The latter is only possible with hand entry in the Advanced Key Binding Entry pane. This might be why some functions have a single key binding and some both. Perhaps the dialog should auto-augment Control-Key-x with Control-Key-X, where x is a lowercase letter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 03:28:40 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 19 May 2014 01:28:40 +0000 Subject: [issue19979] Missing nested scope vars in class scope (bis) In-Reply-To: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za> Message-ID: <1400462920.54.0.118006039265.issue19979@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 03:29:23 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 19 May 2014 01:29:23 +0000 Subject: [issue17352] Be clear that __prepare__ must be declared as a class method In-Reply-To: <1362409892.83.0.717786566871.issue17352@psf.upfronthosting.co.za> Message-ID: <1400462963.83.0.909373759242.issue17352@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 03:31:22 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 19 May 2014 01:31:22 +0000 Subject: [issue18334] type(name, bases, dict) does not call metaclass' __prepare__ attribute In-Reply-To: <1372641138.46.0.644775856541.issue18334@psf.upfronthosting.co.za> Message-ID: <1400463082.31.0.063525244911.issue18334@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 03:33:27 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 19 May 2014 01:33:27 +0000 Subject: [issue17421] Drop restriction that meta.__prepare__() must return a dict (subclass) In-Reply-To: <1363292427.77.0.787480674647.issue17421@psf.upfronthosting.co.za> Message-ID: <1400463207.73.0.212913122885.issue17421@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 03:34:10 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 19 May 2014 01:34:10 +0000 Subject: [issue17422] language reference should specify restrictions on class namespace In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za> Message-ID: <1400463250.51.0.453302049673.issue17422@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 03:40:24 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 19 May 2014 01:40:24 +0000 Subject: [issue17044] Implement PEP 422: Simple class initialisation hook In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za> Message-ID: <1400463624.49.0.907987052378.issue17044@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 03:42:43 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 19 May 2014 01:42:43 +0000 Subject: [issue17044] Implement PEP 422: Simple class initialisation hook In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za> Message-ID: <1400463763.13.0.877499926101.issue17044@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 03:57:13 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 19 May 2014 01:57:13 +0000 Subject: [issue21519] IDLE : Bug in keybinding validity check In-Reply-To: <1400392455.89.0.13094614924.issue21519@psf.upfronthosting.co.za> Message-ID: <1400464633.29.0.222732993428.issue21519@psf.upfronthosting.co.za> Terry J. Reedy added the comment: > Now the binding will be assigned to two actions. I do not see this. I only see duplicated, which is bad enough to be patched. What did you leave out ;-). Also see #12387, which we need to finish, and Ned's link to http://wiki.tcl.tk/28331 A patch for KeysOK should include test_bindings.py with class KeysOK_Test. As with the test of name_ok in test_configname.py (sp?), the method should be embedded in a dummy class and use a dummy message box. The problem with the method goes deeper. It is not called if the 'advanced' (hand entry, therefore primitive) pane is used. As near as I can tell (and if I am wrong, please tell me), multiple bindings, which are required to ignore lower-upper case issues, can only be entered with this 'advanced' method. Hence, most new entries are not checked at all. The basic pane, which is advanced in that one can only enter possibly valid combination, should be modified to allow multiple entries. (The two panes should be called 'Easy' and 'Error-prone ;-) As it is, 'keys' is a misnomer[note], "keys.strip()" is a no-op in that 'keys' is auto-generated, and "keySequence = keys.split()" is the same as "keySequence = [keys]"[note]. Many of the tests only test mistakes that can happen with hand-entry, which is not tested. I believe that the duplicate check is the only one needed (except possible for the modifier check, which I have not looked at enough to tell). [note] If the easy pane were modified to define multiple keys, and all were passed at once, then the two noted lines would become valid, but then each key, would have to be tested individually against the flat list. This suggests to me that the flattening should be done just once and that KeysOK should become KeyOK, or rather key_ok. It might even be replaced by "newkey in flat_list" or something nearly that simple. ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 04:58:18 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 19 May 2014 02:58:18 +0000 Subject: [issue19979] Missing nested scope vars in class scope (bis) In-Reply-To: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za> Message-ID: <1400468298.8.0.554331283587.issue19979@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #17853 was in the context of metaclasses. Even so, I am puzzled by the opening statement there that from enum import Enum # I added this as necessary class Season(Enum): SPRING = Season() "works beautifully" at top level as it indeed raises NameError: name 'Season' is not defined My point here is that changing the output of n=1 def f(n=2): class A: n=n return A print(f().n) from 1, as it has been from the beginning (except for the print change) to 2, which I believe is implied in the request, is not the sort of syntax change we do. Hence I think this should be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 05:08:20 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 19 May 2014 03:08:20 +0000 Subject: [issue19979] Missing nested scope vars in class scope (bis) In-Reply-To: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za> Message-ID: <1400468900.39.0.201599610046.issue19979@psf.upfronthosting.co.za> Ethan Furman added the comment: Terry remarked: --------------- > I am puzzled by the opening statement there that > > from enum import Enum # I added this as necessary > class Season(Enum): > SPRING = Season() > > "works beautifully" at top level as it indeed raises > NameError: name 'Season' is not defined Pay close attention to the line just before that example: > I tried having the metaclass insert an object into the custom dict > (aka namespace) returned by __prepare__; this object has the same > name as the to-be-created class. It does not raise a NameError because the name was injected via the metaclass __prepare__ method. (Or did at that time -- I don't think that bit of cleverness made the final cut.) As far as this enhancement request goes, I think the compatibility break is likely too large to have it in the 3.x series. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 05:28:21 2014 From: report at bugs.python.org (Tony Gedge) Date: Mon, 19 May 2014 03:28:21 +0000 Subject: [issue21531] Sending a zero-length UDP packet to asyncore invokes handle_close() Message-ID: <1400470101.73.0.899149180495.issue21531@psf.upfronthosting.co.za> New submission from Tony Gedge: Sending a zero-length UDP packet to asyncore closes socket by default. The default implementation of recv() assumes that zero-length data means close. This isn't true for UDP - it is possible to send a zero-length payload packet. A possible work-around is to overload handle_close() and not call self.close(). However, as handle_close() is called as part of exception handling, we can't determine whether the handle_close() is happening due to a zero-length payload or an exception event. It should be possible to process a zero-length payload UDP packet. ---------- components: Library (Lib) messages: 218780 nosy: Tony.Gedge priority: normal severity: normal status: open title: Sending a zero-length UDP packet to asyncore invokes handle_close() type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 07:42:15 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 19 May 2014 05:42:15 +0000 Subject: [issue21532] 2.7.7rc1 msi is lacking libpython27.a Message-ID: <1400478135.47.0.49178894487.issue21532@psf.upfronthosting.co.za> New submission from Martin v. L?wis: The 32-bit installer should include libpython27.a, the import library in GNU ld format. To build it, cygwin must be installed and on PATH when the MSI is built. The file will end up in libs/libpython27.a ---------- components: Windows messages: 218781 nosy: loewis, steve.dower priority: normal severity: normal status: open title: 2.7.7rc1 msi is lacking libpython27.a _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 09:48:07 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 May 2014 07:48:07 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <1400485687.61.0.785138616737.issue12546@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand why it works with "<", "=" or ">": >>> "{0:\x00<6d}".format(123) '123\x00\x00\x00' But not without: >>> "{0:\x006d}".format(123) Traceback (most recent call last): File "", line 1, in ValueError: Invalid format specifier Compare it to: >>> "{0:6d}".format(123) ' 123' >>> "{0:06d}".format(123) '000123' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 09:55:59 2014 From: report at bugs.python.org (Armin Rigo) Date: Mon, 19 May 2014 07:55:59 +0000 Subject: [issue19979] Missing nested scope vars in class scope (bis) In-Reply-To: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za> Message-ID: <1400486159.5.0.31970691822.issue19979@psf.upfronthosting.co.za> Armin Rigo added the comment: Terry: I meant exactly what I wrote, and not some unrelated examples: def f(): n = 1 class A: n = n doesn't work, but the same two lines ("n = 1"; "class A: n = n") work if written at module level instead of in a function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 10:10:15 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Mon, 19 May 2014 08:10:15 +0000 Subject: [issue21533] built-in types dict docs - construct dict from iterable, not iterator Message-ID: <1400487015.16.0.760931173475.issue21533@psf.upfronthosting.co.za> New submission from Wolfgang Maier: The docs for Python3.4 havethis to say about the arguments to the dict constructor: class dict(**kwarg) class dict(mapping, **kwarg) class dict(iterable, **kwarg) Return a new dictionary initialized from an optional positional argument and a possibly empty set of keyword arguments. If no positional argument is given, an empty dictionary is created. If a positional argument is given and it is a mapping object, a dictionary is created with the same key-value pairs as the mapping object. Otherwise, the positional argument must be an iterator object. Each item in the iterable must itself be an iterator with exactly two objects. The first object of each item becomes a key in the new dictionary, and the second object the corresponding value. If a key occurs more than once, the last value for that key becomes the corresponding value in the new dictionary. This paragraph uses the term iterator twice when it should talk about an iterable instead. I'm attaching the patch for this. Best, Wolfgang ---------- assignee: docs at python components: Documentation files: dict_doc.patch keywords: patch messages: 218784 nosy: docs at python, wolma priority: normal severity: normal status: open title: built-in types dict docs - construct dict from iterable, not iterator Added file: http://bugs.python.org/file35292/dict_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 10:13:20 2014 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 19 May 2014 08:13:20 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <1400487200.49.0.447426941402.issue12546@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 11:20:38 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 19 May 2014 09:20:38 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1400491238.03.0.842372821658.issue21304@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Some comments: * Python 2.7 ships with OpenSSL 0.9.8 on Windows, so the Python version will always get used on that platform, so it needs to be fast. * The iterations loop should use xrange instead of range * The .encode('ascii') in _long_to_bin() is not necessary in Python 2 * Given that _long_to_bin() and _bin_to_long() are only used once in the function, it's better to inline the code directly. * bytes(buffer()) should not be necessary in Python 2, since objects with a buffer interface will usually also implement the tp_str slot used by bytes(). ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 12:24:15 2014 From: report at bugs.python.org (Christian Heimes) Date: Mon, 19 May 2014 10:24:15 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1400495055.98.0.706261984894.issue21304@psf.upfronthosting.co.za> Christian Heimes added the comment: Sorry that I join the party rather late. How about you take my back port from https://bitbucket.org/tiran/backports.pbkdf2/ and remove all Python 3.x related code? :) I spent a lot of time to make the code as fast as possible. ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Mon May 19 12:34:03 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 19 May 2014 12:34:03 +0200 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1400495055.98.0.706261984894.issue21304@psf.upfronthosting.co.za> References: <1400495055.98.0.706261984894.issue21304@psf.upfronthosting.co.za> Message-ID: <5379DE1B.9010407@egenix.com> On 19.05.2014 12:24, Christian Heimes wrote: > > How about you take my back port from https://bitbucket.org/tiran/backports.pbkdf2/ and remove all Python 3.x related code? :) I spent a lot of time to make the code as fast as possible. Could you perhaps compare this to the proposed patch ? -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Mon May 19 12:34:07 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 19 May 2014 10:34:07 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1400495055.98.0.706261984894.issue21304@psf.upfronthosting.co.za> Message-ID: <5379DE1B.9010407@egenix.com> Marc-Andre Lemburg added the comment: On 19.05.2014 12:24, Christian Heimes wrote: > > How about you take my back port from https://bitbucket.org/tiran/backports.pbkdf2/ and remove all Python 3.x related code? :) I spent a lot of time to make the code as fast as possible. Could you perhaps compare this to the proposed patch ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 13:10:26 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Mon, 19 May 2014 11:10:26 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1400497826.25.0.171691741387.issue14776@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Hi, I'd like to take this over after Dave Malcolm. I don't see any issues that haven't been resolved, so my question is: What else can I do to make this patch acceptable? I'm attaching a rebased version of this patch that applies to current default branch (FWIW, we use this patch downstream in Fedora in our python3-debug build and it works well) ---------- Added file: http://bugs.python.org/file35293/cpython-systemtap-2014-05-19.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 13:14:37 2014 From: report at bugs.python.org (Pavel Aslanov) Date: Mon, 19 May 2014 11:14:37 +0000 Subject: [issue14710] pkgutil.get_loader is broken In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1400498077.11.0.155830172287.issue14710@psf.upfronthosting.co.za> Pavel Aslanov added the comment: This function is broken again in version 3.4 The way it should look is: Python 2.7.6 (default, Feb 26 2014, 12:07:17) [GCC 4.8.2 20140206 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pkgutil >>> pkgutil.get_loader('no_such_module') # returns None >>> How it really looks: Python 3.4.0 (default, Apr 27 2014, 23:33:09) [GCC 4.8.2 20140206 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pkgutil >>> pkgutil.get_loader('no_such_module') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/pkgutil.py", line 467, in get_loader return find_loader(fullname) File "/usr/lib/python3.4/pkgutil.py", line 488, in find_loader return spec.loader AttributeError: 'NoneType' object has no attribute 'loader' >>> find_loader is at fault (change "return spec.loader" -> "return spec and spec.loader"). Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 14:53:14 2014 From: report at bugs.python.org (Inndy) Date: Mon, 19 May 2014 12:53:14 +0000 Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8 In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za> Message-ID: <1400503994.13.0.720778758954.issue7856@psf.upfronthosting.co.za> Inndy added the comment: I'm Taiwanese, F9D8 in big5 should be mapped to E8A38F in UTF-8. ---------- nosy: +Inndy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 15:24:17 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 19 May 2014 13:24:17 +0000 Subject: [issue21528] Fix a number of typos in the documentation In-Reply-To: <1400456947.04.0.361173205763.issue21528@psf.upfronthosting.co.za> Message-ID: <1400505857.43.0.682196255492.issue21528@psf.upfronthosting.co.za> Georg Brandl added the comment: Looks all good to me. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 15:41:39 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 19 May 2014 13:41:39 +0000 Subject: [issue21534] 404 on documentation download links Message-ID: <1400506899.65.0.0656735087144.issue21534@psf.upfronthosting.co.za> New submission from Zachary Ware: docs@ has received several reports from people unable to download documentation from docs.python.org/[23]/download.html since the release of 3.4.1rc1 and 2.7.7rc1. ---------- assignee: docs at python components: Documentation messages: 218792 nosy: benjamin.peterson, docs at python, georg.brandl, larry, zach.ware priority: high severity: normal status: open title: 404 on documentation download links type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 16:15:01 2014 From: report at bugs.python.org (Dave Malcolm) Date: Mon, 19 May 2014 14:15:01 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1400497826.25.0.171691741387.issue14776@psf.upfronthosting.co.za> Message-ID: <1400508756.22162.177.camel@surprise> Dave Malcolm added the comment: On Mon, 2014-05-19 at 11:10 +0000, Bohuslav "Slavek" Kabrda wrote: > Bohuslav "Slavek" Kabrda added the comment: > > Hi, > I'd like to take this over after Dave Malcolm. I don't see any issues that haven't been resolved, so my question is: What else can I do to make this patch acceptable? > I'm attaching a rebased version of this patch that applies to current default branch (FWIW, we use this patch downstream in Fedora in our python3-debug build and it works well) > > ---------- > Added file: http://bugs.python.org/file35293/cpython-systemtap-2014-05-19.patch Is this attachment missing the "instrumentation.rst"? There are also a couple of example scripts we ship in the RPMs, iirc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 16:25:13 2014 From: report at bugs.python.org (Dave Malcolm) Date: Mon, 19 May 2014 14:25:13 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1400508756.22162.177.camel@surprise> Message-ID: <1400509365.22162.178.camel@surprise> Dave Malcolm added the comment: On Mon, 2014-05-19 at 14:15 +0000, Dave Malcolm wrote: > Dave Malcolm added the comment: > > On Mon, 2014-05-19 at 11:10 +0000, Bohuslav "Slavek" Kabrda wrote: > > Bohuslav "Slavek" Kabrda added the comment: > > > > Hi, > > I'd like to take this over after Dave Malcolm. I don't see any issues that haven't been resolved, so my question is: What else can I do to make this patch acceptable? > > I'm attaching a rebased version of this patch that applies to current default branch (FWIW, we use this patch downstream in Fedora in our python3-debug build and it works well) > > > > ---------- > > Added file: http://bugs.python.org/file35293/cpython-systemtap-2014-05-19.patch > > Is this attachment missing the "instrumentation.rst"? FWIW I see it within http://bugs.python.org/file26074/cpython-systemtap-2012-06-21-001.patch > There are also a couple of example scripts we ship in the RPMs, iirc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 16:26:29 2014 From: report at bugs.python.org (Ankur Ankan) Date: Mon, 19 May 2014 14:26:29 +0000 Subject: [issue19217] Calling assertEquals for moderately long list takes too long In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za> Message-ID: <1400509589.3.0.802842578939.issue19217@psf.upfronthosting.co.za> Changes by Ankur Ankan : ---------- nosy: +ankurankan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 16:33:15 2014 From: report at bugs.python.org (Ankur Ankan) Date: Mon, 19 May 2014 14:33:15 +0000 Subject: [issue19217] Calling assertEquals for moderately long list takes too long In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za> Message-ID: <1400509995.87.0.761361243446.issue19217@psf.upfronthosting.co.za> Changes by Ankur Ankan : ---------- nosy: +Ankur.Ankan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 16:41:50 2014 From: report at bugs.python.org (Matthias Klose) Date: Mon, 19 May 2014 14:41:50 +0000 Subject: [issue21535] test_license_exists_at_url fails with 3.4.1, wrong/unexpected http error code Message-ID: <1400510510.74.0.19030338165.issue21535@psf.upfronthosting.co.za> New submission from Matthias Klose: ====================================================================== FAIL: test_license_exists_at_url (test.test_site.ImportSideEffectTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/scratch/packages/python/3.4/python3.4-3.4.1/Lib/test/test_site.py", line 438, in test_license_exists_at_url self.assertEqual(code, 200, msg="Can't find " + url) AssertionError: 404 != 200 : Can't find http://www.python.org/download/releases/3.4.1/license ---------- components: Tests messages: 218795 nosy: doko priority: normal severity: normal status: open title: test_license_exists_at_url fails with 3.4.1, wrong/unexpected http error code versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 17:05:15 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Mon, 19 May 2014 15:05:15 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1400511915.91.0.639072220057.issue14776@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: As usual, I forgot to hg add the new files before running hg diff, so the newly created files didn't get added to the patch. Attaching a fixed version that hopefully has everything. AFAICS all the scripts that Fedora has are 1:1 copy of documentation in instrumentation.rst, so I don't think it's necessary to add them here (there are enough files attached here already ;)). ---------- Added file: http://bugs.python.org/file35294/cpython-systemtap-2014-05-19-all-files.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 17:15:04 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 19 May 2014 15:15:04 +0000 Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za> Message-ID: <1400512504.8.0.401769919752.issue12546@psf.upfronthosting.co.za> Eric V. Smith added the comment: For int, the spec is: [[fill]align][sign][#][0][width][,][.precision][type] So, for "06d", "0" is matched as the literal 0, "6" is matched as width, and "d" is matched as type. For "\x00<6d", "\x00" is matched as fill, "<" as align, "6" as width, and "d" as type. For "\x006d", there's no align. So "\x00" cannot match as fill. "\x00" doesn't match anything else, so it's an invalid format specifier, thus the exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 17:16:40 2014 From: report at bugs.python.org (Steve Dower) Date: Mon, 19 May 2014 15:16:40 +0000 Subject: [issue21532] 2.7.7rc1 msi is lacking libpython27.a In-Reply-To: <1400478135.47.0.49178894487.issue21532@psf.upfronthosting.co.za> Message-ID: <1400512600.17.0.925515197833.issue21532@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks for catching this. Do I need a specific version of Cygwin or will the latest version suffice? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 17:16:58 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 19 May 2014 15:16:58 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1400512618.96.0.308013182235.issue14776@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 17:52:39 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Mon, 19 May 2014 15:52:39 +0000 Subject: [issue21531] Sending a zero-length UDP packet to asyncore invokes handle_close() In-Reply-To: <1400470101.73.0.899149180495.issue21531@psf.upfronthosting.co.za> Message-ID: <1400514759.21.0.999475007688.issue21531@psf.upfronthosting.co.za> Changes by Santoso Wijaya : ---------- nosy: +santa4nt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 18:11:00 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 19 May 2014 16:11:00 +0000 Subject: [issue21531] Sending a zero-length UDP packet to asyncore invokes handle_close() In-Reply-To: <1400470101.73.0.899149180495.issue21531@psf.upfronthosting.co.za> Message-ID: <1400515860.78.0.814442877554.issue21531@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: That doesn't surprise me as asyncore does not natively support UDP protocol in the first place. ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 18:16:25 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 19 May 2014 16:16:25 +0000 Subject: [issue21532] 2.7.7rc1 msi is lacking libpython27.a In-Reply-To: <1400478135.47.0.49178894487.issue21532@psf.upfronthosting.co.za> Message-ID: <1400516185.23.0.094565742556.issue21532@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think any version should do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 19:21:25 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 19 May 2014 17:21:25 +0000 Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8 In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za> Message-ID: <1400520085.35.0.577174153966.issue7856@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm still looking for an official source of that. >>> u"\u88cf".encode("big5hkscs") '\xf9\xd8' works fine (and always has been working fine), and the character clearly is in big5hkscs. According to http://en.wikipedia.org/wiki/Big5 F9D8 is "Reserved for user-defined characters", so this suggests that the character does *not* have a fixed meaning in BIG-5. However, it is part of the Hong Kong Supplementary Character Set. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 19:42:31 2014 From: report at bugs.python.org (Steve Dower) Date: Mon, 19 May 2014 17:42:31 +0000 Subject: [issue21532] 2.7.7rc1 msi is lacking libpython27.a In-Reply-To: <1400478135.47.0.49178894487.issue21532@psf.upfronthosting.co.za> Message-ID: <1400521351.78.0.778040294839.issue21532@psf.upfronthosting.co.za> Steve Dower added the comment: I installed mingw32-binutils and it seems to work fine. 2.7.7 will have the file again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 19:46:34 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 19 May 2014 17:46:34 +0000 Subject: [issue14710] pkgutil.get_loader is broken In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1400521594.66.0.118331100936.issue14710@psf.upfronthosting.co.za> Brett Cannon added the comment: I'll take a look the next time I have some Python time (in a week or two) and make sure this gets dealt with. ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 19:50:57 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 19 May 2014 17:50:57 +0000 Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8 In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za> Message-ID: <1400521857.31.0.113386566405.issue7856@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Inndy, you might also be talking about big5-2003, from http://www.csie.ntu.edu.tw/~r92030/project/big5/ Python currently does not support big5-2003, but a contribution of such an encoding would surely be welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 20:46:14 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 19 May 2014 18:46:14 +0000 Subject: [issue21529] JSON module: reading arbitrary process memory In-Reply-To: <1400460059.59.0.206542140717.issue21529@psf.upfronthosting.co.za> Message-ID: <1400525174.1.0.872912239911.issue21529@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 20:46:17 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 19 May 2014 18:46:17 +0000 Subject: [issue21535] test_license_exists_at_url fails with 3.4.1, wrong/unexpected http error code In-Reply-To: <1400510510.74.0.19030338165.issue21535@psf.upfronthosting.co.za> Message-ID: <1400525177.54.0.271160899174.issue21535@psf.upfronthosting.co.za> Berker Peksag added the comment: This is probably related to issue 21534. ---------- nosy: +berker.peksag, larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 20:50:02 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 19 May 2014 18:50:02 +0000 Subject: [issue21536] extension built with a shared python cannot be loaded with a static python Message-ID: <1400525402.57.0.75792320709.issue21536@psf.upfronthosting.co.za> New submission from Antoine Pitrou: When a C extension is built (using distutils) with a shared library Python, it cannot be loaded with an otherwise identical statically linked Python. The other way round works fine. Trivial example using the _ssl module: >>> import sys >>> sys.path.insert(0, '/home/antoine/cpython/shared/build/lib.linux-x86_64-3.5/') >>> import _ssl Traceback (most recent call last): File "", line 1, in ImportError: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory This is probably because of an additional -L flag that is passed when linking a C extension with a shared library Python. I don't think the flag is useful under Linux (or perhaps under any other OS at all), since the relevant symbols are already loaded when the interpreter tries to load the C extension. (AFAIK, systems notorious for providing shared library Pythons are RedHat-alike systems, while Debian/Ubuntu provide statically linked Pythons) ---------- components: Library (Lib) messages: 218806 nosy: dstufft, eric.araujo, loewis, ncoghlan, pitrou priority: normal severity: normal status: open title: extension built with a shared python cannot be loaded with a static python type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 20:51:59 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 19 May 2014 18:51:59 +0000 Subject: [issue21530] Integer overflow in strop In-Reply-To: <1400460305.46.0.189795458549.issue21530@psf.upfronthosting.co.za> Message-ID: <1400525519.31.0.96703144595.issue21530@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 20:54:21 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 19 May 2014 18:54:21 +0000 Subject: [issue21529] JSON module: reading arbitrary process memory In-Reply-To: <1400460059.59.0.206542140717.issue21529@psf.upfronthosting.co.za> Message-ID: <1400525661.58.0.528252476001.issue21529@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Fixed also in 3.2 (b9913eb96643), 3.3 (4f15bd1ab28f), 3.4 (7b95540ced5c) and 3.5 (3a414c709f1f). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 20:58:59 2014 From: report at bugs.python.org (Stephen Paul Chappell) Date: Mon, 19 May 2014 18:58:59 +0000 Subject: [issue21537] functools.lru_cache does not cache exceptions Message-ID: <1400525939.56.0.613557499448.issue21537@psf.upfronthosting.co.za> New submission from Stephen Paul Chappell: While examining the implementation for lru_cache, it came to my attention that the wrappers ignore the possibility of exceptions. Is this on purpose? If the cache is designed to reduce the overhead of running certain functions, it seems like lru_cache should handle returned values along with raised exceptions. ---------- components: Library (Lib) messages: 218808 nosy: Zero priority: normal severity: normal status: open title: functools.lru_cache does not cache exceptions type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 21:07:59 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 19 May 2014 19:07:59 +0000 Subject: [issue14710] pkgutil.get_loader is broken In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1400526479.37.0.259604964202.issue14710@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 21:15:20 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 19 May 2014 19:15:20 +0000 Subject: [issue21536] extension built with a shared python cannot be loaded with a static python In-Reply-To: <1400525402.57.0.75792320709.issue21536@psf.upfronthosting.co.za> Message-ID: <1400526920.11.0.990845736539.issue21536@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, it's not a -L flag but a -l flag. Removing the "-lpython3.5m" flag from the linker line works fine under Linux, and allows the resulting extension to be loaded with both a shared libary Python and a statically-linked Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 21:44:30 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 May 2014 19:44:30 +0000 Subject: [issue21537] functools.lru_cache does not cache exceptions In-Reply-To: <1400525939.56.0.613557499448.issue21537@psf.upfronthosting.co.za> Message-ID: <1400528670.32.0.361813029995.issue21537@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Is this on purpose? The short answer is yes. It is a can of worms and there isn't much of a payoff. ---------- nosy: +rhettinger resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 21:48:52 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 May 2014 19:48:52 +0000 Subject: [issue21507] memory used by frozenset created from set differs from that of frozenset created from other iterable In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400528932.26.0.789018260797.issue21507@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 21:52:06 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 May 2014 19:52:06 +0000 Subject: [issue21507] memory used by frozenset created from set differs from that of frozenset created from other iterable In-Reply-To: <1400070772.56.0.315189597778.issue21507@psf.upfronthosting.co.za> Message-ID: <1400529126.91.0.402060632647.issue21507@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 21:55:14 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 May 2014 19:55:14 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400529314.84.0.481444852447.issue2506@psf.upfronthosting.co.za> Raymond Hettinger added the comment: There has been no activity on this for several year. Marking as rejected for the reasons originally listed. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 21:57:23 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 May 2014 19:57:23 +0000 Subject: [issue21484] More clarity needed about difference between "x += e" and "x = x + e" In-Reply-To: <1399913881.84.0.586979222354.issue21484@psf.upfronthosting.co.za> Message-ID: <1400529443.85.0.248410530983.issue21484@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I agree with Josh. If anything this belongs in a wiki entry, faq page, or stack overflow question. ---------- nosy: +rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 22:05:09 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 19 May 2014 20:05:09 +0000 Subject: [issue21536] extension built with a shared python cannot be loaded with a static python In-Reply-To: <1400525402.57.0.75792320709.issue21536@psf.upfronthosting.co.za> Message-ID: <1400529909.36.0.298901445127.issue21536@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think you are right. It would IMO be useful to research a few comparable systems. E.g. Apache modules don't link a shared library, but still refer to apr_ functions as undefined symbols - but then, there isn't an APR shared library in the first place (at least not on Debian - how about Redhat?) PHP might be close to our case: Debian includes a libphp5.so (in /usr/lib/php5), yet neither /usr/bin/php5 nor the Apache libphp5.so link against it, and all the PHP modules (in /usr/lib/php5/20100525+lfs/) don't link with the shared library - on Debian. I wonder how it is on systems that actually use the PHP shared library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 22:26:31 2014 From: report at bugs.python.org (Ned Batchelder) Date: Mon, 19 May 2014 20:26:31 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400531191.31.0.956656943167.issue2506@psf.upfronthosting.co.za> Ned Batchelder added the comment: Raymond, thanks for keeping us honest! I am still hoping to convince people that this is a good idea. I think Guido's +1 (https://mail.python.org/pipermail/python-dev/2012-December/123099.html) should help in that regard. Part of your reason for today's rejection is the lack of activity. Can I assume that with a patch you would be supportive? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 22:30:37 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 19 May 2014 20:30:37 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1400531437.27.0.190639915255.issue14776@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I would like to point out that if this patch gets accepted, maybe issue #13405 (updated, I keep an up to date version in my mercurial repo) should too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 22:34:59 2014 From: report at bugs.python.org (Trip Volpe) Date: Mon, 19 May 2014 20:34:59 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400531699.38.0.990814440342.issue2506@psf.upfronthosting.co.za> Trip Volpe added the comment: I found this issue just the other day while researching why we were getting false gaps in our test coverage reports (using Ned's coverage module, natch!). I agree that this seems like a fairly minor nuisance, but it's a nuisance that anybody who has tests and measures test coverage will run into sooner or later -- and that's *everybody*, right? I think some kind of fix ought to be discussed. After all, "it should be possible to have accurate coverage results" is a proposition that seems fairly reasonable to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 22:37:13 2014 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 19 May 2014 20:37:13 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400531833.14.0.110427687076.issue2506@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 22:49:58 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 19 May 2014 20:49:58 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1400532598.05.0.990217622535.issue14776@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I still wish there was a patch that combined both dtrace and systemtap support, und used as much code sharing between them as feasible. I'd be +1 on such a patch, and -0 on two separate patches that achieve the same functionality, but on different code paths. For example, the systemtap version has a helper function get_frame_marker_info that covers more cases than the dtrace version; OTOH, the dtrace version has more trace points. If consensus on functionality is not easily achieved, I propose to have the intersection on functionality first, i.e. only use the function-entry/exit trace points even in the dtrace version. Or else you agree on what trace points both systems ought to provide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 23:21:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 19 May 2014 21:21:34 +0000 Subject: [issue20620] Update the min()/max() docs for the new default argument In-Reply-To: <1392322129.66.0.847659571757.issue20620@psf.upfronthosting.co.za> Message-ID: <3gXY7d6GNwz7Ljc@mail.python.org> Roundup Robot added the comment: New changeset b60258f4499c by Raymond Hettinger in branch '3.4': Issue 20620: Update the min()/max() docs for the new default argument. http://hg.python.org/cpython/rev/b60258f4499c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 23:22:15 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 May 2014 21:22:15 +0000 Subject: [issue20620] Update the min()/max() docs for the new default argument In-Reply-To: <1392322129.66.0.847659571757.issue20620@psf.upfronthosting.co.za> Message-ID: <1400534535.12.0.808859450591.issue20620@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the patch. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 23:49:26 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 19 May 2014 21:49:26 +0000 Subject: [issue21535] test_license_exists_at_url fails with 3.4.1, wrong/unexpected http error code In-Reply-To: <1400510510.74.0.19030338165.issue21535@psf.upfronthosting.co.za> Message-ID: <1400536166.13.0.334016781534.issue21535@psf.upfronthosting.co.za> Ned Deily added the comment: The license file page for 3.4.1 now exists. ---------- nosy: +ned.deily stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 23:49:44 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 19 May 2014 21:49:44 +0000 Subject: [issue21535] test_license_exists_at_url fails with 3.4.1, wrong/unexpected http error code In-Reply-To: <1400510510.74.0.19030338165.issue21535@psf.upfronthosting.co.za> Message-ID: <1400536184.09.0.436940116823.issue21535@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 19 23:59:33 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 19 May 2014 21:59:33 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1400536773.19.0.991050391197.issue7776@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 00:08:52 2014 From: report at bugs.python.org (John Lehr) Date: Mon, 19 May 2014 22:08:52 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist Message-ID: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> New submission from John Lehr: plistlib has key error when attempting to load the iOS7 var/mobile/Applications/com.apple.mobilesafari/Library/Safari/History.plist. No detected issues with other iOS7 plists. In [8]: with open('cases/vitale_test_iphone/unback/AppDomain-com.apple.mobilesafari/Library/Safari/History.plist', 'rb') as f: ...: plist = plistlib.lo plistlib.load plistlib.loads ...: plist = plistlib.load(f) ...: --------------------------------------------------------------------------- KeyError Traceback (most recent call last) in () 1 with open('cases/vitale_test_iphone/unback/AppDomain-com.apple.mobilesafari/Library/Safari/History.plist', 'rb') as f: ----> 2 plist = plistlib.load(f) 3 /usr/lib/python3.4/plistlib.py in load(fp, fmt, use_builtin_types, dict_type) 993 p = _FORMATS[fmt]['parser'](use_builtin_types=use_builtin_types) 994 --> 995 return p.parse(fp) 996 997 /usr/lib/python3.4/plistlib.py in parse(self, fp) 620 ) = struct.unpack('>6xBBQQQ', trailer) 621 self._fp.seek(offset_table_offset) --> 622 offset_format = '>' + _BINARY_FORMAT[offset_size] * num_objects 623 self._ref_format = _BINARY_FORMAT[self._ref_size] 624 self._object_offsets = struct.unpack( KeyError: 3 ---------- messages: 218821 nosy: slo.sleuth priority: normal severity: normal status: open title: plistlib unable to load iOS7 Safari History.plist type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 00:27:31 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 19 May 2014 22:27:31 +0000 Subject: [issue10510] distutils upload/register should use CRLF in HTTP requests In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za> Message-ID: <1400538451.06.0.78182354411.issue10510@psf.upfronthosting.co.za> ?ric Araujo added the comment: Patch looks good, will apply. Thanks. ---------- stage: needs patch -> commit review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 00:33:07 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Mon, 19 May 2014 22:33:07 +0000 Subject: [issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks In-Reply-To: <1400099572.93.0.56172954955.issue21509@psf.upfronthosting.co.za> Message-ID: <1400538787.32.0.551966025115.issue21509@psf.upfronthosting.co.za> Santoso Wijaya added the comment: I think you should use codecs.BOM_UTF8 rather than using hardcoded string "\xef\xbb\xbf" directly. And why special casing UTF-8 while we're at it? What about other encodings and their BOMs? ---------- nosy: +santa4nt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 00:38:22 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Mon, 19 May 2014 22:38:22 +0000 Subject: [issue21386] ipaddress.IPv4Address.is_global not implemented In-Reply-To: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za> Message-ID: <1400539102.87.0.090309114826.issue21386@psf.upfronthosting.co.za> Changes by Santoso Wijaya : ---------- nosy: +santa4nt type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 00:45:15 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 19 May 2014 22:45:15 +0000 Subject: [issue20620] Update the min()/max() docs for the new default argument In-Reply-To: <1392322129.66.0.847659571757.issue20620@psf.upfronthosting.co.za> Message-ID: <1400539515.41.0.469537306118.issue20620@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 01:18:52 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 19 May 2014 23:18:52 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400541532.12.0.955197684911.issue21538@psf.upfronthosting.co.za> Ned Deily added the comment: Can you attach a zipped version of the failing plist or at least identify what data in it is causing the exception? Presumably that plist is user-specific, i.e. contains browser history. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 02:09:57 2014 From: report at bugs.python.org (John Lehr) Date: Tue, 20 May 2014 00:09:57 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400541532.12.0.955197684911.issue21538@psf.upfronthosting.co.za> Message-ID: John Lehr added the comment: I have shared the file for which I have permission, but neither of two History.plists in my possession will load, both with the same traceback. Thank you. On Mon, May 19, 2014 at 4:18 PM, Ned Deily wrote: > > Ned Deily added the comment: > > Can you attach a zipped version of the failing plist or at least identify > what data in it is causing the exception? Presumably that plist is > user-specific, i.e. contains browser history. > > ---------- > nosy: +ned.deily > > _______________________________________ > Python tracker > > _______________________________________ > ---------- Added file: http://bugs.python.org/file35295/History.plist.7z _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: History.plist.7z Type: application/x-7z-compressed Size: 37004 bytes Desc: not available URL: From report at bugs.python.org Tue May 20 02:21:36 2014 From: report at bugs.python.org (Josiah Carlson) Date: Tue, 20 May 2014 00:21:36 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1400545296.53.0.874041100831.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: First off, thank you everyone who has reviewed and commented so far. I very much appreciate your input and efforts. Does anyone have questions, comments, or concerns about the patch? If no one mentions anything in the next week or so, I'll ping the email thread. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 02:32:48 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 20 May 2014 00:32:48 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400545968.12.0.762316938065.issue21538@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Library (Lib) nosy: +ronaldoussoren, serhiy.storchaka -ned.deily type: crash -> versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 02:45:50 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 20 May 2014 00:45:50 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400546750.14.0.869346330573.issue21538@psf.upfronthosting.co.za> Changes by Ned Deily : Removed file: http://bugs.python.org/file35295/History.plist.7z _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 02:51:46 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 20 May 2014 00:51:46 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400547106.09.0.86310716268.issue21538@psf.upfronthosting.co.za> Ned Deily added the comment: John, a quick look at the file shows that it contains browsing history information that might be personally identifiable. I don't think that is appropriate to store on a public web site like this one so I've deleted the file. Is there some way to provide a simpler file with non-personal history? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 03:37:47 2014 From: report at bugs.python.org (Tony Gedge) Date: Tue, 20 May 2014 01:37:47 +0000 Subject: [issue21531] Sending a zero-length UDP packet to asyncore invokes handle_close() In-Reply-To: <1400470101.73.0.899149180495.issue21531@psf.upfronthosting.co.za> Message-ID: <1400549867.18.0.614033378467.issue21531@psf.upfronthosting.co.za> Tony Gedge added the comment: If it's true that asyncore doesn't support UDP, I'd suggest at least a statement to this effect in the documentation. As far as I can see, there's nothing to suggest it won't work with UDP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 04:17:01 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 20 May 2014 02:17:01 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400552221.59.0.312278057307.issue2506@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Trip, see msg140290, which was ignored. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 04:56:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 20 May 2014 02:56:54 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <3gXhZX6vj2z7LjS@mail.python.org> Roundup Robot added the comment: New changeset 33a39dfc239e by Terry Jan Reedy in branch '2.7': Issue #21477: idle htests - lower case function names, other cleanups. http://hg.python.org/cpython/rev/33a39dfc239e New changeset 7c70198ec48e by Terry Jan Reedy in branch '3.4': Issue #21477: idle htests - lower case function names, other cleanups. http://hg.python.org/cpython/rev/7c70198ec48e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 05:13:01 2014 From: report at bugs.python.org (tholzer) Date: Tue, 20 May 2014 03:13:01 +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: <1400555581.89.0.479622645828.issue20611@psf.upfronthosting.co.za> tholzer added the comment: We encountered the same problem, this is in the context of using PyQt (specifically QProcess) or twisted. They both rely on SIGCHLD for their notification framework. I've attached a httplib EINTR patch for 2.6.4 & 2.7.3. ---------- nosy: +tholzer Added file: http://bugs.python.org/file35296/httplib_2.6.4_eintr_patch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 05:13:37 2014 From: report at bugs.python.org (tholzer) Date: Tue, 20 May 2014 03:13:37 +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: <1400555617.23.0.888184702887.issue20611@psf.upfronthosting.co.za> Changes by tholzer : Added file: http://bugs.python.org/file35297/httplib_2.7.3_eintr_patch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 05:53:56 2014 From: report at bugs.python.org (Jim Garrison) Date: Tue, 20 May 2014 03:53:56 +0000 Subject: [issue21539] pathlib's Path.mkdir() should allow for "mkdir -p" functionality Message-ID: <1400558036.91.0.766972225791.issue21539@psf.upfronthosting.co.za> New submission from Jim Garrison: As of Python 3.2, `os.makedirs()` takes `exist_ok` as a keyword argument. If set to true, the function does not raise an error if the directory already exists. This makes the function's behavior similar to `mkdir -p` on the UNIX commandline. (See https://docs.python.org/3/library/os.html#os.makedirs) However, this functionality is missing in Python's new pathlib. In fact, the documentation for `Path.mkdir()` even mentions that if `parent=True` is passed, then it should behave like `mkdir -p`. This is accurate in that it indeed recursively makes any parent directories necessary, but it is inaccurate in that it raises an error if the directory already exists. I propose that either `parents=True` should imply that there is no error if the directory already exists (which would be a backwards-incompatible change); or, there could be a new `exist_ok=True`, which could suppress the error for an existing directory. Either way, it ought to be possible to get the `mkdir -p` functionality easily from pathlib. And the documentation for `Path.mkdir()` should be updated to explain how to get this `mkdir -p` functionality, with the existing (inaccurate) `mkdir -p` mention removed. ---------- components: Library (Lib) messages: 218832 nosy: garrison priority: normal severity: normal status: open title: pathlib's Path.mkdir() should allow for "mkdir -p" functionality type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 06:09:06 2014 From: report at bugs.python.org (tholzer) Date: Tue, 20 May 2014 04:09:06 +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: <1400558946.93.0.920568091847.issue20611@psf.upfronthosting.co.za> tholzer added the comment: Here is a reproducible test case: import threading import signal import os import httplib def killer(): while 1: os.kill(os.getpid(), signal.SIGINT) def go(): signal.signal(signal.SIGINT, lambda x,y: None) thread = threading.Thread(target=killer) thread.start() while 1: connection = httplib.HTTPConnection("localhost:80") connection.connect() connection.close() if __name__ == '__main__': go() Which gives: Traceback (most recent call last): File "./repro1.py", line 22, in go() File "./repro1.py", line 18, in go connection.connect() File ".../lib/python2.7/httplib.py", line 757, in connect self.timeout, self.source_address) File ".../lib/python2.7/socket.py", line 571, in create_connection raise err socket.error: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 06:41:43 2014 From: report at bugs.python.org (John Lehr) Date: Tue, 20 May 2014 04:41:43 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400547106.09.0.86310716268.issue21538@psf.upfronthosting.co.za> Message-ID: John Lehr added the comment: Ned, I understand. I did get permission to post that history, and as I feared, the sanitized History.plist I'm attaching now doesn't have the loading issue that the first did. Possibly a URL character is throwing the exception? Can you suggest where I can put a print statement in the library or some other way to post to get you meaningful debug information? I don't have any experience with pdb, and a verbose python execution is pretty lengthy. As I said before, I have two more extensive History.plist files from two different devices that won't load. On Mon, May 19, 2014 at 5:51 PM, Ned Deily wrote: > > Ned Deily added the comment: > > John, a quick look at the file shows that it contains browsing history > information that might be personally identifiable. I don't think that is > appropriate to store on a public web site like this one so I've deleted the > file. Is there some way to provide a simpler file with non-personal > history? > > ---------- > nosy: +ned.deily > > _______________________________________ > Python tracker > > _______________________________________ > ---------- Added file: http://bugs.python.org/file35298/History.plist _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: History.plist Type: application/octet-stream Size: 1580 bytes Desc: not available URL: From report at bugs.python.org Tue May 20 07:03:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 May 2014 05:03:22 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400562202.76.0.972088177068.issue21538@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file35295/History.plist.7z _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 07:05:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 May 2014 05:05:02 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400562302.16.0.646491305024.issue21538@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file35295/History.plist.7z _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 07:32:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 May 2014 05:32:41 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400563961.79.0.363289315662.issue21538@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this patch should fix the issue. But tests needed. ---------- keywords: +patch stage: -> test needed type: -> behavior Added file: http://bugs.python.org/file35299/plistlib_read_refs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 07:41:32 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 20 May 2014 05:41:32 +0000 Subject: [issue20611] socket.create_connection() doesn't handle EINTR properly In-Reply-To: <1400555581.89.0.479622645828.issue20611@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: As said in a previous comment, we don't want to have EINTR handling code everywhere. The right way to do this is to handle it at the syscall level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 07:59:44 2014 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 20 May 2014 05:59:44 +0000 Subject: [issue21540] PEP 8 should recommend "is not" and "not in" Message-ID: <1400565584.02.0.148226279911.issue21540@psf.upfronthosting.co.za> New submission from Florent Xicluna: Python accepts both syntaxes: if not item in some_list and not item is None: return item and if item not in some_list and item is not None: return item In the first form, you identify 5 operators: "not", "in", "and", "not" and "in" In the second form, you find only 3 operators: "not in", "and", "is not" Of course CPython does internal optimization, and it compiles both expressions to the same bytecode. However the second form is more readable and less error-prone. It is plain English. I propose to add such advice to the section "Programming Recommendations" of PEP 8. ---------- assignee: docs at python components: Documentation messages: 218837 nosy: barry, docs at python, flox, ncoghlan priority: normal severity: normal status: open title: PEP 8 should recommend "is not" and "not in" type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 08:07:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 May 2014 06:07:35 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400566055.72.0.809140640748.issue21538@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And here is a patch with test. ---------- stage: test needed -> patch review Added file: http://bugs.python.org/file35300/plistlib_read_refs_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 08:08:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 May 2014 06:08:19 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400566099.04.0.157658063232.issue21538@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file35299/plistlib_read_refs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 08:28:01 2014 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 20 May 2014 06:28:01 +0000 Subject: [issue21540] PEP 8 should recommend "is not" and "not in" In-Reply-To: <1400565584.02.0.148226279911.issue21540@psf.upfronthosting.co.za> Message-ID: <1400567281.35.0.475624652961.issue21540@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- assignee: docs at python -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 10:23:08 2014 From: report at bugs.python.org (Simon de Vlieger) Date: Tue, 20 May 2014 08:23:08 +0000 Subject: [issue21052] Consider dropping ImportWarning for empty sys.path_hooks and sys.meta_path In-Reply-To: <1395681608.6.0.965988272103.issue21052@psf.upfronthosting.co.za> Message-ID: <1400574188.94.0.492281753118.issue21052@psf.upfronthosting.co.za> Changes by Simon de Vlieger : ---------- nosy: +ikanobori _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 11:09:19 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Tue, 20 May 2014 09:09:19 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400576959.5.0.613830594024.issue21477@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Adds spec dicts for aboutDialog, ClassBrowser, PathBrowser, textView and configHelpSourceEdit and modifies the related modules appropriately. The spec dicts(and the tests relating to) for editorwindow and help dialog have not been modified in this patch. The tests work OK when run individually from respective modules. The widgets are placed below parent. Some widgets close the parent when they are closed, some do not.(I feel the parent should be manually closed by the user, because the user might want to re-run a test. This would also help in reusing root, when running all the tests together). The runall() seems shaky at the moment. For eg, as mentioned above, some widgets close the parent when they are closed, some do not. This is causes build-up of parent dialogs. I did not try to fix it, because things will change once we agree upon factoring out run() and runall(), about reusing the same root window for runall(). If things dont change, I will work on fixing the buildup of dialogs. If this patch seems "incomplete" because of the above issue, please provide feedback about the tests itself, when run individually. ---------- keywords: +patch Added file: http://bugs.python.org/file35301/about+classbrowser+cfghelpsrcedit+pathbrowser+textview.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 11:29:32 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Tue, 20 May 2014 09:29:32 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400578172.89.0.0775529452367.issue21477@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Removed file: http://bugs.python.org/file35301/about+classbrowser+cfghelpsrcedit+pathbrowser+textview.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 11:31:00 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Tue, 20 May 2014 09:31:00 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400578260.78.0.799089929287.issue21477@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file35302/about+classbrowser+cfghelpsrcedit+pathbrowser+textview.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 12:29:19 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 20 May 2014 10:29:19 +0000 Subject: [issue21527] concurrent.futures.ThreadPoolExecutor does not use a default value In-Reply-To: <1400453267.44.0.909455514702.issue21527@psf.upfronthosting.co.za> Message-ID: <1400581759.11.0.894145142855.issue21527@psf.upfronthosting.co.za> Josh Rosenberg added the comment: +1. Makes it easier to swap Executors (which is a big selling point for the Executor framework), and number of cores is a reasonable default value. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 12:48:53 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 20 May 2014 10:48:53 +0000 Subject: [issue21539] pathlib's Path.mkdir() should allow for "mkdir -p" functionality In-Reply-To: <1400558036.91.0.766972225791.issue21539@psf.upfronthosting.co.za> Message-ID: <1400582933.28.0.327143414917.issue21539@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 13:39:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 20 May 2014 11:39:48 +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: <1400585988.38.0.406805802916.issue20611@psf.upfronthosting.co.za> Antoine Pitrou added the comment: @tholzer, to clarify Charles-Fran?ois's comment: EINTR should be handled in socket.connect() and socket.getaddrinfo() (the two syscalls called by create_connection(), AFAIR). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 13:46:05 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 20 May 2014 11:46:05 +0000 Subject: [issue21539] pathlib's Path.mkdir() should allow for "mkdir -p" functionality In-Reply-To: <1400558036.91.0.766972225791.issue21539@psf.upfronthosting.co.za> Message-ID: <1400586365.38.0.74921796657.issue21539@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think we can a new `exist_ok` parameter indeed. It should probably be False by default, though. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 14:05:34 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 20 May 2014 12:05:34 +0000 Subject: [issue21539] pathlib's Path.mkdir() should allow for "mkdir -p" functionality In-Reply-To: <1400558036.91.0.766972225791.issue21539@psf.upfronthosting.co.za> Message-ID: <1400587534.86.0.799387016799.issue21539@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file35303/issue21539.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 14:59:49 2014 From: report at bugs.python.org (Facundo Batista) Date: Tue, 20 May 2014 12:59:49 +0000 Subject: [issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za> Message-ID: <1400590789.8.0.0560307336059.issue13866@psf.upfronthosting.co.za> Changes by Facundo Batista : ---------- stage: resolved -> patch review versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 15:16:44 2014 From: report at bugs.python.org (Steven Myint) Date: Tue, 20 May 2014 13:16:44 +0000 Subject: [issue21540] PEP 8 should recommend "is not" and "not in" In-Reply-To: <1400565584.02.0.148226279911.issue21540@psf.upfronthosting.co.za> Message-ID: <1400591804.68.0.49055002082.issue21540@psf.upfronthosting.co.za> Changes by Steven Myint : ---------- nosy: +myint _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 15:29:49 2014 From: report at bugs.python.org (Pavel Machyniak) Date: Tue, 20 May 2014 13:29:49 +0000 Subject: [issue5575] Add env vars for controlling building sqlite, hashlib and ssl In-Reply-To: <1238101680.27.0.350099709898.issue5575@psf.upfronthosting.co.za> Message-ID: <1400592589.28.0.979216738078.issue5575@psf.upfronthosting.co.za> Pavel Machyniak added the comment: Unfortunately this patch will not work if there is other (system) openssl installed in the default locations (`/usr/include`, `/usr/lib`) because this patch only add another path at the end of the search list. Instead of this I will make a ticket for providing configuration option for controlling the `openssl` (`--with-ssl=PATH`) and I will propose the solution (patch for current `configure` and `setup.py`). This way the user can explicitly provide the path for `openssl` and there is no need to search for one. I think it is important to fix this because there is a lot of people having problem compiling `python` with custom `openssl`, eg.: [http://stackoverflow.com/questions/22409092/coredump-when-compiling-python-with-a-custom-openssl-version] ---------- nosy: +machyniak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 15:46:54 2014 From: report at bugs.python.org (Pavel Machyniak) Date: Tue, 20 May 2014 13:46:54 +0000 Subject: [issue21541] Provide configure option --with-ssl for compilation with custom openssl Message-ID: <1400593614.19.0.224440922912.issue21541@psf.upfronthosting.co.za> New submission from Pavel Machyniak: There is no easy way to build python with custom openssl build. This can lead to miscellaneous problems (like segmentation faults) in various situations/configurations (see eg. http://stackoverflow.com/questions/22409092/coredump-when-compiling-python-with-a-custom-openssl-version). The problems usually arise when different version of openssl headers and libs are used, or when different versions of openssl is required within one process (eg. using python within apache httpd process (mod_wsgi or mod_python) + some other module that uses explicitly updated/newer/incompatible version of openssl). The best way to workaround this problem would be to have the clear way how to build python with specific openssl version. The best way would by to use configure options --with-ssl=PATH optionally with --with-ssl-includes=PATH and --with-ssl-libs=PATH. In this case, setup.py shall not search for openssl but shall use the explicitly specified one. I will shortly provide the patch for the current version of configure and setup.py. See related issues: - http://bugs.python.org/issue5575 - http://bugs.python.org/issue16660 ---------- components: Build messages: 218844 nosy: machyniak priority: normal severity: normal status: open title: Provide configure option --with-ssl for compilation with custom openssl type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 16:06:48 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 20 May 2014 14:06:48 +0000 Subject: [issue21541] Provide configure option --with-ssl for compilation with custom openssl In-Reply-To: <1400593614.19.0.224440922912.issue21541@psf.upfronthosting.co.za> Message-ID: <1400594808.88.0.841942175887.issue21541@psf.upfronthosting.co.za> R. David Murray added the comment: Aren't things like this normally accomplished by editing Modules/Setup? Granted, that's not the most convenient build API... ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 16:30:29 2014 From: report at bugs.python.org (Ian Cordasco) Date: Tue, 20 May 2014 14:30:29 +0000 Subject: [issue21540] PEP 8 should recommend "is not" and "not in" In-Reply-To: <1400565584.02.0.148226279911.issue21540@psf.upfronthosting.co.za> Message-ID: <1400596229.32.0.150048386067.issue21540@psf.upfronthosting.co.za> Changes by Ian Cordasco : ---------- nosy: +icordasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 17:11:20 2014 From: report at bugs.python.org (Pavel Machyniak) Date: Tue, 20 May 2014 15:11:20 +0000 Subject: [issue21541] Provide configure option --with-ssl for compilation with custom openssl In-Reply-To: <1400593614.19.0.224440922912.issue21541@psf.upfronthosting.co.za> Message-ID: <1400598680.97.0.255089516666.issue21541@psf.upfronthosting.co.za> Pavel Machyniak added the comment: This is the proposed patch (compared 2 trees src & upd where src is latest release 3.4.1, upd is my working). Changes are in: configure, setup.py. Please review it and hopefully integrate to future releases. ---------- keywords: +patch versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file35304/issue21541-patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 17:30:03 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 20 May 2014 15:30:03 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1400599803.26.0.702904918826.issue21161@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The patch fails to invoke exec() with the locals argument set to the current frame locals. The attached patch fixes this, and test_pdb runs now fine with it. ---------- Added file: http://bugs.python.org/file35305/default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 17:32:41 2014 From: report at bugs.python.org (Ram Rachum) Date: Tue, 20 May 2014 15:32:41 +0000 Subject: [issue21542] pprint doesn't work well for counters, sometimes shows them like a dict Message-ID: <1400599961.44.0.600133216015.issue21542@psf.upfronthosting.co.za> New submission from Ram Rachum: pprint doesn't work well for counters, sometimes shows them like a dict Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> dd={'a': 11640, 'b': 2614, 'c': 5261, 'd': 5311, 'e': 17722, 'f': 3041, 'g': 3570, 'h': 6740, 'i': 10729, 'j': 279, 'k': 1812, 'l': 6391, 'm': 5037, 'n': 10111, 'o': 11922, 'p': 3863, 'q': 99, 'r': 94 61, 's': 9444, 't': 13744, 'u': 4027, 'v': 1486, 'w': 3194, 'x': 540, 'y': 2976, 'z': 203} >>> import collections >>> collections.Counter(dd) Counter({'e': 17722, 't': 13744, 'o': 11922, 'a': 11640, 'i': 10729, 'n': 10111, 'r': 9461, 's': 9444, 'h': 6740, 'l': 6391, 'd': 5311, 'c': 5261, 'm': 5037, 'u': 4027, 'p': 3863, 'g': 3570, 'w': 3194, 'f ': 3041, 'y': 2976, 'b': 2614, 'k': 1812, 'v': 1486, 'x': 540, 'j': 279, 'z': 203, 'q': 99}) >>> import pprint >>> pprint.pprint(collections.Counter(dd)) {'a': 11640, 'b': 2614, 'c': 5261, 'd': 5311, 'e': 17722, 'f': 3041, 'g': 3570, 'h': 6740, 'i': 10729, 'j': 279, 'k': 1812, 'l': 6391, 'm': 5037, 'n': 10111, 'o': 11922, 'p': 3863, 'q': 99, 'r': 9461, 's': 9444, 't': 13744, 'u': 4027, 'v': 1486, 'w': 3194, 'x': 540, 'y': 2976, 'z': 203} >>> ---------- components: Library (Lib) messages: 218848 nosy: cool-RR priority: normal severity: normal status: open title: pprint doesn't work well for counters, sometimes shows them like a dict versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 18:51:57 2014 From: report at bugs.python.org (Dann Ke) Date: Tue, 20 May 2014 16:51:57 +0000 Subject: [issue21543] json library fails to serialize objects such as datetime Message-ID: <1400604717.26.0.426276318996.issue21543@psf.upfronthosting.co.za> New submission from Dann Ke: I'm using the json library to serialize objects out for web use. Whenever I serialize a datetime or other included python library object (uuid as another example), it fails with TypeError: datetime.datetime(2014, 5, 20, 9, 37, 56, 133627) is not JSON serializable While this behaviour is well and good, what I am suggesting is that I would like a way for this library to attempt to serialize an object when it encounters an exception. For instance, if it attempts to serialize a datetime and fails, I would like the option of submitting a method as a parameter to the json.dumps() method that the object is put into in an attempt to serialize it. As a code example: import datetime, json json.dumps(dict(mydate=datetime.datetime.now()), serialize=str) That way, when it encounters a TypeError, it will set mydate to a string and will be serialized out. Right now, I have to use str() on a few different fields because they are not standard types (str, int, bool, float, None, etc) This isn't a priority and I'm open to criticisms. Would you accept a patch for this if you are too busy to work on this feature? Thank you for your time. Dann ---------- components: Extension Modules, Library (Lib) messages: 218849 nosy: Dann.Ke priority: normal severity: normal status: open title: json library fails to serialize objects such as datetime type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 18:58:39 2014 From: report at bugs.python.org (John Lehr) Date: Tue, 20 May 2014 16:58:39 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400566099.07.0.207827556331.issue21538@psf.upfronthosting.co.za> Message-ID: John Lehr added the comment: Serhiy, I applied the patch and can confirm this is a fix (three previous failing loads of History.plists from three different devices now load successfully). Thank you, I would not likely have identified the issue myself. On Mon, May 19, 2014 at 11:08 PM, Serhiy Storchaka wrote: > > Changes by Serhiy Storchaka : > > > Removed file: http://bugs.python.org/file35299/plistlib_read_refs.patch > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 19:00:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 20 May 2014 17:00:19 +0000 Subject: [issue21528] Fix a number of typos in the documentation In-Reply-To: <1400456947.04.0.361173205763.issue21528@psf.upfronthosting.co.za> Message-ID: <3gY3Hk2gH5z7LjN@mail.python.org> Roundup Robot added the comment: New changeset db302b88fdb6 by Donald Stufft in branch 'default': Fix Issue #21528 - Fix documentation typos http://hg.python.org/cpython/rev/db302b88fdb6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 19:06:56 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 20 May 2014 17:06:56 +0000 Subject: [issue21528] Fix a number of typos in the documentation In-Reply-To: <1400456947.04.0.361173205763.issue21528@psf.upfronthosting.co.za> Message-ID: <1400605616.26.0.836434868234.issue21528@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 19:09:05 2014 From: report at bugs.python.org (akira) Date: Tue, 20 May 2014 17:09:05 +0000 Subject: [issue21543] json library fails to serialize objects such as datetime In-Reply-To: <1400604717.26.0.426276318996.issue21543@psf.upfronthosting.co.za> Message-ID: <1400605745.2.0.105957584855.issue21543@psf.upfronthosting.co.za> akira added the comment: json module already allows you to customize the serialization: see *default* parameter for json.dumps [1] [1] https://docs.python.org/3/library/json.html#json.dump ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 19:11:21 2014 From: report at bugs.python.org (Dann Ke) Date: Tue, 20 May 2014 17:11:21 +0000 Subject: [issue21543] json library fails to serialize objects such as datetime In-Reply-To: <1400605745.2.0.105957584855.issue21543@psf.upfronthosting.co.za> Message-ID: Dann Ke added the comment: I was reading the older 2.7 docs and it didn't click that default() was what I wanted. Thank you for clarifying. On Tue, May 20, 2014 at 10:09 AM, akira wrote: > > akira added the comment: > > json module already allows you to customize the serialization: see > *default* parameter for json.dumps [1] > > [1] https://docs.python.org/3/library/json.html#json.dump > > ---------- > nosy: +akira > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 19:31:24 2014 From: report at bugs.python.org (John Lehr) Date: Tue, 20 May 2014 17:31:24 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400607084.29.0.251421426885.issue21538@psf.upfronthosting.co.za> John Lehr added the comment: Patch plistlib_read_refs_2.patch corrects load error for iOS Safari History.plist. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 19:36:36 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 20 May 2014 17:36:36 +0000 Subject: [issue21543] json library fails to serialize objects such as datetime In-Reply-To: <1400604717.26.0.426276318996.issue21543@psf.upfronthosting.co.za> Message-ID: <1400607396.5.0.0508957218903.issue21543@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 20:04:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 May 2014 18:04:40 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400609080.69.0.299618032193.issue21538@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Issue shouldn't be closed as resolved until patch is committed. Ronald, is it good to you? ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 22:08:13 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 20 May 2014 20:08:13 +0000 Subject: [issue21542] pprint doesn't work well for counters, sometimes shows them like a dict In-Reply-To: <1400599961.44.0.600133216015.issue21542@psf.upfronthosting.co.za> Message-ID: <1400616493.38.0.574370737139.issue21542@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 22:48:56 2014 From: report at bugs.python.org (bjlittle) Date: Tue, 20 May 2014 20:48:56 +0000 Subject: [issue21544] Did y ou call me Message-ID: <537bbfb4.4253b40a.2a17.fffff980@mx.google.com> New submission from bjlittle: That was a really bad thing to happen in Hagrids first class though wasnt it said Ron
i have sent you a aol message
View your notification here ---------- messages: 218856 nosy: bill.little priority: normal severity: normal status: open title: Did y ou call me _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 22:55:19 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 20 May 2014 20:55:19 +0000 Subject: [issue21544] Spam In-Reply-To: <537bbfb4.4253b40a.2a17.fffff980@mx.google.com> Message-ID: <1400619319.6.0.824757882981.issue21544@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: -bill.little resolution: -> not a bug status: open -> closed title: Did y ou call me -> Spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 22:55:35 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 20 May 2014 20:55:35 +0000 Subject: [issue21544] Spam Message-ID: <1400619335.58.0.0405340056721.issue21544@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg218856 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 20 23:37:33 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 20 May 2014 21:37:33 +0000 Subject: [issue21545] Tutorial: examples and comment about mutation methods Message-ID: <1400621853.89.0.606116768213.issue21545@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The Tutorial section More on Lists https://docs.python.org/3.4/tutorial/datastructures.html#more-on-lists includes list.pop but ignores it in the example and final comment. I think the examples should be augmented and the comment modified. 1. (simplest) End the example block with >>> a.pop() 1234.5 >>> a [-1, 1, 66.25, 333, 333] 2. The comment says "You might have noticed that methods like insert, remove or sort that modify the list have no return value printed ? they return None. [1] This is a design principle for all mutable data structures in Python." [The footnote says "[1] Other languages may return the mutated object, which allows method chaining, such as d->insert("a")->remove("b")->sort();."] Inserting 'only' before 'modify' makes the statement true even now with .pop added. I think 'the default' should be added before 'None', but that would be optional. I do not think .pop needs to be explicitly mentioned here since the point of the comment is to explain the lack of a printed return value, and .pop does have a printed return value. ---------- assignee: docs at python components: Documentation messages: 218857 nosy: docs at python, ncoghlan, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Tutorial: examples and comment about mutation methods type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 00:10:15 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 20 May 2014 22:10:15 +0000 Subject: [issue21540] PEP 8 should recommend "is not" and "not in" In-Reply-To: <1400565584.02.0.148226279911.issue21540@psf.upfronthosting.co.za> Message-ID: <1400623815.69.0.275466036516.issue21540@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Agreed! I'll update the PEP. Thanks. ---------- assignee: -> barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 00:14:34 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 20 May 2014 22:14:34 +0000 Subject: [issue21540] PEP 8 should recommend "is not" and "not in" In-Reply-To: <1400565584.02.0.148226279911.issue21540@psf.upfronthosting.co.za> Message-ID: <1400624074.65.0.144929363651.issue21540@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 00:56:53 2014 From: report at bugs.python.org (Chris Rebert) Date: Tue, 20 May 2014 22:56:53 +0000 Subject: [issue21545] Tutorial: examples and comment about mutation methods In-Reply-To: <1400621853.89.0.606116768213.issue21545@psf.upfronthosting.co.za> Message-ID: <1400626613.49.0.0662364503625.issue21545@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 01:38:26 2014 From: report at bugs.python.org (Kurt Rose) Date: Tue, 20 May 2014 23:38:26 +0000 Subject: [issue21546] int('\0') gives wrong error message Message-ID: <1400629106.74.0.994862767087.issue21546@psf.upfronthosting.co.za> New submission from Kurt Rose: int() ignores everything after a null byte when reporting an error message. Here you can see an example of how this manifests, and why could be a problem. Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit(Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> int('a') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: 'a' >>> int('\0a') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: '' >>> int('abc\0def') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: 'abc' ---------- components: Interpreter Core messages: 218859 nosy: Kurt.Rose priority: normal severity: normal status: open title: int('\0') gives wrong error message versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 02:41:43 2014 From: report at bugs.python.org (Masayuki Yamamoto) Date: Wed, 21 May 2014 00:41:43 +0000 Subject: [issue21088] curses addch() argument position reverses in Python3.4.0 In-Reply-To: <1396036290.82.0.606042459455.issue21088@psf.upfronthosting.co.za> Message-ID: <1400632903.57.0.183887846987.issue21088@psf.upfronthosting.co.za> Changes by Masayuki Yamamoto : ---------- nosy: -masamoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 03:19:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 May 2014 01:19:45 +0000 Subject: [issue21546] int('\0') gives wrong error message In-Reply-To: <1400629106.74.0.994862767087.issue21546@psf.upfronthosting.co.za> Message-ID: <1400635185.93.0.989642871739.issue21546@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like the issue was already fixed in Python 3: Python 3.5.0a0 (default:61d9aa8be445, May 20 2014, 16:03:51) >>> int('a') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: 'a' >>> int('\0a') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: '\x00a' >>> int('abc\x00def') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: 'abc\x00def' And the last one: >>> int('\0') Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for int() with base 10: '\x00' ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 03:21:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 May 2014 01:21:03 +0000 Subject: [issue17421] Drop restriction that meta.__prepare__() must return a dict (subclass) In-Reply-To: <1363292427.77.0.787480674647.issue17421@psf.upfronthosting.co.za> Message-ID: <1400635263.21.0.945259292473.issue17421@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 03:27:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 May 2014 01:27:53 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1400635673.95.0.664652196104.issue1191964@psf.upfronthosting.co.za> STINNER Victor added the comment: @Josiah: Modifications of the asyncio module should be done first in the Tulip project because we try to keep the same code base in Tulip, Python 3.4 and 3.5. You may duplicate the code the avoid this dependency? For the documentation, I don't think that you need ".. note" and ".. warning", just write paragraphs of text. ---------- nosy: +gvanrossum, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 03:32:37 2014 From: report at bugs.python.org (eryksun) Date: Wed, 21 May 2014 01:32:37 +0000 Subject: [issue21546] int('\0') gives wrong error message In-Reply-To: <1400629106.74.0.994862767087.issue21546@psf.upfronthosting.co.za> Message-ID: <1400635957.59.0.845405481113.issue21546@psf.upfronthosting.co.za> eryksun added the comment: See issue 16741. This is fixed in 3.3, but 2.7 intentionally keeps the old behavior. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 07:52:27 2014 From: report at bugs.python.org (paul j3) Date: Wed, 21 May 2014 05:52:27 +0000 Subject: [issue12806] argparse: Hybrid help text formatter In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za> Message-ID: <1400651547.73.0.522198450692.issue12806@psf.upfronthosting.co.za> Changes by paul j3 : Removed file: http://bugs.python.org/file35236/wrap_sample.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 07:53:05 2014 From: report at bugs.python.org (paul j3) Date: Wed, 21 May 2014 05:53:05 +0000 Subject: [issue12806] argparse: Hybrid help text formatter In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za> Message-ID: <1400651585.22.0.162561891603.issue12806@psf.upfronthosting.co.za> Changes by paul j3 : Added file: http://bugs.python.org/file35306/wrap_sample.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 08:39:19 2014 From: report at bugs.python.org (Joshua Landau) Date: Wed, 21 May 2014 06:39:19 +0000 Subject: [issue21547] '!s' formatting documentation bug Message-ID: <1400654359.7.0.699720681212.issue21547@psf.upfronthosting.co.za> New submission from Joshua Landau: In the docs for 2.x about the formatting syntax: https://docs.python.org/2/library/string.html#format-string-syntax it says "Two conversion flags are currently supported: '!s' which calls str() on the value, and '!r' which calls repr()." but for unicode formatters, '!s' calls unicode() instead. See http://stackoverflow.com/questions/23773816/why-python-str-format-doesnt-call-str for the question that found this. ---------- assignee: docs at python components: Documentation messages: 218863 nosy: Joshua.Landau, docs at python priority: normal severity: normal status: open title: '!s' formatting documentation bug versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 09:47:08 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Wed, 21 May 2014 07:47:08 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1400658428.23.0.154014454721.issue14776@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: I'd be fine with adapting the patch to support both systemtap and dtrace, however I have very little knowledge of dtrace and I don't have a machine to test it on. @jcea would you be willing to work on such patch with me? I'm sure we could work on this together and reuse each others' code as much as possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 10:43:03 2014 From: report at bugs.python.org (Dima Tisnek) Date: Wed, 21 May 2014 08:43:03 +0000 Subject: [issue21548] pydoc -k IndexError on empty docstring Message-ID: <1400661783.43.0.558471008968.issue21548@psf.upfronthosting.co.za> New submission from Dima Tisnek: While trying to track down another bug, I disabled some packages: [dima at bmg tmp]$ chmod a-x /usr/lib/python3.4/site-packages/speechd* Then ran pydoc -k: [dima at bmg tmp]$ pydoc3.4 -k n688954789 Traceback (most recent call last): File "/usr/bin/pydoc3.4", line 5, in pydoc.cli() File "/usr/lib/python3.4/pydoc.py", line 2548, in cli apropos(val) File "/usr/lib/python3.4/pydoc.py", line 2080, in apropos ModuleScanner().run(callback, key, onerror=onerror) File "/usr/lib/python3.4/pydoc.py", line 2061, in run desc = (module.__doc__ or '').splitlines()[0] IndexError: list index out of range Clearly "".splitlines() is always empty; missing doc is not handled correctly. ---------- components: Library (Lib) messages: 218865 nosy: Dima.Tisnek priority: normal severity: normal status: open title: pydoc -k IndexError on empty docstring versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 11:55:55 2014 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Wed, 21 May 2014 09:55:55 +0000 Subject: [issue21541] Provide configure option --with-ssl for compilation with custom openssl In-Reply-To: <1400593614.19.0.224440922912.issue21541@psf.upfronthosting.co.za> Message-ID: <1400666155.91.0.502623386717.issue21541@psf.upfronthosting.co.za> Changes by Michele Orr? : ---------- nosy: +maker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 12:30:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 May 2014 10:30:23 +0000 Subject: [issue21549] Add the members parameter for TarFile.list() Message-ID: <1400668223.94.0.601908593409.issue21549@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The proposed patch adds the members parameter for TarFile.list() with the same meaning as in TarFile.extractall(). This is needed for implementing the tar command utility which allows filtering and transforming an output (e.g. output numerical ids instead names for owner/group). An alternative approach is to add the filter parameter (as in TarFile.add()) to both TarFile.list() and TarFile.extractall(). ---------- components: Library (Lib) files: tarfile_list_members.patch keywords: patch messages: 218866 nosy: lars.gustaebel, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add the members parameter for TarFile.list() type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35307/tarfile_list_members.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 12:49:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 May 2014 10:49:14 +0000 Subject: [issue21550] Add Python implementation of the tar utility Message-ID: <1400669354.09.0.317678574527.issue21550@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is preliminary Python implementation of the tar archiving utility. I propose to add it to Tools/script. The main purpose of this the research of which features needed the tarfile module. Another purpose is that this provides more powerful tool to create or extract tar archives on platforms where the tar utility is not installed (the tarfile module itself provides very simple command line interface). Supported options are mainly common subset of GNU tar and bsdtar options. Some options (--absolute-names, controlling of symlinks and hardlings dereferencing and files overwriting) needs implementing new features in the tarfile module. ---------- components: Demos and Tools files: tar.py messages: 218867 nosy: berker.peksag, lars.gustaebel, serhiy.storchaka priority: normal severity: normal stage: test needed status: open title: Add Python implementation of the tar utility type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35308/tar.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 12:50:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 May 2014 10:50:09 +0000 Subject: [issue21550] Add Python implementation of the tar utility In-Reply-To: <1400669354.09.0.317678574527.issue21550@psf.upfronthosting.co.za> Message-ID: <1400669409.61.0.977819442038.issue21550@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Add the members parameter for TarFile.list() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 12:50:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 May 2014 10:50:50 +0000 Subject: [issue21549] Add the members parameter for TarFile.list() In-Reply-To: <1400668223.94.0.601908593409.issue21549@psf.upfronthosting.co.za> Message-ID: <1400669450.75.0.4205646344.issue21549@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See issue21550 for example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 13:28:29 2014 From: report at bugs.python.org (Ned Batchelder) Date: Wed, 21 May 2014 11:28:29 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400671709.33.0.513352614855.issue2506@psf.upfronthosting.co.za> Ned Batchelder added the comment: Python-Ideas thread started: https://mail.python.org/pipermail/python-ideas/2014-May/027893.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 13:42:43 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 21 May 2014 11:42:43 +0000 Subject: [issue21550] Add Python implementation of the tar utility In-Reply-To: <1400669354.09.0.317678574527.issue21550@psf.upfronthosting.co.za> Message-ID: <1400672563.14.0.51310668824.issue21550@psf.upfronthosting.co.za> Claudiu.Popa added the comment: I don't think that adding it to Tools/script helps that much on Windows at least. See issue21027 for reference. Except this, +1 from me. ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 14:31:09 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 21 May 2014 12:31:09 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1400675469.16.0.503919984558.issue14776@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I would. Just to point out that some dtrace weirdness like the stack walker is needed because dtrace probes are executed inside the OS kernel :-). Can we analyze case by case?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 15:26:40 2014 From: report at bugs.python.org (akira) Date: Wed, 21 May 2014 13:26:40 +0000 Subject: [issue21542] pprint doesn't work well for counters, sometimes shows them like a dict In-Reply-To: <1400599961.44.0.600133216015.issue21542@psf.upfronthosting.co.za> Message-ID: <1400678800.11.0.306859760863.issue21542@psf.upfronthosting.co.za> akira added the comment: If it fits on a line then it seems Counter's repr is used: >>> pprint(Counter({i:i*i for i in range(10)})) Counter({9: 81, 8: 64, 7: 49, 6: 36, 5: 25, 4: 16, 3: 9, 2: 4, 1: 1, 0: 0}) Otherwise It is shown as a dict (Counter is a dict subclass) if it is too large (multi-line): >>> pprint(Counter({i:i*i for i in range(10)}), width=20) {0: 0, 1: 1, 2: 4, 3: 9, 4: 16, 5: 25, 6: 36, 7: 49, 8: 64, 9: 81} the behaviour is weird but pprint doesn't promise that custom objects such as Counter that can't be created using Python literals will be printed in a reversible manner. It seems there is a special support for some objects: >>> pprint(frozenset({i for i in range(10)})) frozenset({0, 1, 2, 3, 4, 5, 6, 7, 8, 9}) >>> pprint(frozenset({i for i in range(10)}), width=20) frozenset({0, 1, 2, 3, 4, 5, 6, 7, 8, 9}) Perhaps the support for Counter could be added using functools.singledispatch and/or __prettyprint__ hook from issue #7434 ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 15:27:44 2014 From: report at bugs.python.org (akira) Date: Wed, 21 May 2014 13:27:44 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1400678864.3.0.0791851406477.issue7434@psf.upfronthosting.co.za> akira added the comment: Related issue #21542: pprint support for multiline collections.Counter ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 15:54:19 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 21 May 2014 13:54:19 +0000 Subject: [issue21550] Add Python implementation of the tar utility In-Reply-To: <1400669354.09.0.317678574527.issue21550@psf.upfronthosting.co.za> Message-ID: <1400680459.92.0.2501350936.issue21550@psf.upfronthosting.co.za> Brett Cannon added the comment: If this goes in then the CLI in the tarfile module should be removed. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 16:12:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 21 May 2014 14:12:32 +0000 Subject: [issue21525] Accept lists in Tkinter In-Reply-To: <1400429071.94.0.00909655456626.issue21525@psf.upfronthosting.co.za> Message-ID: <3gYbWf1CwFz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 8676e436c0f0 by Serhiy Storchaka in branch 'default': Issue #21525: Most Tkinter methods which accepted tuples now accept lists too. http://hg.python.org/cpython/rev/8676e436c0f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 16:21:36 2014 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 21 May 2014 14:21:36 +0000 Subject: [issue21547] '!s' formatting documentation bug In-Reply-To: <1400654359.7.0.699720681212.issue21547@psf.upfronthosting.co.za> Message-ID: <1400682096.83.0.850451554067.issue21547@psf.upfronthosting.co.za> Eric V. Smith added the comment: I suggest using whatever language explains what "u'%s' %obj" does. It's the same behavior. >From the SO question, given: class A(object): def __str__(self): return 'as str' def __unicode__(self): return u'as unicode' Then: >>> '%s' % A() 'as str' >>> u'%s' % A() u'as unicode' and: >>> '{!s}'.format(A()) 'as str' >>> u'{!s}'.format(A()) u'as unicode' ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 16:21:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 May 2014 14:21:46 +0000 Subject: [issue21525] Accept lists in Tkinter In-Reply-To: <1400429071.94.0.00909655456626.issue21525@psf.upfronthosting.co.za> Message-ID: <1400682106.67.0.100705110957.issue21525@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 May 21 16:59:36 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 21 May 2014 14:59:36 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1400684376.73.0.342739189162.issue20035@psf.upfronthosting.co.za> Zachary Ware added the comment: Ping. I still want to get this in, but not without a proper review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 17:02:56 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 21 May 2014 15:02:56 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400684576.21.0.362003675948.issue21538@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The patch looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 17:38:12 2014 From: report at bugs.python.org (Wellington Fan) Date: Wed, 21 May 2014 15:38:12 +0000 Subject: [issue21551] Behavior of word boundaries in regexes unexpected Message-ID: <1400686692.12.0.566986679321.issue21551@psf.upfronthosting.co.za> New submission from Wellington Fan: Hello, It seems that the word boundary sequence -- r'\b' -- is not behaving as expected using re.split(). The regex docs say: \b Matches the empty string, but only at the start or end of a word. My (failing) test: > import re > re.split(r'\b', 'A funky string') ['A funky string'] We get a one-element array returned; I would expect a seven-element array: ['', 'A', ' ', 'funky', ' ', 'string', ''] I have equivalent code in PHP that *does* work: php > print_r( preg_split('/\b/', 'A funny string') ); Array ( [0] => [1] => A [2] => [3] => funny [4] => [5] => string [6] => ) ---------- components: Regular Expressions messages: 218879 nosy: Wellington.Fan, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Behavior of word boundaries in regexes unexpected type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 17:49:44 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 21 May 2014 15:49:44 +0000 Subject: [issue21090] File read silently stops after EIO I/O error In-Reply-To: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za> Message-ID: <1400687384.37.0.923412385476.issue21090@psf.upfronthosting.co.za> Changes by Claudiu.Popa : ---------- nosy: -Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 17:59:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 May 2014 15:59:29 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1400687969.23.0.660800398211.issue20035@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I want to get this too, but perhaps there are some issues in a code. 1. Py_GetPrefix() returns wchar_t* string with maximal length MAXPATHLEN (defined in Include/osdefs.h as 256 on Windows). Then wcstombs() converts it to char* string. Are you sure that MAX_PATH (defined as 260 on Windows) is enough for converted string? I afraid that for multi-byte encoding it can be 2*MAXPATHLEN or even 3*MAXPATHLEN bytes. 2. After converting _tcl_library contains a path in locale encoding. And _putenv() works with it. I'm not sure, but I afraid that Tcl_SetVar() can expect UTF-8 encoded string. Please test with prefix containing non-ASCII characters (or even better with prefix containing East-Asian characters on East-Asian Windows). ---------- nosy: +haypo, scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 18:02:43 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 21 May 2014 16:02:43 +0000 Subject: [issue21551] Behavior of word boundaries in regexes unexpected In-Reply-To: <1400686692.12.0.566986679321.issue21551@psf.upfronthosting.co.za> Message-ID: <1400688163.3.0.114163716696.issue21551@psf.upfronthosting.co.za> R. David Murray added the comment: "Note that split will never split a string on an empty pattern match" You can get what you want this way: >>> re.split(r'(\w*)', 'a funky string') ['', 'a', ' ', 'funky', ' ', 'string', ''] Or use r'(\W*)' if you don't actually want the leading and training empty strings. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 18:19:00 2014 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 21 May 2014 16:19:00 +0000 Subject: [issue21551] Behavior of word boundaries in regexes unexpected In-Reply-To: <1400686692.12.0.566986679321.issue21551@psf.upfronthosting.co.za> Message-ID: <1400689140.32.0.858290149655.issue21551@psf.upfronthosting.co.za> Matthew Barnett added the comment: See also issue #852532, issue #3262 and issue #988761. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 21:41:04 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 21 May 2014 19:41:04 +0000 Subject: [issue8579] Add missing tests for FlushKey, LoadKey, and SaveKey in winreg In-Reply-To: <1272650551.21.0.0191974450566.issue8579@psf.upfronthosting.co.za> Message-ID: <1400701264.67.0.416248952105.issue8579@psf.upfronthosting.co.za> Claudiu.Popa added the comment: I'm working on this issue and I have a minimal patch ready, but it depends on issue21518, which proposes adding UnloadKey to winreg, so that we can unload the keys mounted with LoadKey. Also, that issue adds a mechanism for privilege acquisition, which I'll utilize for this issue. ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 22:02:45 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 May 2014 20:02:45 +0000 Subject: [issue21542] pprint doesn't work well for counters, sometimes shows them like a dict In-Reply-To: <1400599961.44.0.600133216015.issue21542@psf.upfronthosting.co.za> Message-ID: <1400702565.35.0.229533319057.issue21542@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think this tracker item should be subsumed by the effort to write a better pprint API. That would be better than trying to hack special cases into the current code which doesn't allow straight-forward customizations or extensions. I recommend this entry be closed as a known problem that is just one of many and needs to be solved in a much larger context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 22:49:12 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 21 May 2014 20:49:12 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1400705352.46.0.644147795305.issue21304@psf.upfronthosting.co.za> Alex Gaynor added the comment: Updated patch applies all of MAL's suggestions. Except the buffer() one, the purpose of the buffer() call is to make it an error to pass a list (or random other types) since you can call bytes() on any object. ---------- Added file: http://bugs.python.org/file35309/pbkdf2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 23:10:17 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 May 2014 21:10:17 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <1400706617.41.0.934715708566.issue21523@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 23:25:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 21 May 2014 21:25:14 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <1400707514.33.0.348458285395.issue21523@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Andrew, have you tried to bisect the Mercurial repository to find where the regression was introduced? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 21 23:52:28 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 21 May 2014 21:52:28 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1400709148.58.0.247334497798.issue21304@psf.upfronthosting.co.za> Alex Gaynor added the comment: As a note, the current code is basically identical to the code in Christain's backport, without the py3k compat. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 00:22:01 2014 From: report at bugs.python.org (Duke Dougal) Date: Wed, 21 May 2014 22:22:01 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1400710921.02.0.802473328004.issue19662@psf.upfronthosting.co.za> Duke Dougal added the comment: Is this one likely to be included in 3.5? It effectively breaks smtpd so it would be good to see it working again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 02:03:26 2014 From: report at bugs.python.org (Andrew Dalke) Date: Thu, 22 May 2014 00:03:26 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <1400717006.09.0.99334007686.issue21523@psf.upfronthosting.co.za> Andrew Dalke added the comment: Live and learn. I did my first bisect today. The first bad revision is: changeset: 51920:ef8fe9088696 branch: legacy-trunk parent: 51916:4e1556012584 user: Jeffrey Yasskin date: Sat Feb 28 19:03:21 2009 +0000 summary: Backport r69961 to trunk, replacing JUMP_IF_{TRUE,FALSE} with I confirmed that the parent did not have the problem. If you want me to diagnose this further, then I'll need some hints on what to do next. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 03:43:03 2014 From: report at bugs.python.org (Steven Barker) Date: Thu, 22 May 2014 01:43:03 +0000 Subject: [issue21547] '!s' formatting documentation bug In-Reply-To: <1400654359.7.0.699720681212.issue21547@psf.upfronthosting.co.za> Message-ID: <1400722983.04.0.928920645364.issue21547@psf.upfronthosting.co.za> Steven Barker added the comment: The behavior of !s with the format() methods isn't exactly the same as %s with % formatting. With the latter, the conversion depends on the type of the result string, which in turn depends on whether the format string *or any of the values values* is unicode: >>> class X(): def __str__(self): return "str" def __unicode__(self): return u"unicode" >>> "%s %s" % ("foo", X()) 'foo str' >>> "%s %s" % (u"foo", X()) u'foo unicode' >>> u"%s %s" % ("foo", X()) u'foo unicode' >>> u"%s %s" % (u"foo", X()) u'foo unicode' The format methods are more consistent, always returning the same type as the format string regardless of the types of the arguments (and using the appropriate converter): >>> "{} {!s}".format("foo", X()) 'foo str' >>> "{} {!s}".format(u"foo", X()) 'foo str' >>> u"{} {!s}".format("foo", X()) u'foo unicode' >>> u"{} {!s}".format(u"foo", X()) u'foo unicode' The documentation for %s conversion (in the second table here: https://docs.python.org/2/library/stdtypes.html#string-formatting-operations ) also suggests that it always uses str(), though the footnote for that table entry alludes to the behavior shown above without ever mentioning using unicode() for conversions explicitly. ---------- nosy: +Steven.Barker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 07:49:53 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 05:49:53 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400737793.8.0.387115242909.issue2506@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Ned, why is your proposal to turn-off ALL peephole transformations with COMMAND-LINE switch? * Why not just turn-off the jump-to-jump? Do you really need to disable constant folding and other transformations? * Have you explored whether the peephole.c code can be changed to indicate the continue-statement was visited? * Why does this have to be a command-line setting rather than a flag or environment variable settable by coverage.py? * Is there some less radical way the coverage.py can be taught to make the continue-statement as visited? * Are you requesting that optimization constraints be placed on all of the implementations of Python (Jython, PyPy, and IronPython) to make coverage.py perfect? * Do you want to place limits on what can be done by Victor's proposed AST tranformations which will occur upstream from the peepholer and will make higher level semantically-neutral transformations *prior* to code generation. * Have you considered whether the genererated PYC files need a different magic number or some other way to indicate that they aren't production code? * If coverage.py produces a report on different code than the production run, doesn't that undermine some of the confidence the meaningfulness of the report? In other words, are you sure that you're making the right request and that it is really worth it? Do we really have to open this can of worms to make coverage.py happy? ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 09:12:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 May 2014 07:12:52 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400742772.66.0.530000369346.issue2506@psf.upfronthosting.co.za> STINNER Victor added the comment: > Have you considered whether the genererated PYC files need a different magic number or some other way to indicate that they aren't production code? Would it make sense to use a different sys.implementation.cache_tag? For example, the tag si currently "cpython-35". We can use "cpython-35P" when peephole optimizations are disabled. So you can have separated .pyc and .pyo files and the disabling peephole optimizations is compatible with -O and -OO command line options. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 12:06:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 May 2014 10:06:05 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400753165.9.0.570887864249.issue2506@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, another option to solve the .pyc file issue is to *not* write .pyc files if the peephole optimizer is disabled. If you disable an optimizer, you probably don't care of performances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 12:46:25 2014 From: report at bugs.python.org (Ned Batchelder) Date: Thu, 22 May 2014 10:46:25 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400755585.44.0.214157880925.issue2506@psf.upfronthosting.co.za> Ned Batchelder added the comment: I thought we were discussing this on Python-Ideas? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 14:56:39 2014 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Thu, 22 May 2014 12:56:39 +0000 Subject: [issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value In-Reply-To: <1392053798.24.0.547929158873.issue20584@psf.upfronthosting.co.za> Message-ID: <1400763399.67.0.864376150746.issue20584@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: If you are thinking TL;DR: This fails on FreeBSD: >>> signal.signal(signal.SIGRTMAX, lambda *a: None) Traceback (most recent call last): File "", line 1, in ValueError: signal number out of range Although of infrequent use, I doubt that this is expected or desired behavior. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 15:05:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 May 2014 13:05:25 +0000 Subject: [issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value In-Reply-To: <1392053798.24.0.547929158873.issue20584@psf.upfronthosting.co.za> Message-ID: <1400763925.02.0.984548321436.issue20584@psf.upfronthosting.co.za> STINNER Victor added the comment: The current implementation of _signal requires a limit on the number of signals to its internal array used to store Python callback: static volatile struct { sig_atomic_t tripped; PyObject *func; } Handlers[NSIG]; If you want to kill the arbitrary limit, you need to change this structure. Maybe we need to find NSIG value differently on FreeBSD? For example try to use _SIG_MAXSIG. http://lists.freebsd.org/pipermail/freebsd-doc/2010-August/017500.html Please try attached on FreeBSD. ---------- keywords: +patch Added file: http://bugs.python.org/file35310/signal_nsig_freebsd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 16:36:01 2014 From: report at bugs.python.org (David Harrigan) Date: Thu, 22 May 2014 14:36:01 +0000 Subject: [issue21545] Tutorial: examples and comment about mutation methods In-Reply-To: <1400621853.89.0.606116768213.issue21545@psf.upfronthosting.co.za> Message-ID: <1400769361.84.0.870792024842.issue21545@psf.upfronthosting.co.za> David Harrigan added the comment: I've added the example and modified the final comment. ---------- keywords: +patch nosy: +David.Harrigan Added file: http://bugs.python.org/file35311/datastructures.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 16:42:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 May 2014 14:42:02 +0000 Subject: [issue21552] String length overflow in Tkinter Message-ID: <1400769722.86.0.708994855199.issue21552@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Tkinter converts str argument to C string and then pass it to Tcl. But Tcl handles string length as int and it can overflow if strlen() returns value > INT_MAX. Proposed patch introduces special conversion functions which ensure that string length will not overflow. It also corrects error message in getint(), getdouble() and getboolean() methods (e.g. "must be int or str" instead of "must be str") and adds tests for them. ---------- assignee: serhiy.storchaka components: Tkinter files: tkinter_strlen_overflow.patch keywords: patch messages: 218898 nosy: gpolo, loewis, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: String length overflow in Tkinter type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35312/tkinter_strlen_overflow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 16:59:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 May 2014 14:59:13 +0000 Subject: [issue21552] String length overflow in Tkinter In-Reply-To: <1400769722.86.0.708994855199.issue21552@psf.upfronthosting.co.za> Message-ID: <1400770753.07.0.482004297491.issue21552@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file35313/tkinter_strlen_overflow-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 17:21:27 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 22 May 2014 15:21:27 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1400772087.35.0.942946778312.issue19662@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, this will be fixed in 3.5 one way or another. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 17:23:33 2014 From: report at bugs.python.org (Maciej Szulik) Date: Thu, 22 May 2014 15:23:33 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1400772213.48.0.894183185515.issue19662@psf.upfronthosting.co.za> Maciej Szulik added the comment: I'll try to take care of this issue in the following few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 17:37:33 2014 From: report at bugs.python.org (mythsmith) Date: Thu, 22 May 2014 15:37:33 +0000 Subject: [issue21553] Behaviour of modules depends on how they where imported Message-ID: <1400773053.58.0.249917369677.issue21553@psf.upfronthosting.co.za> New submission from mythsmith: I found a condition where different behaviour could be observed depending on how a module is imported. It seems to be different to write: import module # against: from package import module In the attachment you find a minimal package (imptest) with this organization: imptest |-> __init__.py (empty) |-> m.py (module which initializes a variable "foo=0") |- sub (package) |-> __init__.py (empty) |-> subm.py (module which, upon import, changes "m.foo=1") And two scripts which can be directly executed: |-> run0.py (using "import m") |-> run1.py (using "from imptest import m") Contents of the module m: ######################### foo=0 def do(): global foo foo=1 print('doing foo=',foo) print("imported foo=",foo) Contents of module subm: ####################### from imptest import m from imptest import m print("imported sub, foo=",m.foo) Both run0.py and run1.py imports module m and calls the do() function, thus theoretically changing foo to 1. Both later import the subm module, which in turn imports again the m module. What I would expect is that, since m is already in memory, it is not really imported again: so foo remains equal to 1 also after subm import. I found that this actually depends on how I imported m in the script. Contents of run0.py: #################### import m m.do() print("importing subm") from imptest.sub import subm Result: imported m; foo= 0 doing foo= 1 importing subm imported m; foo= 0 imported sub, foo= 0 As you can see from printout "importing subm", the m module is imported again and thus foo is reset to 0. In run1.py, I changed the line "import m" to "from imptest import m", and got the expected behaviour: Contents of run1.py: #################### from imptest import m m.do() print("importing subm") from imptest.sub import subm Result: imported m; foo= 0 doing foo= 1 importing subm imported sub, foo= 1 I know that directly running a module in the first level of a package may seem strange or not correct, but could someone explain why this is happening? I would expect a module to be loaded in memory at the first import and then referred in any way I later or elsewhere in the program choose to import it. ---------- components: Interpreter Core files: imptest.zip messages: 218901 nosy: mythsmith priority: normal severity: normal status: open title: Behaviour of modules depends on how they where imported type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file35314/imptest.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 17:44:32 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 22 May 2014 15:44:32 +0000 Subject: [issue21553] Behaviour of modules depends on how they where imported In-Reply-To: <1400773053.58.0.249917369677.issue21553@psf.upfronthosting.co.za> Message-ID: <1400773472.83.0.696150532578.issue21553@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 18:01:58 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 22 May 2014 16:01:58 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1400774518.33.0.265036621626.issue20035@psf.upfronthosting.co.za> Zachary Ware added the comment: Thank you, Serhiy; those are exactly the kinds of things I don't know enough about and had concerns about. I'll take another stab and see if I can come up with anything better. Suggestions welcome :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 18:05:36 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 22 May 2014 16:05:36 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400774736.43.0.544812916933.issue2506@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 19:17:27 2014 From: report at bugs.python.org (Peter Otten) Date: Thu, 22 May 2014 17:17:27 +0000 Subject: [issue21553] Behaviour of modules depends on how they where imported In-Reply-To: <1400773053.58.0.249917369677.issue21553@psf.upfronthosting.co.za> Message-ID: <1400779046.99.0.0722556715482.issue21553@psf.upfronthosting.co.za> Peter Otten added the comment: Here's a simpler demo for what I believe you are experiencing: $ mkdir package $ cd package/ $ touch __ini__.py module.py $ export PYTHONPATH=.. $ python3 Python 3.3.2+ (default, Feb 28 2014, 00:52:16) [GCC 4.8.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import module, package.module >>> module is package.module False Even though module and package.module correspond to the same file Python does not recognize that you intend the former to be part of a package. Your run0.py script goes through its sys.path entries and unfortunately the first entry points into a package so that all modules in that package become also visible as toplevel modules. A good way to avoid this trap is to use relative imports >>> from . import module Traceback (most recent call last): File "", line 1, in SystemError: Parent module '' not loaded, cannot perform relative import ---------- nosy: +peter.otten _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 19:39:05 2014 From: report at bugs.python.org (Erik Kusko) Date: Thu, 22 May 2014 17:39:05 +0000 Subject: [issue21554] Possible Error in "Brief Tour of the Standard Library" Message-ID: <1400780345.53.0.941799194043.issue21554@psf.upfronthosting.co.za> New submission from Erik Kusko: In https://docs.python.org/3/tutorial/stdlib.html, there is an example: >>> import shutil >>> shutil.copyfile('data.db', 'archive.db') >>> shutil.move('/build/executables', 'installdir') Should it not be: >>> import shutil >>> shutil.copyfile('data.db', 'archive.db') 'archive.db' >>> shutil.move('/build/executables', 'installdir') 'installdir' ? I am run under Windows, so I don't know if the behavior is different than under Linux. Under Windows the destination file and destination directory, respectively, are echoed to stdout. ---------- assignee: docs at python components: Documentation messages: 218904 nosy: Pitmaster, docs at python priority: normal severity: normal status: open title: Possible Error in "Brief Tour of the Standard Library" type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 19:41:38 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 22 May 2014 17:41:38 +0000 Subject: [issue21553] Behaviour of modules depends on how they where imported In-Reply-To: <1400773053.58.0.249917369677.issue21553@psf.upfronthosting.co.za> Message-ID: <1400780498.62.0.127185968469.issue21553@psf.upfronthosting.co.za> Eric Snow added the comment: This is a consequence of a script's directory getting prepended to sys.path. See issue #13475. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 19:43:24 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 22 May 2014 17:43:24 +0000 Subject: [issue21554] Possible Error in "Brief Tour of the Standard Library" In-Reply-To: <1400780345.53.0.941799194043.issue21554@psf.upfronthosting.co.za> Message-ID: <1400780604.47.0.0134095495632.issue21554@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, this is a recent enhancement and the example was not updated to match. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 20:34:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 22 May 2014 18:34:48 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <1400783688.54.0.951243019875.issue21523@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You're right, CPU time is burnt by stackdepth_walk(). The underlying issue is that max stacksize is computed a bit pessimistically with the new opcodes (JUMP_IF_{TRUE,FALSE}_OR_POP). On normal functions there wouldn't be a sizable difference, but on pathological cases such as yours, a code object could end up claiming a large stack size (as large of the number of such opcodes) rather than a very small number. Still, of course, stackdepth_walk() should not blow up when computing a large stack size, but fixing the opcode's stack effect in compile.c seems to fix the issue anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 20:38:33 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 22 May 2014 18:38:33 +0000 Subject: [issue15293] AST nodes do not support garbage collection In-Reply-To: <1341744454.01.0.740763019773.issue15293@psf.upfronthosting.co.za> Message-ID: <1400783913.99.0.668909330441.issue15293@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Would it be possible to backport this to 2.7? We've been bitten by this at work (pyflakes introduces reference cycles in AST). ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 20:46:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 22 May 2014 18:46:12 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <1400784372.02.0.588463529596.issue21523@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file35315/stackdepth.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 20:48:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 22 May 2014 18:48:21 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: <1399576407.19.0.800132565912.issue21455@psf.upfronthosting.co.za> Message-ID: <3gZKbS5yDMz7Lr9@mail.python.org> Roundup Robot added the comment: New changeset 09371221e59d by Charles-Fran?ois Natali in branch 'default': Issue #21455: Add a default backlog to socket.listen(). http://hg.python.org/cpython/rev/09371221e59d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 21:02:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 22 May 2014 19:02:48 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <1400785368.83.0.15500995614.issue21523@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch adding some tests. ---------- stage: -> patch review versions: -Python 3.3 Added file: http://bugs.python.org/file35316/stackdepth2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 21:05:56 2014 From: report at bugs.python.org (Florent Xicluna) Date: Thu, 22 May 2014 19:05:56 +0000 Subject: [issue15293] AST nodes do not support garbage collection In-Reply-To: <1341744454.01.0.740763019773.issue15293@psf.upfronthosting.co.za> Message-ID: <1400785556.2.0.0615682289195.issue15293@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 21:06:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 22 May 2014 19:06:06 +0000 Subject: [issue21555] gcmodule.c could use pytime.h Message-ID: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> New submission from Antoine Pitrou: gcmodule.c is able to displayed elapsed time of garbage collection runs. It currently does it by poking inside the time module to call time.time() and convert it to a C double. It could instead use the new pytime.h facilities. ---------- components: Extension Modules, Library (Lib) keywords: easy messages: 218912 nosy: pitrou priority: low severity: normal stage: needs patch status: open title: gcmodule.c could use pytime.h type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 21:13:00 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 22 May 2014 19:13:00 +0000 Subject: [issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value In-Reply-To: <1392053798.24.0.547929158873.issue20584@psf.upfronthosting.co.za> Message-ID: <1400785980.24.0.756603589553.issue20584@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > If you want to kill the arbitrary limit, you need to change this > structure. Or the structure could simply host up to 256 handlers, regardless of NSIG. I'm uncomfortable with tweaking NSIG specifically for FreeBSD. If the FreeBSD headers export the wrong value, it's not really Python's problem. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 21:31:14 2014 From: report at bugs.python.org (Sunny K) Date: Thu, 22 May 2014 19:31:14 +0000 Subject: [issue21555] gcmodule.c could use pytime.h In-Reply-To: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> Message-ID: <1400787074.15.0.758626963964.issue21555@psf.upfronthosting.co.za> Changes by Sunny K : ---------- nosy: +sunfinite _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 21:40:39 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 22 May 2014 19:40:39 +0000 Subject: [issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value In-Reply-To: <1400785980.24.0.756603589553.issue20584@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Or the structure could simply host up to 256 handlers, regardless of NSIG. > I'm uncomfortable with tweaking NSIG specifically for FreeBSD. If the FreeBSD headers export the wrong value, it's not really Python's problem. Agreed. And the current code is already complicated enough: #ifndef NSIG # if defined(_NSIG) # define NSIG _NSIG /* For BSD/SysV */ # elif defined(_SIGMAX) # define NSIG (_SIGMAX + 1) /* For QNX */ # elif defined(SIGMAX) # define NSIG (SIGMAX + 1) /* For djgpp */ # else # define NSIG 64 /* Use a reasonable default value */ # endif #endif ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 21:47:29 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 22 May 2014 19:47:29 +0000 Subject: [issue21534] 404 on documentation download links In-Reply-To: <1400506899.65.0.0656735087144.issue21534@psf.upfronthosting.co.za> Message-ID: <1400788049.67.0.95331279805.issue21534@psf.upfronthosting.co.za> Zachary Ware added the comment: Reports continue to pour in on docs@, 25 reports for 2.7.7rc1 and 3.4.1 so far by my count. Is there anything I can do to help on this? It looks to me like the files just haven't been uploaded, but I don't know where exactly they should be uploaded to, nor do I have the keys to do it. ---------- assignee: docs at python -> priority: high -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 22:05:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 May 2014 20:05:13 +0000 Subject: [issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value In-Reply-To: <1392053798.24.0.547929158873.issue20584@psf.upfronthosting.co.za> Message-ID: <1400789113.61.0.765594037558.issue20584@psf.upfronthosting.co.za> STINNER Victor added the comment: Extract of system signal.h: #if __BSD_VISIBLE #define NSIG 32 /* number of old signals (counting 0) */ #endif whereas contains: #define _SIG_MAXSIG 128 In signalmodule.c, NSIG is still important in the function sigset_to_set(): we need to have the exact maximum signal number of a sigset. I prefer to make signalmodule.c a little big uglier to fix the NSIG value. I tested attached signal_nsig_freebsd-2.patch on FreeBSD 9. I suggest to backport this fix to Python 2.7 and 3.4. ---------- versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file35317/signal_nsig_freebsd-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 22:06:44 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 22 May 2014 20:06:44 +0000 Subject: [issue21534] 404 on documentation download links In-Reply-To: <1400506899.65.0.0656735087144.issue21534@psf.upfronthosting.co.za> Message-ID: <1400789204.7.0.761001857331.issue21534@psf.upfronthosting.co.za> Ned Deily added the comment: At the moment, the links for 3.4.1 documentation downloads at https://docs.python.org/3/download.html appear to be working AFAICT; anyone see otherwise? However, the 2.7.7rc1 links are broken (https://docs.python.org/2/download.html). Benjamin? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 22:19:41 2014 From: report at bugs.python.org (David Harrigan) Date: Thu, 22 May 2014 20:19:41 +0000 Subject: [issue21554] Possible Error in "Brief Tour of the Standard Library" In-Reply-To: <1400780345.53.0.941799194043.issue21554@psf.upfronthosting.co.za> Message-ID: <1400789981.57.0.899276788389.issue21554@psf.upfronthosting.co.za> Changes by David Harrigan : ---------- keywords: +patch Added file: http://bugs.python.org/file35318/stdlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 22:23:03 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 22 May 2014 20:23:03 +0000 Subject: [issue21534] 404 on documentation download links In-Reply-To: <1400506899.65.0.0656735087144.issue21534@psf.upfronthosting.co.za> Message-ID: <1400790183.08.0.209930185717.issue21534@psf.upfronthosting.co.za> Zachary Ware added the comment: You're right, Ned; 3.4.1 is working for me now, but 2.7.7rc1 is still broken. (Sorry for not checking again!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 22:45:13 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 22 May 2014 20:45:13 +0000 Subject: [issue21455] add default backlog to socket.listen() In-Reply-To: <1399576407.19.0.800132565912.issue21455@psf.upfronthosting.co.za> Message-ID: <1400791513.38.0.317415378468.issue21455@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed, thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 22:55:07 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 22 May 2014 20:55:07 +0000 Subject: [issue21556] try to use hashtable in pickle Message-ID: <1400792107.19.0.965541378341.issue21556@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: This patch is an attempt at making pickle use Modules/hashtable.{h,c} instead of its hash table ad-hoc implementation for its memoization table. I'm saying attempt, because although it works correctly, some benchmarks are actually slower. I didn't profile it, so I don't know if it's due to the hashtable implementation, function call overheads, etc. If we manage to bring this on par with pickle's ad-hoc implementation, it would probably be interesting to replace it. If not, then we can just drop this patch :-) Also, there might be other places in the code base which might benefit from this generic hashtable, maybe. ---------- files: pickle_use_hashtable.diff keywords: patch messages: 218920 nosy: haypo, neologix, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: try to use hashtable in pickle type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35319/pickle_use_hashtable.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 22:57:06 2014 From: report at bugs.python.org (Maciej Szulik) Date: Thu, 22 May 2014 20:57:06 +0000 Subject: [issue21555] gcmodule.c could use pytime.h In-Reply-To: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> Message-ID: <1400792226.91.0.80064397826.issue21555@psf.upfronthosting.co.za> Changes by Maciej Szulik : ---------- nosy: +maciej.szulik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 23:33:48 2014 From: report at bugs.python.org (Chris Rebert) Date: Thu, 22 May 2014 21:33:48 +0000 Subject: [issue21557] os.popen & os.system lack shell-related security warnings Message-ID: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za> New submission from Chris Rebert: Since these functions run shell commands, which is a common vector for security-related bugs (see * http://cwe.mitre.org/data/definitions/78.html * http://cwe.mitre.org/data/definitions/88.html ), I suggest that they should have security warning boxes analogous to the one for the `subprocess` module: https://docs.python.org/2/library/subprocess.html#frequently-used-arguments ---------- assignee: docs at python components: Documentation messages: 218921 nosy: cvrebert, docs at python priority: normal severity: normal status: open title: os.popen & os.system lack shell-related security warnings versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 23:41:42 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 22 May 2014 21:41:42 +0000 Subject: [issue16442] PATH_MAX vs MAXPATHLEN vs pathconf(..., _PC_PATH_MAX). In-Reply-To: <1352393326.63.0.0902907389394.issue16442@psf.upfronthosting.co.za> Message-ID: <1400794902.96.0.936017545587.issue16442@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 23:45:37 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 22 May 2014 21:45:37 +0000 Subject: [issue18061] m68k Python 3.3 test results In-Reply-To: <1369515304.6.0.15163680976.issue18061@psf.upfronthosting.co.za> Message-ID: <1400795137.0.0.104186924892.issue18061@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 23:53:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 22 May 2014 21:53:14 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1400795594.41.0.574887381464.issue20260@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 23:55:29 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 22 May 2014 21:55:29 +0000 Subject: [issue19463] assertGdbRepr depends on hash randomization / endianess In-Reply-To: <1383245602.59.0.0634998131847.issue19463@psf.upfronthosting.co.za> Message-ID: <1400795729.22.0.0214947129488.issue19463@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 22 23:56:18 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 22 May 2014 21:56:18 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1400795778.2.0.370944892157.issue20260@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.rosenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:01:32 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 22 May 2014 22:01:32 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1400796091.99.0.705722059718.issue15989@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:06:50 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 22 May 2014 22:06:50 +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: <1400796410.29.0.0542853399688.issue20015@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:09:30 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 22 May 2014 22:09:30 +0000 Subject: [issue19533] Unloading docstrings from memory if -OO is given In-Reply-To: <1383980059.61.0.697157457336.issue19533@psf.upfronthosting.co.za> Message-ID: <1400796570.31.0.803820325603.issue19533@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:11:49 2014 From: report at bugs.python.org (Jason Browne) Date: Thu, 22 May 2014 22:11:49 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1400796709.67.0.86600836428.issue21261@psf.upfronthosting.co.za> Changes by Jason Browne : ---------- nosy: +cdspace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:13:27 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 22 May 2014 22:13:27 +0000 Subject: [issue19531] Loading -OO bytecode files if -O was requested can lead to problems In-Reply-To: <1383976647.12.0.628513721742.issue19531@psf.upfronthosting.co.za> Message-ID: <1400796807.83.0.152193967351.issue19531@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:15:30 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 22:15:30 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <1400796930.74.0.984095176641.issue21523@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The patch looks like the correct solution. That said, I'm more impressed that you were able to test it so cleanly :-) ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:21:59 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 22:21:59 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1400797319.69.0.789524553336.issue2506@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Victor] > Oh, another option to solve the .pyc file issue is to *not* > write .pyc files if the peephole optimizer is disabled. > If you disable an optimizer, you probably don't care of performances. That is an inspired idea and would help address one of the possible problems that could be caused by a new on/off switch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:27:58 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 22:27:58 +0000 Subject: [issue21554] Possible Error in "Brief Tour of the Standard Library" In-Reply-To: <1400780345.53.0.941799194043.issue21554@psf.upfronthosting.co.za> Message-ID: <1400797678.85.0.643827367898.issue21554@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:30:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 22 May 2014 22:30:38 +0000 Subject: [issue21383] "make touch" fails when the build directory is not the source directory In-Reply-To: <1398760947.89.0.691766045615.issue21383@psf.upfronthosting.co.za> Message-ID: <3gZQWw0JWkz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 1fd37eefa141 by Ned Deily in branch '2.7': Issue #21383: Allow "make touch" to work when building outside of the http://hg.python.org/cpython/rev/1fd37eefa141 New changeset 6f85967c908e by Ned Deily in branch '2.7': Issue #21383: OS X installer builds now use "make touch". http://hg.python.org/cpython/rev/6f85967c908e New changeset 15b5559b1068 by Ned Deily in branch '3.4': Issue #21383: OS X installer builds now use "make touch". http://hg.python.org/cpython/rev/15b5559b1068 New changeset 24f198c520c1 by Ned Deily in branch 'default': Issue #21383: OS X installer builds now use "make touch". http://hg.python.org/cpython/rev/24f198c520c1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:31:36 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 22 May 2014 22:31:36 +0000 Subject: [issue21383] "make touch" fails when the build directory is not the source directory In-Reply-To: <1398760947.89.0.691766045615.issue21383@psf.upfronthosting.co.za> Message-ID: <1400797896.02.0.290400495923.issue21383@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:37:50 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 22 May 2014 22:37:50 +0000 Subject: [issue21556] try to use hashtable in pickle In-Reply-To: <1400792107.19.0.965541378341.issue21556@psf.upfronthosting.co.za> Message-ID: <1400798270.47.0.00952943938505.issue21556@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +alexandre.vassalotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:38:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 22 May 2014 22:38:05 +0000 Subject: [issue21554] Possible Error in "Brief Tour of the Standard Library" In-Reply-To: <1400780345.53.0.941799194043.issue21554@psf.upfronthosting.co.za> Message-ID: <3gZQhX3sQ1z7Lr6@mail.python.org> Roundup Robot added the comment: New changeset e07e347688a0 by Raymond Hettinger in branch '3.4': Issue 21554: Repair an out-of-date tutorial example to reflect changes in shutil. http://hg.python.org/cpython/rev/e07e347688a0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:38:54 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 22:38:54 +0000 Subject: [issue21554] Possible Error in "Brief Tour of the Standard Library" In-Reply-To: <1400780345.53.0.941799194043.issue21554@psf.upfronthosting.co.za> Message-ID: <1400798334.13.0.866450614577.issue21554@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Fixed. Thanks for the clear bug report. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:42:01 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 22:42:01 +0000 Subject: [issue21545] Tutorial: examples and comment about mutation methods In-Reply-To: <1400621853.89.0.606116768213.issue21545@psf.upfronthosting.co.za> Message-ID: <1400798521.69.0.864533755709.issue21545@psf.upfronthosting.co.za> Raymond Hettinger added the comment: That looks good and is ready to apply. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:44:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 22:44:39 +0000 Subject: [issue21542] pprint doesn't work well for counters, sometimes shows them like a dict In-Reply-To: <1400599961.44.0.600133216015.issue21542@psf.upfronthosting.co.za> Message-ID: <1400798679.82.0.513797677535.issue21542@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> duplicate status: open -> closed superseder: -> general pprint rewrite _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:45:59 2014 From: report at bugs.python.org (Ram Rachum) Date: Thu, 22 May 2014 22:45:59 +0000 Subject: [issue21542] pprint doesn't work well for counters, sometimes shows them like a dict In-Reply-To: <1400599961.44.0.600133216015.issue21542@psf.upfronthosting.co.za> Message-ID: <1400798759.08.0.286698911972.issue21542@psf.upfronthosting.co.za> Ram Rachum added the comment: Maybe though this item should result in at least a test case for the future `pprint` redesign? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:56:03 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 22:56:03 +0000 Subject: [issue21027] difflib new cli interface In-Reply-To: <1395521056.07.0.611061866436.issue21027@psf.upfronthosting.co.za> Message-ID: <1400799362.97.0.726091265471.issue21027@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry guys, I appreciate your enthusiasm, but when I designed the code, I intentionally put it in the Tools/scripts section rather than as a command-line option for a library module. As the author of the context_diff and unified_diff, I was concerned that wasn't competitive with a real diff tool in a numbers of ways. IIRC, Guido had problems with it and couldn't get it to work with "patch" and Uncle Timmy noted some algorithmic difference with other diffs. I'm going to close this because I think it is not a good idea to offer an "attractive nuisance". Victor, I attended David's talk and enjoyed it thoroughly. However, if you thought he was arguing for the standard library to be turned into a suite of command-line unix replacements, you may have missed the point. In addition, most of his "magic" was done by writing scripts that incorporated the tools (for example, the diffs were part of a script that reconstructed the change history for a series of files). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 00:58:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 22:58:39 +0000 Subject: [issue19361] Specialize exceptions thrown by JSON parser In-Reply-To: <1382527334.08.0.362620105205.issue19361@psf.upfronthosting.co.za> Message-ID: <1400799519.16.0.621246382648.issue19361@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Adding it to the stdlib is only matter of time. I think we can go forward with it right now. ---------- nosy: +bob.ippolito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 01:00:51 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 23:00:51 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1400799651.26.0.514149333575.issue21198@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 01:04:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 22 May 2014 23:04:40 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <3gZRHC3wKqz7LrR@mail.python.org> Roundup Robot added the comment: New changeset 630bc60cba04 by Raymond Hettinger in branch '3.4': Issue 21198: Minor tarfile documentation bug. http://hg.python.org/cpython/rev/630bc60cba04 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 01:06:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 22 May 2014 23:06:11 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <3gZRJy3yR3z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 5c1fb67f2edf by Raymond Hettinger in branch '2.7': Issue 21198: Minor tarfile documentation bug. http://hg.python.org/cpython/rev/5c1fb67f2edf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 01:06:48 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 23:06:48 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1400800008.48.0.811131976047.issue21198@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the report and the patch. Fixed now :-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 01:07:19 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 23:07:19 +0000 Subject: [issue21479] Document TarFile.open() as a classmethod In-Reply-To: <1399906899.24.0.584343681531.issue21479@psf.upfronthosting.co.za> Message-ID: <1400800039.46.0.718283380342.issue21479@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 01:11:50 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 22 May 2014 23:11:50 +0000 Subject: [issue21555] gcmodule.c could use pytime.h In-Reply-To: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> Message-ID: <1400800310.82.0.876629928971.issue21555@psf.upfronthosting.co.za> Changes by Nikolaus Rath : ---------- nosy: +nikratio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 01:14:02 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 May 2014 23:14:02 +0000 Subject: [issue21542] pprint doesn't work well for counters, sometimes shows them like a dict In-Reply-To: <1400599961.44.0.600133216015.issue21542@psf.upfronthosting.co.za> Message-ID: <1400800442.31.0.440202106522.issue21542@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please add a note to the other tracker item. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 01:20:37 2014 From: report at bugs.python.org (Bob Ippolito) Date: Thu, 22 May 2014 23:20:37 +0000 Subject: [issue19361] Specialize exceptions thrown by JSON parser In-Reply-To: <1382527334.08.0.362620105205.issue19361@psf.upfronthosting.co.za> Message-ID: <1400800837.15.0.874668230437.issue19361@psf.upfronthosting.co.za> Bob Ippolito added the comment: simplejson v3.5.1 is probably a good target, let me know if there's anything that you'd like me to merge back in from stdlib to make maintenance easier. I haven't been tracking stdlib except when I've been added to issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 02:29:13 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 23 May 2014 00:29:13 +0000 Subject: [issue21553] Behaviour of modules depends on how they where imported In-Reply-To: <1400773053.58.0.249917369677.issue21553@psf.upfronthosting.co.za> Message-ID: <1400804953.54.0.957903244353.issue21553@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- superseder: -> Add '-p'/'--path0' command line option to override sys.path[0] initialisation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 02:48:35 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 May 2014 00:48:35 +0000 Subject: [issue21481] Argpase Namespace object methods __eq__ and __ne__ raise TypeError when comparing to None In-Reply-To: <1399910902.34.0.399069985077.issue21481@psf.upfronthosting.co.za> Message-ID: <1400806115.07.0.635501192294.issue21481@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The equality and inequality tests need to return NotImplemented when comparing to an unknown type. ---------- assignee: -> rhettinger nosy: +bethard, rhettinger priority: normal -> low stage: -> needs patch type: -> behavior versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 03:25:22 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 23 May 2014 01:25:22 +0000 Subject: [issue21198] Minor tarfile documentation bug In-Reply-To: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za> Message-ID: <1400808322.8.0.735224519972.issue21198@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 03:55:51 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 May 2014 01:55:51 +0000 Subject: [issue21481] Argpase Namespace object methods __eq__ and __ne__ raise TypeError when comparing to None In-Reply-To: <1399910902.34.0.399069985077.issue21481@psf.upfronthosting.co.za> Message-ID: <1400810151.65.0.422562629401.issue21481@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file35320/fix_argparse_eq.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 04:43:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 02:43:41 +0000 Subject: [issue21479] Document TarFile.open() as a classmethod In-Reply-To: <1399906899.24.0.584343681531.issue21479@psf.upfronthosting.co.za> Message-ID: <3gZX7w1Cn2z7Lp9@mail.python.org> Roundup Robot added the comment: New changeset e6a9beaff8c9 by Raymond Hettinger in branch '2.7': Issue 21479: Fix markup for the TarFile.open() classmethod. http://hg.python.org/cpython/rev/e6a9beaff8c9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 04:47:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 02:47:21 +0000 Subject: [issue21479] Document TarFile.open() as a classmethod In-Reply-To: <1399906899.24.0.584343681531.issue21479@psf.upfronthosting.co.za> Message-ID: <3gZXD917N7z7Lp9@mail.python.org> Roundup Robot added the comment: New changeset 37d2a6bcf7ae by Raymond Hettinger in branch '3.4': Issue 21479: Fix markup for the TarFile.open() classmethod. http://hg.python.org/cpython/rev/37d2a6bcf7ae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 04:47:48 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 May 2014 02:47:48 +0000 Subject: [issue21479] Document TarFile.open() as a classmethod In-Reply-To: <1399906899.24.0.584343681531.issue21479@psf.upfronthosting.co.za> Message-ID: <1400813268.41.0.642387751705.issue21479@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 04:48:43 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 May 2014 02:48:43 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1400813323.53.0.24008532247.issue21137@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 05:01:33 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 23 May 2014 03:01:33 +0000 Subject: [issue21479] Document TarFile.open() as a classmethod In-Reply-To: <1399906899.24.0.584343681531.issue21479@psf.upfronthosting.co.za> Message-ID: <1400814093.52.0.992250409437.issue21479@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for committing this, Raymond. ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 05:02:10 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 May 2014 03:02:10 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1400814130.11.0.480655359609.issue21137@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The patch is just about ready to go but needs to address some failing tests: ====================================================================== FAIL: test_locked_repr (test.test_importlib.test_locks.Frozen_ModuleLockAsRLockTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/raymond/cpython/Lib/test/lock_tests.py", line 91, in test_locked_repr self.assertRegex(repr(lock), "") AssertionError: Regex didn't match: '' not found in "_ModuleLock('some_lock') at 4438138048" ====================================================================== FAIL: test_repr (test.test_importlib.test_locks.Frozen_ModuleLockAsRLockTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/raymond/cpython/Lib/test/lock_tests.py", line 85, in test_repr self.assertRegex(repr(lock), "") AssertionError: Regex didn't match: '' not found in "_ModuleLock('some_lock') at 4439151784" ====================================================================== FAIL: test_locked_repr (test.test_importlib.test_locks.Source_ModuleLockAsRLockTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/raymond/cpython/Lib/test/lock_tests.py", line 91, in test_locked_repr self.assertRegex(repr(lock), "") AssertionError: Regex didn't match: '' not found in "_ModuleLock('some_lock') at 4438192312" ====================================================================== FAIL: test_repr (test.test_importlib.test_locks.Source_ModuleLockAsRLockTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/raymond/cpython/Lib/test/lock_tests.py", line 85, in test_repr self.assertRegex(repr(lock), "") AssertionError: Regex didn't match: '' not found in "_ModuleLock('some_lock') at 4438192480" ---------------------------------------------------------------------- Ran 970 tests in 0.549s FAILED (failures=4, skipped=7, expected failures=1) test test_importlib failed 1 test failed: test_importlib ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 05:09:13 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 May 2014 03:09:13 +0000 Subject: [issue21213] Memory bomb by incorrect custom serializer to json.dumps In-Reply-To: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za> Message-ID: <1400814553.05.0.435688245282.issue21213@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +bob.ippolito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 05:24:28 2014 From: report at bugs.python.org (Dougal Graham) Date: Fri, 23 May 2014 03:24:28 +0000 Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za> Message-ID: <1400815468.75.0.0565363988487.issue10731@psf.upfronthosting.co.za> Dougal Graham added the comment: I recenly encuntered this error in OSX 10.9.2, using pthon 3.3 and 3.4 from Homebrew. I tried installing activetcl 8.6 package, but it still fails dependably. ---------- nosy: +Dougal.Graham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 05:39:33 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 23 May 2014 03:39:33 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1400816373.51.0.669285645048.issue21137@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a new patch. I've disabled test_repr and test_locked_repr tests in Lib/test/test_importlib/test_locks.py. ---------- Added file: http://bugs.python.org/file35321/issue21137_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 05:55:54 2014 From: report at bugs.python.org (Dougal Graham) Date: Fri, 23 May 2014 03:55:54 +0000 Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za> Message-ID: <1400817354.57.0.426009279517.issue10731@psf.upfronthosting.co.za> Dougal Graham added the comment: I have resolved this by using the official Python distribution, rather than Homebrew's. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 05:58:48 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 23 May 2014 03:58:48 +0000 Subject: [issue21558] Fix a typo in the contextlib docs Message-ID: <1400817528.11.0.0994185866372.issue21558@psf.upfronthosting.co.za> New submission from Berker Peksag: >From the code example at https://docs.python.org/3.5/library/contextlib.html#supporting-a-variable-number-of-context-managers "if need_special resource:" (see line 4) should be "if need_special_resource:". Related changeset: http://hg.python.org/cpython/rev/5d91d87b5969 ---------- assignee: docs at python components: Documentation files: contextlib-typo.diff keywords: patch messages: 218944 nosy: berker.peksag, docs at python priority: normal severity: normal stage: patch review status: open title: Fix a typo in the contextlib docs versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35322/contextlib-typo.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 06:31:41 2014 From: report at bugs.python.org (Bob Ippolito) Date: Fri, 23 May 2014 04:31:41 +0000 Subject: [issue21213] Memory bomb by incorrect custom serializer to json.dumps In-Reply-To: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za> Message-ID: <1400819501.77.0.823832186762.issue21213@psf.upfronthosting.co.za> Bob Ippolito added the comment: I agree with ebfe. It's a case that only comes up if you're writing your own default handlers, and there's not a reasonable solution to avoid this issue. You would've gotten a "RuntimeError: maximum recursion depth exceeded" if it wasn't for the behavior of repr here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 06:35:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 04:35:16 +0000 Subject: [issue21545] Tutorial: examples and comment about mutation methods In-Reply-To: <1400621853.89.0.606116768213.issue21545@psf.upfronthosting.co.za> Message-ID: <3gZZcf6ntfz7Lpy@mail.python.org> Roundup Robot added the comment: New changeset 6fc09f30b514 by Terry Jan Reedy in branch '2.7': Issue #21545: Add .pop example and tweak comment about pure mutation methods. http://hg.python.org/cpython/rev/6fc09f30b514 New changeset 3f2b6034b73a by Terry Jan Reedy in branch '3.4': Issue #21545: Add .pop example and tweak comment about pure mutation methods. http://hg.python.org/cpython/rev/3f2b6034b73a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 06:38:02 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 May 2014 04:38:02 +0000 Subject: [issue21545] Tutorial: examples and comment about mutation methods In-Reply-To: <1400621853.89.0.606116768213.issue21545@psf.upfronthosting.co.za> Message-ID: <1400819882.72.0.971903020954.issue21545@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks David. If this is not to be your last contribution, and we hope not, please fill out the contributor agreement, if you have hot already, at https://www.python.org/psf/contrib/contrib-form/ ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 08:01:57 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 May 2014 06:01:57 +0000 Subject: [issue21213] Memory bomb by incorrect custom serializer to json.dumps In-Reply-To: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za> Message-ID: <1400824917.39.0.996952823275.issue21213@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 10:20:29 2014 From: report at bugs.python.org (Tobias Oberstein) Date: Fri, 23 May 2014 08:20:29 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1400833229.78.0.763335936452.issue21356@psf.upfronthosting.co.za> Changes by Tobias Oberstein : ---------- nosy: +oberstet _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 10:43:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 May 2014 08:43:42 +0000 Subject: [issue21556] try to use hashtable in pickle In-Reply-To: <1400792107.19.0.965541378341.issue21556@psf.upfronthosting.co.za> Message-ID: <1400834622.06.0.445075686891.issue21556@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I'm saying attempt, because although it works correctly, some benchmarks are actually slower. > I didn't profile it, so I don't know if it's due to the hashtable implementation, function call overheads, etc. It probably shows that Python dicts (which the pickle hashtable is a rip-off of, module refcounting) are more optimized than the average hash table implementation :-) But also, _Py_hashtable_hash_ptr is quite crude in that it doesn't even try to compensate for pointer alignment, so there will automatically be many collisions. Only one hash bucket every 8 or 16 will be used, at best. And the straightforward collision resolution in hashtable.c is much less efficient at mitigating collisions than a Python dict's. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 10:56:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 May 2014 08:56:06 +0000 Subject: [issue21556] try to use hashtable in pickle In-Reply-To: <1400792107.19.0.965541378341.issue21556@psf.upfronthosting.co.za> Message-ID: <1400835366.49.0.792389319875.issue21556@psf.upfronthosting.co.za> STINNER Victor added the comment: "_Py_hashtable_hash_ptr is quite crude in that it doesn't even try to compensate for pointer alignment, so there will automatically be many collisions. Only one hash bucket every 8 or 16 will be used, at best." I chose to use _Py_HashPointer() to drop (shift) lower bits. Do you mean that it's not enough? Python memory allocator uses an alignement on 8 bytes (2**3). Py_uhash_t _Py_hashtable_hash_ptr(const void *key) { return (Py_uhash_t)_Py_HashPointer((void *)key); } Py_hash_t _Py_HashPointer(void *p) { Py_hash_t x; size_t y = (size_t)p; /* bottom 3 or 4 bits are likely to be 0; rotate y by 4 to avoid excessive hash collisions for dicts and sets */ y = (y >> 4) | (y << (8 * SIZEOF_VOID_P - 4)); x = (Py_hash_t)y; if (x == -1) x = -2; return x; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 10:57:26 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 May 2014 08:57:26 +0000 Subject: [issue21556] try to use hashtable in pickle In-Reply-To: <1400835366.49.0.792389319875.issue21556@psf.upfronthosting.co.za> Message-ID: <1400835444.2383.0.camel@fsol> Antoine Pitrou added the comment: > "_Py_hashtable_hash_ptr is quite crude in that it doesn't even try to compensate for pointer alignment, so there will automatically be many collisions. Only one hash bucket every 8 or 16 will be used, at best." > > I chose to use _Py_HashPointer() to drop (shift) lower bits. Do you > mean that it's not enough? Python memory allocator uses an alignement > on 8 bytes (2**3). Ah, sorry, I just hadn't realized that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 11:01:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 May 2014 09:01:10 +0000 Subject: [issue21556] try to use hashtable in pickle In-Reply-To: <1400792107.19.0.965541378341.issue21556@psf.upfronthosting.co.za> Message-ID: <1400835670.7.0.661461882456.issue21556@psf.upfronthosting.co.za> STINNER Victor added the comment: > And the straightforward collision resolution in hashtable.c is much less efficient at mitigating collisions than a Python dict's. Modules/hashtable.c comes from http://sourceforge.net/projects/libcfu/ (cfuhash type). I adapted the code for my needs (the tracemalloc module), but I didn't try to make it fast. My main change was to store data directly in an entry of a table instead of using a second memory block for the data (and a pointer in the hash table entry). I didn't want to use the Python dict type for tracemalloc because this type may use the Python memory allocator which would lead to reentrant calls to tracemalloc. It's also nice to have a function to compute exactly the memory usage of an hash table (table + data), it's exposed in tracemalloc.get_tracemalloc_memory(). It doesn't mean that I want hashtable.c to be slow :-) Feel free to modify it as you want. But trying to make it as fast as Python dict would be hard. The design is different. Python dict uses open addressing, whereas _Py_hashtable uses linked list to store entries. Python dict is well optimized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 11:03:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 May 2014 09:03:31 +0000 Subject: [issue21556] try to use hashtable in pickle In-Reply-To: <1400835670.7.0.661461882456.issue21556@psf.upfronthosting.co.za> Message-ID: <1400835804.2383.2.camel@fsol> Antoine Pitrou added the comment: > I didn't want to use the Python dict type for tracemalloc because this > type may use the Python memory allocator which would lead to reentrant > calls to tracemalloc. Ah, so this means CF's patch will make the pickle memotable invisible to tracemalloc? > It doesn't mean that I want hashtable.c to be slow :-) Feel free to > modify it as you want. But trying to make it as fast as Python dict > would be hard. The design is different. Python dict uses open > addressing, whereas _Py_hashtable uses linked list to store entries. > Python dict is well optimized. Yes, optimizing hashtable.c probably means converting it to the same hashing scheme as dicts (or the current memotable in pickle.c). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 11:26:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 May 2014 09:26:44 +0000 Subject: [issue21556] try to use hashtable in pickle In-Reply-To: <1400792107.19.0.965541378341.issue21556@psf.upfronthosting.co.za> Message-ID: <1400837204.7.0.773938094899.issue21556@psf.upfronthosting.co.za> STINNER Victor added the comment: "Ah, so this means CF's patch will make the pickle memotable invisible to tracemalloc?" Currently, _Py_hashtabe uses PyMem_RawMalloc and PyMem_RawFree by default (realloc is not needed, we need to keep the previous buckets on rehash). Using _Py_hashtable_new_full, you can choose a different memory allocator. Hum, wait. tracemalloc uses trace PyMem_RawMalloc and PyMem_RawFree. In fact, tracemalloc ignores reentrant calls to the memory allocator. So now I don't remember exactly why I chose a custom hash table implementation :-) Maybe because Python dict requires Python objects with reference counter, use the garbage collector, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 11:57:40 2014 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Fri, 23 May 2014 09:57:40 +0000 Subject: [issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value In-Reply-To: <1392053798.24.0.547929158873.issue20584@psf.upfronthosting.co.za> Message-ID: <1400839060.2.0.7667288716.issue20584@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: We should match the unit test with the documentation for signal.NSIG. Either the code or the docs or both need to change. Currently the docs say that signal.NSIG is "One more than the number of the highest signal number." ("https://docs.python.org/3.4/library/signal.html#signal.NSIG). In case of FreeBSD's _SIG_MAXSIG (128) the documentation is still wrong: the highest signal value MAX is 126 (see http://bugs.python.org/issue20584#msg210892). According to the docs, NSIG should then be 127. In signal_nsig_freebsd-2.patch the test `self.assertLess(max(signals), signal.NSIG)` tests for NSIG > MAX instead of for NSIG = MAX+1. So, either - we count signals by ourselves and build our own value of NSIG, in which case we can guarantee that NSIG = MAX+1 or - we rely on the platform header files for extracting NSIG, but must note in the docs that NSIG is not always MAX+1. The current patch + a documentation change would implement the latter case. What is the exact meaning of _SIG_MAXSIG, where is that meaning defined? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 11:58:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 09:58:19 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <3gZjnQ3NGKz7Ljc@mail.python.org> Roundup Robot added the comment: New changeset cd62cc331572 by Antoine Pitrou in branch '3.4': Issue #21523: Fix over-pessimistic computation of the stack effect of some opcodes in the compiler. http://hg.python.org/cpython/rev/cd62cc331572 New changeset e61462e18112 by Antoine Pitrou in branch 'default': Issue #21523: Fix over-pessimistic computation of the stack effect of some opcodes in the compiler. http://hg.python.org/cpython/rev/e61462e18112 New changeset 49588a510ed4 by Antoine Pitrou in branch '2.7': Issue #21523: Fix over-pessimistic computation of the stack effect of some opcodes in the compiler. http://hg.python.org/cpython/rev/49588a510ed4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 12:00:06 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 May 2014 10:00:06 +0000 Subject: [issue21523] quadratic-time compilation in the number of 'and' or 'or' expressions In-Reply-To: <1400416305.88.0.347488833998.issue21523@psf.upfronthosting.co.za> Message-ID: <1400839206.15.0.845079895325.issue21523@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This should be fixed now! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 12:34:39 2014 From: report at bugs.python.org (theme) Date: Fri, 23 May 2014 10:34:39 +0000 Subject: [issue21559] OverflowError should not happen for integer operations Message-ID: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za> New submission from theme: >From the documentation at https://docs.python.org/3.4/library/exceptions.html#OverflowError all integer operations should not throw OverflowError no matter what. However, there are so many issues here that describe library functions and built-in functions doing exactly that (just search this website for OverflowError). This might cause an expected uncaught exception that the cause cannot be deduced after reading the documentation. There are 2 ways to fix this: either change the documentation, or change something in the core of the interpreter. Note: I don't know what versions of python this affects, but I have tested this on python 3.4.0 on windows. (the version that was downloadable from www.python.org/downloads/) ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 218957 nosy: docs at python, theme priority: normal severity: normal status: open title: OverflowError should not happen for integer operations type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 12:35:32 2014 From: report at bugs.python.org (theme) Date: Fri, 23 May 2014 10:35:32 +0000 Subject: [issue21559] OverflowError should not happen for integer operations In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za> Message-ID: <1400841332.44.0.921472076693.issue21559@psf.upfronthosting.co.za> Changes by theme : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 12:55:04 2014 From: report at bugs.python.org (Steffen Daode Nurpmeso) Date: Fri, 23 May 2014 10:55:04 +0000 Subject: [issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value In-Reply-To: <1392053798.24.0.547929158873.issue20584@psf.upfronthosting.co.za> Message-ID: <1400842504.39.0.272716376338.issue20584@psf.upfronthosting.co.za> Steffen Daode Nurpmeso added the comment: Salut!, amis fran?ais! (Und auch sonst so, nat?rlich.) POSIX has recently standardized a NSIG_MAX constant in [1]: The value of {NSIG_MAX} shall be no greater than the number of signals that the sigset_t type (see [cross-ref to ]) is capable of representing, ignoring any restrictions imposed by sigfillset() or sigaddset(). I'm personally following an advise of Rich Felker in the meantime: #ifdef NSIG_MAX # undef NSIG # define NSIG NSIG_MAX #elif !defined NSIG # define NSIG ((sizeof(sigset_t) * 8) - 1) #endif That is for "old" signals only, there; maybe reducing this to #undef NSIG #ifdef NSIG_MAX # define NSIG NSIG_MAX #else # define NSIG ((sizeof(sigset_t) * 8) - 1) #endif should do the trick for Python on any POSIX system? Ciao from, eh, gray, Germany :) [1] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 13:11:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 11:11:32 +0000 Subject: [issue21522] Add more tkinter tests In-Reply-To: <1400415959.04.0.266142881924.issue21522@psf.upfronthosting.co.za> Message-ID: <3gZlPv0WHGz7Ltm@mail.python.org> Roundup Robot added the comment: New changeset a7082e2898aa by Serhiy Storchaka in branch '2.7': Issue #21522: Added Tkinter tests for Listbox.itemconfigure(), http://hg.python.org/cpython/rev/a7082e2898aa New changeset f7c012ff33cb by Serhiy Storchaka in branch '3.4': Issue #21522: Added Tkinter tests for Listbox.itemconfigure(), http://hg.python.org/cpython/rev/f7c012ff33cb New changeset 4034c96a98a7 by Serhiy Storchaka in branch 'default': Issue #21522: Added Tkinter tests for Listbox.itemconfigure(), http://hg.python.org/cpython/rev/4034c96a98a7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 13:11:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 11:11:32 +0000 Subject: [issue20635] Fix the grid geometry manager and add tests for geometry managers In-Reply-To: <1392464302.58.0.168858938069.issue20635@psf.upfronthosting.co.za> Message-ID: <3gZlPv5ykQz7Ltm@mail.python.org> Roundup Robot added the comment: New changeset 9ab1225b6cc5 by Serhiy Storchaka in branch '2.7': Issue #20635: Added tests for Tk geometry managers. http://hg.python.org/cpython/rev/9ab1225b6cc5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 13:18:32 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 23 May 2014 11:18:32 +0000 Subject: [issue21558] Fix a typo in the contextlib docs In-Reply-To: <1400817528.11.0.0994185866372.issue21558@psf.upfronthosting.co.za> Message-ID: <1400843912.49.0.883273354373.issue21558@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 13:22:57 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 23 May 2014 11:22:57 +0000 Subject: [issue21560] gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string Message-ID: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za> New submission from Wolfgang Maier: I ran into this: >>> gzout = gzip.open('test.gz','wb') >>> gzout.write('abcdefgh') # write expects bytes not str Traceback (most recent call last): File "", line 1, in gzout.write('abcdefgh') File "/usr/lib/python3.4/gzip.py", line 343, in write self.crc = zlib.crc32(data, self.crc) & 0xffffffff TypeError: 'str' does not support the buffer interface >>> gzout.write(b'abcdefgh') # ok, use bytes instead 8 >>> gzout.close() But now the file is not recognized as valid gzip format anymore (neither by the gzip module nor by external software): >>> gzin = gzip.open('test.gz','rb') >>> next(gzin) Traceback (most recent call last): File "", line 1, in next(gzin) File "/usr/lib/python3.4/gzip.py", line 594, in readline c = self.read(readsize) File "/usr/lib/python3.4/gzip.py", line 365, in read if not self._read(readsize): File "/usr/lib/python3.4/gzip.py", line 465, in _read self._read_eof() File "/usr/lib/python3.4/gzip.py", line 487, in _read_eof raise OSError("Incorrect length of data produced") OSError: Incorrect length of data produced Turns out that gzip.write increased the ISIZE field value by 8 already during the failed call with the str object, so it is now 16 instead of 8: >>> raw = open('test.gz','rb') >>> [n for n in raw.read()] # ISIZE is the fourth last element [31, 139, 8, 8, 51, 46, 127, 83, 2, 255, 116, 101, 115, 116, 0, 75, 76, 74, 78, 73, 77, 75, 207, 0, 0, 80, 42, 239, 174, 16, 0, 0, 0] in other words: gzip.GzipFile.write() leaps (and modifies) before it checks its input argument. ---------- components: Library (Lib) messages: 218961 nosy: wolma priority: normal severity: normal status: open title: gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 13:30:44 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 23 May 2014 11:30:44 +0000 Subject: [issue7094] Add alternate float formatting styles to new-style formatting. In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za> Message-ID: <1400844644.07.0.274110724179.issue7094@psf.upfronthosting.co.za> Stefan Krah added the comment: This might be out of date: _decimal has never implemented alternate formatting and so far there have been no reported issues. Another data point: Go apparently implements alternate formatting only for octal, hex and strings: http://golang.org/pkg/fmt/ So I'm unsure if anyone is actually using alternate formatting. I think complaints about 2-to-3 porting problems should have surfaced by now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 13:32:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 11:32:33 +0000 Subject: [issue20635] Fix the grid geometry manager and add tests for geometry managers In-Reply-To: <1392464302.58.0.168858938069.issue20635@psf.upfronthosting.co.za> Message-ID: <1400844753.28.0.776019407651.issue20635@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 May 23 13:32:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 11:32:54 +0000 Subject: [issue21522] Add more tkinter tests In-Reply-To: <1400415959.04.0.266142881924.issue21522@psf.upfronthosting.co.za> Message-ID: <1400844774.35.0.0887990380067.issue21522@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 May 23 13:37:33 2014 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 23 May 2014 11:37:33 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1400845053.62.0.183718558975.issue21356@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 13:40:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 11:40:12 +0000 Subject: [issue21560] gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string In-Reply-To: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za> Message-ID: <1400845212.73.0.167621171305.issue21560@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy stage: -> needs patch versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 13:44:41 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 23 May 2014 11:44:41 +0000 Subject: [issue21560] gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string In-Reply-To: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za> Message-ID: <1400845481.11.0.233938820591.issue21560@psf.upfronthosting.co.za> Wolfgang Maier added the comment: ok, this seems to be really easy: patch attached ---------- keywords: +patch Added file: http://bugs.python.org/file35323/GzipFile_write.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 13:55:32 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 23 May 2014 11:55:32 +0000 Subject: [issue21560] gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string In-Reply-To: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za> Message-ID: <1400846132.96.0.239286347547.issue21560@psf.upfronthosting.co.za> Wolfgang Maier added the comment: or not - my patch just causes a different error in my example :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 14:02:17 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Fri, 23 May 2014 12:02:17 +0000 Subject: [issue21560] gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string In-Reply-To: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za> Message-ID: <1400846537.1.0.833697448508.issue21560@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Moving `self.crc = zlib.crc32(data, self.crc) & 0xffffffff` before `self.size = self.size + len(data)` should be enough. Also, your patch needs a test. ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 14:20:26 2014 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 23 May 2014 12:20:26 +0000 Subject: [issue21560] gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string In-Reply-To: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za> Message-ID: <1400847626.21.0.933276268608.issue21560@psf.upfronthosting.co.za> Wolfgang Maier added the comment: isn't this exactly what I did in my patch ? actually, it is working, I just had an error in my preliminary test script. I may be able to work on an official test at some point, but definitely not over the next week ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 14:26:21 2014 From: report at bugs.python.org (Geoffrey Spear) Date: Fri, 23 May 2014 12:26:21 +0000 Subject: [issue21555] gcmodule.c could use pytime.h In-Reply-To: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> Message-ID: <1400847981.86.0.863082776431.issue21555@psf.upfronthosting.co.za> Changes by Geoffrey Spear : ---------- nosy: +geoffreyspear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 14:37:02 2014 From: report at bugs.python.org (David Harrigan) Date: Fri, 23 May 2014 12:37:02 +0000 Subject: [issue21545] Tutorial: examples and comment about mutation methods In-Reply-To: <1400621853.89.0.606116768213.issue21545@psf.upfronthosting.co.za> Message-ID: <1400848622.33.0.766933325236.issue21545@psf.upfronthosting.co.za> David Harrigan added the comment: Thanks for the info, I've signed the agreement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 15:15:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 13:15:58 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <3gZp9T02p1z7LkL@mail.python.org> Roundup Robot added the comment: New changeset f0452bc62cc3 by Serhiy Storchaka in branch '3.4': Issue #21538: The plistlib module now supports loading of binary plist files http://hg.python.org/cpython/rev/f0452bc62cc3 New changeset b2c5d0cba5fd by Serhiy Storchaka in branch 'default': Issue #21538: The plistlib module now supports loading of binary plist files http://hg.python.org/cpython/rev/b2c5d0cba5fd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 15:21:05 2014 From: report at bugs.python.org (Geoffrey Spear) Date: Fri, 23 May 2014 13:21:05 +0000 Subject: [issue21555] gcmodule.c could use pytime.h In-Reply-To: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> Message-ID: <1400851265.13.0.697961486455.issue21555@psf.upfronthosting.co.za> Geoffrey Spear added the comment: Attached patch replaces call to Python time.time() with _PyTime_gettimeofday() call. ---------- keywords: +patch Added file: http://bugs.python.org/file35324/issue21555.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 15:26:04 2014 From: report at bugs.python.org (ingrid) Date: Fri, 23 May 2014 13:26:04 +0000 Subject: [issue16428] turtle with compound shape doesn't get clicks In-Reply-To: <1352299609.35.0.759398778926.issue16428@psf.upfronthosting.co.za> Message-ID: <1400851564.14.0.183025512745.issue16428@psf.upfronthosting.co.za> ingrid added the comment: I tried the same script in Python 2.7 and Python 3.4.1 on OSX and had the same results. ---------- nosy: +ingrid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 15:26:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 13:26:27 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400851587.23.0.54006062069.issue21538@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you John for your report. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 15:47:40 2014 From: report at bugs.python.org (Geoffrey Spear) Date: Fri, 23 May 2014 13:47:40 +0000 Subject: [issue21555] gcmodule.c could use pytime.h In-Reply-To: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> Message-ID: <1400852860.74.0.903986661796.issue21555@psf.upfronthosting.co.za> Geoffrey Spear added the comment: revised patch; thanks to berkerpeksag's code review. ---------- Added file: http://bugs.python.org/file35325/issue21555-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 16:09:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 14:09:46 +0000 Subject: [issue21538] plistlib unable to load iOS7 Safari History.plist In-Reply-To: <1400537332.53.0.0901948459241.issue21538@psf.upfronthosting.co.za> Message-ID: <1400854186.16.0.00683846346271.issue21538@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 Fri May 23 16:29:25 2014 From: report at bugs.python.org (Sergey Vilgelm) Date: Fri, 23 May 2014 14:29:25 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1400855365.27.0.00328779738065.issue9253@psf.upfronthosting.co.za> Changes by Sergey Vilgelm : ---------- nosy: +svilgelm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 16:37:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 14:37:16 +0000 Subject: [issue15809] 2.7 IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1400855836.42.0.491965991926.issue15809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: When someone reads file in locale encoding (either as str or unicode in 2.7), he gets printable result. When someone lists directory, he gets printable result (str or unicode). When someone enter string literal (either str or unicode) in interactive mode, he gets printable result. This is expected behavior. And this means that default encoding for text files, filesystem encoding and encoding used in interactive Python (or IDLE console) should be the same, locale encoding. > Irdb said "As a Windows user, currently I can't print u'????' in interactive mode and get an "Unsupported characters in input" error because my default system encoding (cp1256) can't encode Russian.)" This is different issue. It would be better if IDLE will filter pasted text and replace unencodable characters or underscore them with wavy red line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 17:02:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 15:02:07 +0000 Subject: [issue21513] speed up some ipaddress properties In-Reply-To: <1400189077.88.0.327979647169.issue21513@psf.upfronthosting.co.za> Message-ID: <1400857327.49.0.986129716456.issue21513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be move implementations to parent class? In any case the patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 17:08:10 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 23 May 2014 15:08:10 +0000 Subject: [issue20853] pdb "args" crashes when an arg is not printable In-Reply-To: <1394016357.17.0.646134871451.issue20853@psf.upfronthosting.co.za> Message-ID: <1400857690.63.0.754779764823.issue20853@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Commands that silently fail when an object is not printable: p, pp Commands that crash when an object is not printable: args, retval Python 3: display Python 2: on a 'return' trace event when the return value is not printable The attached script illustrates all these cases. ---------- Added file: http://bugs.python.org/file35326/safe_repr.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 17:43:56 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 23 May 2014 15:43:56 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1400859836.0.0.398881891461.issue14019@psf.upfronthosting.co.za> Brett Cannon added the comment: Set to "pending" while I wait to hear back from Francisco on the review comments. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 17:47:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 15:47:08 +0000 Subject: [issue21474] Idle: updata fixwordbreaks() for unicode identifiers In-Reply-To: <1399858064.02.0.148903090644.issue21474@psf.upfronthosting.co.za> Message-ID: <1400860028.67.0.621145399539.issue21474@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 18:27:49 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 23 May 2014 16:27:49 +0000 Subject: [issue14710] pkgutil.get_loader and find_loader fail when module is missing In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1400862469.68.0.165010682288.issue14710@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- title: pkgutil.get_loader is broken -> pkgutil.get_loader and find_loader fail when module is missing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 18:27:59 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 23 May 2014 16:27:59 +0000 Subject: [issue14710] pkgutil.get_loader and find_loader fail when module is missing In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1400862479.81.0.648922338672.issue14710@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 18:32:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 16:32:42 +0000 Subject: [issue14710] pkgutil.get_loader and find_loader fail when module is missing In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <3gZtXT1hynz7Ljv@mail.python.org> Roundup Robot added the comment: New changeset 660c82192c69 by Brett Cannon in branch '3.4': Issue #14710: Fix both pkgutil.find_loader() and get_loader() to not http://hg.python.org/cpython/rev/660c82192c69 New changeset 1adc8eb362f0 by Brett Cannon in branch 'default': Merge for issue #14710 http://hg.python.org/cpython/rev/1adc8eb362f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 18:33:33 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 23 May 2014 16:33:33 +0000 Subject: [issue14710] pkgutil.get_loader and find_loader fail when module is missing In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1400862813.28.0.0826417332335.issue14710@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the bug report, Pavel. It turned out pkgutil.find_loader is broken as well as pkgutil.get_loader in different ways. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 19:27:11 2014 From: report at bugs.python.org (Andy Maier) Date: Fri, 23 May 2014 17:27:11 +0000 Subject: [issue21561] help() on enum34 enumeration class creates only a dummy documentation Message-ID: <1400866031.36.0.493061688069.issue21561@psf.upfronthosting.co.za> New submission from Andy Maier: Using the enum34 backport of enums, the help() function on an enum class Colors displays only: ------- Help on class Colors in module __main__: Colors = ------- Source code to reproduce: ------- from enum import Enum # enum34 package class Colors(Enum): """docstring for enumeration Colors""" RED = 1 GREEN = "2" BLUE = [3] help(Colors) ------- Versions used: python 2.7.6 enum34 1.0 Platform: Windows 7 I debugged the issue, found the place where it breaks down, and made a fix. However, it may well be that the fix is just a cure to a symptom, and that a better fix is possible. Here is the fix: In pydoc.py, class TextDoc, method docclass(): Change this code on line 1220+: ------- if thisclass is __builtin__.object: attrs = inherited continue elif thisclass is object: tag = "defined here" else: tag = "inherited from %s" % classname(thisclass, object.__module__) ------- to this, by adding the two lines marked with "added": ------- if thisclass is __builtin__.object: attrs = inherited continue elif thisclass is object: tag = "defined here" elif thisclass is None: # <-- added tag = "inherited from TBD" # <-- added else: tag = "inherited from %s" % classname(thisclass, object.__module__) ------- It breaks down during the last round through the 'while attrs' loop, where thisclass is None. I did not investigate why thisclass is None. Without the fix, this causes an AttributeError to be raised by the classname() function, which then further on causes the dummy documentation to be generated. With the fix, the help(Colors) output becomes: ------- Help on class Colors in module __main__: class Colors(enum.Enum) | docstring for enumeration Colors | | Method resolution order: | Colors | enum.Enum | __builtin__.object | | Data and other attributes defined here: | | BLUE = | | GREEN = | | RED = | | ---------------------------------------------------------------------- | Data and other attributes inherited from TBD: | | __members__ = {'BLUE': , 'GREEN': _______________________________________ From report at bugs.python.org Fri May 23 19:35:51 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 May 2014 17:35:51 +0000 Subject: [issue21474] Idle: updata fixwordbreaks() for unicode identifiers In-Reply-To: <1399858064.02.0.148903090644.issue21474@psf.upfronthosting.co.za> Message-ID: <1400866551.74.0.743475765524.issue21474@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Deleting the function and calls to it would be easy. But my memory, which could be off, is that I left fixwordbreaks(root) in the test function now called _editor_window (at the end of the file) because the test did not work right without it. I willhave to recheck. Beyond that, my first experiments were aimed at discovering the functions affected and therefor what would have to be tested with any changes. To properly test this requires simulating keystrokes, like control-backspace, as opposed to inserting characters. Are there any tk/tkinter tests that do this, that I could use as a model? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 19:43:29 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 May 2014 17:43:29 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400867009.71.0.0265218846685.issue21477@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +jesstess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 20:00:51 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 23 May 2014 18:00:51 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1400868051.1.0.0126881123906.issue20383@psf.upfronthosting.co.za> Eric Snow added the comment: @Brett: Did those last two messages (and the patch) get on the wrong issue. The issue of module_from_spec() or the like seems somewhat orthogonal to a spec argument to ModuleType. Perhaps you meant issue #21436 or #21235? Otherwise, I have a few comments. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 20:20:43 2014 From: report at bugs.python.org (Ethan Furman) Date: Fri, 23 May 2014 18:20:43 +0000 Subject: [issue21561] help() on enum34 enumeration class creates only a dummy documentation In-Reply-To: <1400866031.36.0.493061688069.issue21561@psf.upfronthosting.co.za> Message-ID: <1400869243.72.0.0510372591673.issue21561@psf.upfronthosting.co.za> Ethan Furman added the comment: Good work. This bug was fixed in 3.4 with the inclusion of enum. It would definitely be good to fix in 2.7 as well. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 20:22:38 2014 From: report at bugs.python.org (Lita Cho) Date: Fri, 23 May 2014 18:22:38 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1400869358.32.0.389738732141.issue17172@psf.upfronthosting.co.za> Lita Cho added the comment: I tested the patch and it looks correct upon inspection. It looks like it applies cleanly and a straight forward solution. I made a slight change so that when the Demo exits, it has a better message. I also added the change to the NEWS.txt file. I also ran the IDLE tests, and everything passed. I didn't see new tests added, but I am not sure if that is needed, since we are just adding a menu binding. I've attached my patch with the changes listed above. It should be ready for review. ---------- nosy: +Lita.Cho, jesstess Added file: http://bugs.python.org/file35328/issue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 20:32:36 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 23 May 2014 18:32:36 +0000 Subject: [issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value In-Reply-To: <1400839060.2.0.7667288716.issue20584@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Jan-Philip Gehrcke added the comment: > > Currently the docs say that signal.NSIG is "One more than the number of the highest signal number." ("https://docs.python.org/3.4/library/signal.html#signal.NSIG). > > In case of FreeBSD's _SIG_MAXSIG (128) the documentation is still wrong: the highest signal value MAX is 126 (see http://bugs.python.org/issue20584#msg210892). According to the docs, NSIG should then be 127. Yeah, but it doesn't matter. We shouldn't be exposing this constant in the first place, all that matters is that we accept all valid signals, and we don't crash whe passing an invalid once (ssee below). > Steffen Daode Nurpmeso added the comment: > > #ifdef NSIG_MAX > # undef NSIG > # define NSIG NSIG_MAX > #elif !defined NSIG > # define NSIG ((sizeof(sigset_t) * 8) - 1) > #endif > > should do the trick for Python on any POSIX system? This assumes that sigset_t is implemented as a raw bitmap, which isn't documented (is could be implemented by an arbitrary data structure). On the other hand, it's really really likely, and should guarantee that sigset & Co don't crash on too large values (or write to arbitrary memory locations like fd_set when passed fd > FD_SETSIZE). So I think we should go for the above patch (Steffen's), with a doc update saying that "NSIG is a value larger than the largest signals". If the OS headers don't provide it, it's not our business to try to infer it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 20:36:38 2014 From: report at bugs.python.org (Lita Cho) Date: Fri, 23 May 2014 18:36:38 +0000 Subject: [issue3015] tkinter with wantobjects=False has been broken for some time In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za> Message-ID: <1400870198.51.0.814378492289.issue3015@psf.upfronthosting.co.za> Changes by Lita Cho : ---------- nosy: +Lita.Cho, jesstess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 20:42:13 2014 From: report at bugs.python.org (Charles Merriam) Date: Fri, 23 May 2014 18:42:13 +0000 Subject: [issue8243] curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR' In-Reply-To: <1352121880.55.0.191535515397.issue8243@psf.upfronthosting.co.za> Message-ID: <1400870533.11.0.192804472451.issue8243@psf.upfronthosting.co.za> Charles Merriam added the comment: Some more information to just nail this thing that's been here forever. 1. This has been an issue in Python since at least 2001. 2. It is a duplicate of the item 441129 which was closed as won't fix. 3. It is bug in curses implementations. 4. This occurs whenever the lower-right character of a screen or window is written. The writing, via addch() or addstr(), causes the cursor to advance outside the window and triggers the error. It triggers the same error as attempting to write beyond the edge of the screen, window, or pad. 5. This occurs with the main windows, sub windows, and pads. 6. There are two work-arounds for users: a. Don't do that. Make your window bigger. b. Catch and ignore the error. The library does the right thing but is trying to be too smart about raising errors. 7. There are two good resolutions to the problem: a. Document it. Add a note to addch() and addstr() to the effect: "Writing outside the pad, window, or subwindow will cause a curses.error Exception. Also, attempting to write the lower right corner of a pad, window, or sub window will cause an exception to be raised after the character is printed. You may safely ignore the error in this case." b. Document it as above and add an example. c. Wrap it so it works on Python if no other curses implementation. Many long discussions can be arguments before agreeing why this a bad idea. This is an annoying, obscure bug that deserves a couple lines in the documentation. If you need sample code, I can provide. ---------- nosy: +Charles.Merriam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 20:46:56 2014 From: report at bugs.python.org (Charles Merriam) Date: Fri, 23 May 2014 18:46:56 +0000 Subject: [issue21562] curses getsxy() should be curses getxy() in https://docs.python.org/3/library/curses.html#curses.cursxy Message-ID: <1400870816.3.0.300590440768.issue21562@psf.upfronthosting.co.za> New submission from Charles Merriam: https://docs.python.org/3/library/curses.html#curses.cursxy The symbol 'getsxy' does not exist in the curses library. The correct symbol is 'getxy'. ---------- assignee: docs at python components: Documentation messages: 218986 nosy: Charles.Merriam, docs at python priority: normal severity: normal status: open title: curses getsxy() should be curses getxy() in https://docs.python.org/3/library/curses.html#curses.cursxy type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 20:58:04 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 May 2014 18:58:04 +0000 Subject: [issue15809] 2.7 IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1400871484.2.0.377907597884.issue15809@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I wonder if we should consider extracting the body of if isinstance(source, types.UnicodeType): as a function, call it ufix_latin1; add one or more alterntives, ufix_utf8, ufix_locale, ufix_irdb(?); keep ufix_latin1 as default; but switch to an alternative according to an Idle command line switch (or environmental variable?)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:00:36 2014 From: report at bugs.python.org (Robert Snoeberger) Date: Fri, 23 May 2014 19:00:36 +0000 Subject: [issue21563] Segv during call to builtin_execfile in application embedding Python interpreter. Message-ID: <1400871636.0.0.265957974694.issue21563@psf.upfronthosting.co.za> New submission from Robert Snoeberger: While embedding the Python 2.7 interpreter in an application, I have encountered a crash when the built-in function 'execfile' is invoked with one argument. A file is attached, execfile_invoke.c, that reproduces the crash. The reproduction steps on my machine are the following: % gcc -o execfile_invoke execfile_invoke.c -I/usr/include/python2.7 -L/usr/lib -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic % ./execfile_invoke Call execfile with one argument... Segmentation fault % I am using the following version of Python. Python 2.7.3 (default, Mar 13 2014, 11:03:55) [GCC 4.7.2] on linux2 The crash appears to occur because a call to PyEval_GetGlobals returns a NULL PyObject*, globals = PyEval_GetGlobals(); and PyDict_GetItemString is called before a NULL check is performed. In the Python 3 function builtin_exec, globals and locals are checked for NULL. If either is NULL, an exception with message "globals and locals cannot be NULL" is set. if (!globals || !locals) { PyErr_SetString(PyExc_SystemError, "globals and locals cannot be NULL"); return NULL; } ---------- files: execfile_invoke.c messages: 218988 nosy: snoeberger priority: normal severity: normal status: open title: Segv during call to builtin_execfile in application embedding Python interpreter. type: crash versions: Python 2.7 Added file: http://bugs.python.org/file35329/execfile_invoke.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:10:55 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 23 May 2014 19:10:55 +0000 Subject: [issue21522] Add more tkinter tests In-Reply-To: <1400415959.04.0.266142881924.issue21522@psf.upfronthosting.co.za> Message-ID: <1400872255.57.0.220382981119.issue21522@psf.upfronthosting.co.za> Ned Deily added the comment: Failing tests with Tk 8.4 (Carbon Tk 8.4.20 on OS X): ====================================================================== ERROR: test_paneconfigure_hide (tkinter.test.test_tkinter.test_widgets.PanedWindowTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/test/test_tkinter/test_widgets.py", line 995, in test_paneconfigure_hide self.check_paneconfigure(p, b, 'hide', False, 0) File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/test/test_tkinter/test_widgets.py", line 967, in check_paneconfigure p.paneconfigure(b, **{name: value}) File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/__init__.py", line 3818, in paneconfigure self._options(cnf, kw)) _tkinter.TclError: unknown option "-hide" ====================================================================== ERROR: test_paneconfigure_stretch (tkinter.test.test_tkinter.test_widgets.PanedWindowTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/test/test_tkinter/test_widgets.py", line 1027, in test_paneconfigure_stretch self.check_paneconfigure(p, b, 'stretch', 'alw', 'always') File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/test/test_tkinter/test_widgets.py", line 967, in check_paneconfigure p.paneconfigure(b, **{name: value}) File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/__init__.py", line 3818, in paneconfigure self._options(cnf, kw)) _tkinter.TclError: unknown option "-stretch" ====================================================================== FAIL: test_paneconfigure_height (tkinter.test.test_tkinter.test_widgets.PanedWindowTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/test/test_tkinter/test_widgets.py", line 989, in test_paneconfigure_height self.check_paneconfigure(p, b, 'height', 10, 10) File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/test/test_tkinter/test_widgets.py", line 968, in check_paneconfigure self.assertEqual(p.paneconfigure(b, name)[4], expected) AssertionError: != 10 ====================================================================== FAIL: test_paneconfigure_width (tkinter.test.test_tkinter.test_widgets.PanedWindowTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/test/test_tkinter/test_widgets.py", line 1034, in test_paneconfigure_width self.check_paneconfigure(p, b, 'width', 10, 10) File "/py/dev/3x/root/fwd/Library/Frameworks/pytest_10.9.framework/Versions/3.5/lib/python3.5/tkinter/test/test_tkinter/test_widgets.py", line 968, in check_paneconfigure self.assertEqual(p.paneconfigure(b, name)[4], expected) AssertionError: != 10 ---------- nosy: +ned.deily resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:16:46 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 23 May 2014 19:16:46 +0000 Subject: [issue16428] turtle with compound shape doesn't get clicks In-Reply-To: <1352299609.35.0.759398778926.issue16428@psf.upfronthosting.co.za> Message-ID: <1400872606.11.0.839962366785.issue16428@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +gregorlingl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:19:18 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 23 May 2014 19:19:18 +0000 Subject: [issue21561] help() on enum34 enumeration class creates only a dummy documentation In-Reply-To: <1400866031.36.0.493061688069.issue21561@psf.upfronthosting.co.za> Message-ID: <1400872758.49.0.274238528095.issue21561@psf.upfronthosting.co.za> Ned Deily added the comment: If the problem reported here applies only to the 2.7 backport of enum, which is not part of the Python standard library, shouldn't this issue be closed? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:32:13 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 23 May 2014 19:32:13 +0000 Subject: [issue8243] curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR' In-Reply-To: <1352121880.55.0.191535515397.issue8243@psf.upfronthosting.co.za> Message-ID: <1400873533.07.0.170767527845.issue8243@psf.upfronthosting.co.za> Ned Deily added the comment: FTR, the previous issue is Issue441429. A documentation patch would be welcomed. ---------- assignee: -> docs at python components: +Documentation keywords: +easy nosy: +docs at python, ned.deily stage: -> needs patch versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:33:21 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 23 May 2014 19:33:21 +0000 Subject: [issue21562] curses getsxy() should be curses getxy() in https://docs.python.org/3/library/curses.html#curses.cursxy In-Reply-To: <1400870816.3.0.300590440768.issue21562@psf.upfronthosting.co.za> Message-ID: <1400873601.25.0.43354073545.issue21562@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +easy versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:33:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 19:33:22 +0000 Subject: [issue21474] Idle: updata fixwordbreaks() for unicode identifiers In-Reply-To: <1399858064.02.0.148903090644.issue21474@psf.upfronthosting.co.za> Message-ID: <1400873602.56.0.0397660388256.issue21474@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: word.tcl in Tcl library contains following lines: if {$::tcl_platform(platform) eq "windows"} { # Windows style - any but a unicode space char set ::tcl_wordchars {\S} set ::tcl_nonwordchars {\s} } else { # Motif style - any unicode word char (number, letter, or underscore) set ::tcl_wordchars {\w} set ::tcl_nonwordchars {\W} } So by default all works as expected in Motif style, but not in Windows style. If you want to have same behavior in both styles, defines word chars as: tk.call('set', 'tcl_wordchars', r'\w') tk.call('set', 'tcl_nonwordchars', r'\W') GUI tests are not needed, it is enough to test relevant Tcl commands: tcl_wordBreakAfter, tcl_wordBreakBefore, tcl_endOfWord, tcl_startOfNextWord, and tcl_startOfPreviousWord or TextSelectTo. It's interesting, there are no tests for these functions in Tcl test suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:35:40 2014 From: report at bugs.python.org (Ethan Furman) Date: Fri, 23 May 2014 19:35:40 +0000 Subject: [issue21561] help() on enum34 enumeration class creates only a dummy documentation In-Reply-To: <1400866031.36.0.493061688069.issue21561@psf.upfronthosting.co.za> Message-ID: <1400873740.88.0.622090303074.issue21561@psf.upfronthosting.co.za> Ethan Furman added the comment: The problem will affect anything that uses the same mechanism as enum. It also affects (not verified) all versions of python up to 3.4 where it was fixed because enum exposed it. Besides which, I did not think a bug had to affect stdlib code in order to be fixed -- or this just a 2.7 restriction since it's basically end-of-lifed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:38:24 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 23 May 2014 19:38:24 +0000 Subject: [issue21561] help() on enum34 enumeration class creates only a dummy documentation In-Reply-To: <1400866031.36.0.493061688069.issue21561@psf.upfronthosting.co.za> Message-ID: <1400873904.45.0.29429268989.issue21561@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, I skimmed over the issue and didn't notice that the fix applied to pydoc.py, not enum. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 21:53:59 2014 From: report at bugs.python.org (Lita Cho) Date: Fri, 23 May 2014 19:53:59 +0000 Subject: [issue6639] turtle: _tkinter.TclError: invalid command name ".10170160" In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za> Message-ID: <1400874839.23.0.302557376877.issue6639@psf.upfronthosting.co.za> Changes by Lita Cho : ---------- nosy: +Lita.Cho, jesstess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 22:32:22 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 May 2014 20:32:22 +0000 Subject: [issue21533] built-in types dict docs - construct dict from iterable, not iterator In-Reply-To: <1400487015.16.0.760931173475.issue21533@psf.upfronthosting.co.za> Message-ID: <1400877142.12.0.167943052637.issue21533@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy nosy: +terry.reedy stage: -> commit review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 22:35:06 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 23 May 2014 20:35:06 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1400877306.57.0.200996687332.issue21235@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 22:39:13 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 May 2014 20:39:13 +0000 Subject: [issue21546] int('\0') gives wrong error message In-Reply-To: <1400629106.74.0.994862767087.issue21546@psf.upfronthosting.co.za> Message-ID: <1400877553.22.0.352146808013.issue21546@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> `int()`, `float()`, etc think python strings are null-terminated type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 22:45:51 2014 From: report at bugs.python.org (Ryan Calhoun) Date: Fri, 23 May 2014 20:45:51 +0000 Subject: [issue21564] Declaration of EVP_MD_CTX causes crash when switching between OpenSSL 0.9 and 1.0 Message-ID: <1400877951.59.0.344409625471.issue21564@psf.upfronthosting.co.za> New submission from Ryan Calhoun: OpenSSL, specifically libcrypto, includes functions EVP_MD_CTX_create() and EVP_MD_CTX_destroy(), such that the application code only needs to forward declare the EVP_MD_CTX* pointer type. Declaring the EVP_MD_CTX variable type directly requires compile-time knowledge of the size of the structure. This knowledge will be wrong when compiling with headers from OpenSSL 0.9.8 and dynamically linking at run time against OpenSSL 1.0.1. Result is a SIGSEGV as follows: (gdb) bt #0 0x00007ffff03b71a0 in EVP_PKEY_CTX_dup () from /usr/lib64/libcrypto.so #1 0x00007ffff03a90cd in EVP_MD_CTX_copy_ex () from /usr/lib64/libcrypto.so #2 0x00007ffff110da8a in EVPnew (name_obj=0x7ffff7ef45a8, digest=0x0, initial_ctx=0x7ffff130fbc0, cp=0x0, len=0) at /home/ryan/vaas/python/2.7.6/build/src/Python-2.7.6/Modules/_hashopenssl.c:436 #3 0x00007ffff110de10 in EVP_new_md5 (self=, args=) at /home/ryan/vaas/python/2.7.6/build/src/Python-2.7.6/Modules/_hashopenssl.c:540 The attached patch updates all declarations in _hashopenssl.c to be pointers initialized by calling EVP_MD_CTX_create(). The patch is done against source version 3.4.1. I have a similar patch for version 2.7.6, but can only attach one file here? ---------- components: Extension Modules files: EVP_MD_CTX-python3.4.patch keywords: patch messages: 218995 nosy: Ryan.Calhoun priority: normal severity: normal status: open title: Declaration of EVP_MD_CTX causes crash when switching between OpenSSL 0.9 and 1.0 type: crash versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file35330/EVP_MD_CTX-python3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:00:07 2014 From: report at bugs.python.org (Charles Merriam) Date: Fri, 23 May 2014 21:00:07 +0000 Subject: [issue8243] curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR' In-Reply-To: <1400873533.07.0.170767527845.issue8243@psf.upfronthosting.co.za> Message-ID: Charles Merriam added the comment: My typo. Documentation verbiage was included in the bug report. Submitting a patch to the documentation is a harder than just rewriting the library. I speak English, MarkDown, HTML, JavaScript, and even RST. I don't speak Sphinx, DocBook, or TeX. On Fri, May 23, 2014 at 12:32 PM, Ned Deily wrote: > > Ned Deily added the comment: > > FTR, the previous issue is Issue441429. A documentation patch would be welcomed. > > ---------- > assignee: -> docs at python > components: +Documentation > keywords: +easy > nosy: +docs at python, ned.deily > stage: -> needs patch > versions: +Python 3.5 -Python 3.2, Python 3.3 > > _______________________________________ > Python tracker > > _______________________________________ ---------- nosy: +CharlesMerriam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:00:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 21:00:17 +0000 Subject: [issue21522] Add more tkinter tests In-Reply-To: <1400415959.04.0.266142881924.issue21522@psf.upfronthosting.co.za> Message-ID: <3gb0TD4y0mzStd@mail.python.org> Roundup Robot added the comment: New changeset c7ee46ed2d70 by Serhiy Storchaka in branch '2.7': Fixed new Tkinter tests added in issue #21522 with Tk 8.4. http://hg.python.org/cpython/rev/c7ee46ed2d70 New changeset 854404294f34 by Serhiy Storchaka in branch '3.4': Fixed new Tkinter tests added in issue #21522 with Tk 8.4. http://hg.python.org/cpython/rev/854404294f34 New changeset 1079772e7309 by Serhiy Storchaka in branch 'default': Fixed new Tkinter tests added in issue #21522 with Tk 8.4. http://hg.python.org/cpython/rev/1079772e7309 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:07:00 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 May 2014 21:07:00 +0000 Subject: [issue21548] pydoc -k IndexError on empty docstring In-Reply-To: <1400661783.43.0.558471008968.issue21548@psf.upfronthosting.co.za> Message-ID: <1400879220.56.0.482917324139.issue21548@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Replacing 2061 with the following should work for all versions. desc = module.__doc__.splitlines()[0] if module.__doc__ else '' ---------- nosy: +terry.reedy type: -> behavior versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:07:29 2014 From: report at bugs.python.org (Lita Cho) Date: Fri, 23 May 2014 21:07:29 +0000 Subject: [issue6639] turtle: _tkinter.TclError: invalid command name ".10170160" In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za> Message-ID: <1400879249.5.0.0632980646814.issue6639@psf.upfronthosting.co.za> Changes by Lita Cho : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:09:11 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 May 2014 21:09:11 +0000 Subject: [issue21558] Fix a typo in the contextlib docs In-Reply-To: <1400817528.11.0.0994185866372.issue21558@psf.upfronthosting.co.za> Message-ID: <1400879351.97.0.920043877382.issue21558@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:10:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 May 2014 21:10:14 +0000 Subject: [issue21513] speed up some ipaddress properties In-Reply-To: <1400189077.88.0.327979647169.issue21513@psf.upfronthosting.co.za> Message-ID: <1400879414.61.0.425695980497.issue21513@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > May be move implementations to parent class? Docstrings are different, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:12:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 May 2014 21:12:30 +0000 Subject: [issue21513] speed up some ipaddress properties In-Reply-To: <1400189077.88.0.327979647169.issue21513@psf.upfronthosting.co.za> Message-ID: <3gb0lK4CzHz7Lt8@mail.python.org> Roundup Robot added the comment: New changeset 7a28ab8f012f by Antoine Pitrou in branch 'default': Issue #21513: Speedup some properties of IP addresses (IPv4Address, IPv6Address) such as .is_private or .is_multicast. http://hg.python.org/cpython/rev/7a28ab8f012f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:12:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 May 2014 21:12:32 +0000 Subject: [issue21522] Add more tkinter tests In-Reply-To: <1400872255.57.0.220382981119.issue21522@psf.upfronthosting.co.za> Message-ID: <11032819.zLGeYhV4hP@raxxla> Serhiy Storchaka added the comment: Thank you Ned. My fault. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:12:52 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 May 2014 21:12:52 +0000 Subject: [issue21513] speed up some ipaddress properties In-Reply-To: <1400189077.88.0.327979647169.issue21513@psf.upfronthosting.co.za> Message-ID: <1400879572.75.0.529872974407.issue21513@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed, thanks. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:13:27 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 23 May 2014 21:13:27 +0000 Subject: [issue21565] multiprocessing: use contex-manager protocol for synchronization primitives Message-ID: <1400879607.2.0.100700742941.issue21565@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: This patch updates multiprocessing to use context-manager for locks, conditions, etc. ---------- components: Library (Lib) files: multiprocessing_context_manager.diff keywords: needs review, patch messages: 219003 nosy: neologix, sbt priority: normal severity: normal stage: patch review status: open title: multiprocessing: use contex-manager protocol for synchronization primitives type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35331/multiprocessing_context_manager.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:14:02 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 May 2014 21:14:02 +0000 Subject: [issue21564] Declaration of EVP_MD_CTX causes crash when switching between OpenSSL 0.9 and 1.0 In-Reply-To: <1400877951.59.0.344409625471.issue21564@psf.upfronthosting.co.za> Message-ID: <1400879642.91.0.50936331113.issue21564@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +christian.heimes, gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:18:44 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 May 2014 21:18:44 +0000 Subject: [issue21559] OverflowError should not happen for integer operations In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za> Message-ID: <1400879924.0.0.391392290675.issue21559@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In 2.7, it was only *long integers* that could not overflow. In both python 2 and 3, the comment only applys to operations on integers and not to integers converted to floats. Perhaps that could be clarified. If have any example from running Python where (long) integer operations raising OverflowError and there is no issue about the bug, please open one. If there are any issues that describe such exceptions as not bugs, please list them also. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:26:51 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 23 May 2014 21:26:51 +0000 Subject: [issue21566] make use of the new default socket.listen() backlog argument Message-ID: <1400880411.34.0.235990435925.issue21566@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: Follow-up to issue #21455: we can now update the stdlib to rely on the default socket listen backlog, instead of having a bazillion different values (which range from 1 to 100!). ---------- components: Library (Lib) files: use_socket_listen_backlog.diff keywords: needs review, patch messages: 219005 nosy: haypo, neologix, pitrou, sbt priority: normal severity: normal stage: patch review status: open title: make use of the new default socket.listen() backlog argument type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35332/use_socket_listen_backlog.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:32:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 May 2014 21:32:19 +0000 Subject: [issue21566] make use of the new default socket.listen() backlog argument In-Reply-To: <1400880411.34.0.235990435925.issue21566@psf.upfronthosting.co.za> Message-ID: <1400880739.89.0.485063381603.issue21566@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:32:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 May 2014 21:32:52 +0000 Subject: [issue21566] make use of the new default socket.listen() backlog argument In-Reply-To: <1400880411.34.0.235990435925.issue21566@psf.upfronthosting.co.za> Message-ID: <1400880772.03.0.58144777573.issue21566@psf.upfronthosting.co.za> STINNER Victor added the comment: Maybe we should keep listen(1) in some cases. For socketpair() of asyncio.windows_utils, it makes sense to use sock.listen(1) since we expect exactly one request from one client. The listening socket is closed just after sock.accept(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 23 23:44:56 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 23 May 2014 21:44:56 +0000 Subject: [issue21566] make use of the new default socket.listen() backlog argument In-Reply-To: <1400880772.03.0.58144777573.issue21566@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Maybe we should keep listen(1) in some cases. > > For socketpair() of asyncio.windows_utils, it makes sense to use sock.listen(1) since we expect exactly one request from one client. The listening socket is closed just after sock.accept(). Yeah, I thought about that, but almost all operating systems don't strictly respect the backlog, they always increase it a bit, so this wouldn't change much. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 00:59:43 2014 From: report at bugs.python.org (=?utf-8?q?Viktor_Sz=C3=A9pe?=) Date: Fri, 23 May 2014 22:59:43 +0000 Subject: [issue21567] cannot create multipart alternative message with us-ascii charset Message-ID: <1400885983.53.0.980235742965.issue21567@psf.upfronthosting.co.za> New submission from Viktor Sz?pe: Python 2.7.6 (default, May 22 2014, 00:19:36) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from email.mime.multipart import MIMEMultipart >>> new_msg = MIMEMultipart('alternative') >>> new_msg.set_charset('us-ascii') Traceback (most recent call last): File "", line 1, in File "/opt/python/lib/python2.7/email/message.py", line 268, in set_charset cte(self) File "/opt/python/lib/python2.7/email/encoders.py", line 73, in encode_7or8bit orig.encode('ascii') AttributeError: 'list' object has no attribute 'encode' >>> I know it is not necessary. How come that new_msg.set_charset('us-ascii') works? ---------- components: email messages: 219009 nosy: Viktor.Sz?pe, barry, r.david.murray priority: normal severity: normal status: open title: cannot create multipart alternative message with us-ascii charset type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 01:01:47 2014 From: report at bugs.python.org (=?utf-8?q?Viktor_Sz=C3=A9pe?=) Date: Fri, 23 May 2014 23:01:47 +0000 Subject: [issue21567] cannot create multipart alternative message with us-ascii charset In-Reply-To: <1400885983.53.0.980235742965.issue21567@psf.upfronthosting.co.za> Message-ID: <1400886107.5.0.659943778367.issue21567@psf.upfronthosting.co.za> Viktor Sz?pe added the comment: Sorry! How come that new_msg.set_charset('utf-8') works? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 01:11:30 2014 From: report at bugs.python.org (Francisco Freire) Date: Fri, 23 May 2014 23:11:30 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1400886690.08.0.29657926004.issue14019@psf.upfronthosting.co.za> Francisco Freire added the comment: Hi, I signed the contributor agreement. Thank you for your review comments. I did these tests about one year ago and right now I don't have much time to look at it again. I hope to do so in the next months. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 01:23:10 2014 From: report at bugs.python.org (Lita Cho) Date: Fri, 23 May 2014 23:23:10 +0000 Subject: [issue3015] tkinter with wantobjects=False has been broken for some time In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za> Message-ID: <1400887390.29.0.0963856510859.issue3015@psf.upfronthosting.co.za> Lita Cho added the comment: I am in the process of reviewing this patch, but I don't know what "wantobjects" does. I can make a guess, I think it is a hack to make tcl objects work in Python. I am guessing this is less needed in Python 3.4, but still has some dependencies. If we can add in the documentation of what "wantobjects" is and why it is being depreciated somewhere, that would be great. I would do it myself, but I do need some direction. I ran the tests, and it seems to run fine. The patch didn't have any new tests. We should add one that checks if the depreciation is working. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 01:32:07 2014 From: report at bugs.python.org (Lita Cho) Date: Fri, 23 May 2014 23:32: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: <1400887927.25.0.477741309865.issue6639@psf.upfronthosting.co.za> Lita Cho added the comment: I was looking at this more, and from my understanding, the turtle code is continuing to run even when the TK window is destroyed. Thus the crash. It looks like the drawing functions are being made on the fly with the following method: for methodname in _tg_turtle_functions: pl1, pl2 = getmethparlist(eval('Turtle.' + methodname)) if pl1 == "": print(">>>>>>", pl1, pl2) continue defstr = ("def %(key)s%(pl1)s: return _getpen().%(key)s%(pl2)s" % {'key':methodname, 'pl1':pl1, 'pl2':pl2}) exec(defstr) eval(methodname).__doc__ = _turtle_docrevise(eval('Turtle.'+methodname).__doc__) So while all the methods are being generated, I am going to add in a check to see if the window was destroyed before running the pen code. If it was, then I exit gratefully. The check will be duplicated for each pen method, but I feel it is the best way to contain the check within the turtle.py module. The other option would be to make the user check for it, which is not a good option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 02:39:42 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 May 2014 00:39:42 +0000 Subject: [issue21558] Fix a typo in the contextlib docs In-Reply-To: <1400817528.11.0.0994185866372.issue21558@psf.upfronthosting.co.za> Message-ID: <1400891982.58.0.164802334914.issue21558@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Berker, feel free to assign all these micro-doc fixes to me. Also, if you want to combine a number of clear-cut, non-controversial fixes into just one patch and tracker item, that might save us both some time. ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 02:43:22 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 May 2014 00:43:22 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1400892202.85.0.570365805411.issue13355@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching patch ---------- Added file: http://bugs.python.org/file35333/fix_triangular.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 02:46:44 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 May 2014 00:46:44 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1400892404.58.0.567324056344.issue17172@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 02:49:50 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 May 2014 00:49:50 +0000 Subject: [issue7094] Add alternate float formatting styles to new-style formatting. In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za> Message-ID: <1400892590.03.0.581425448675.issue7094@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > So I'm unsure if anyone is actually using alternate formatting. That makes sense. Any further effort should wait until there is known demand. Otherwise, we risk growing the API with codes that aren't used. ---------- resolution: -> later versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 03:14:34 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 24 May 2014 01:14:34 +0000 Subject: [issue21386] ipaddress.IPv4Address.is_global not implemented In-Reply-To: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za> Message-ID: <1400894074.34.0.533298774734.issue21386@psf.upfronthosting.co.za> Berker Peksag added the comment: + @property + def is_global(self): + return (not self in IPv4Network('100.64.0.0/10') and Can IPv4Network('100.64.0.0/10') moved to the _IPv4Constants class (e.g. _IPv4Constants._global_network = IPv4Network('100.64.0.0/10')) after http://hg.python.org/cpython/rev/e5d963cb6afc (see also issue 21513) + not self.is_private) ---------- nosy: +berker.peksag stage: -> patch review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 04:30:05 2014 From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=) Date: Sat, 24 May 2014 02:30:05 +0000 Subject: [issue21568] Win32 pip doesn't use relative path to found site-packages. Message-ID: <1400898605.95.0.696955822975.issue21568@psf.upfronthosting.co.za> New submission from ?? ?: I want to directly copy python as a portable version. But the pip always point to the place where it installed, So I am asking pip use relative to found site-packages under win32. ---------- messages: 219018 nosy: ??.? priority: normal severity: normal status: open title: Win32 pip doesn't use relative path to found site-packages. versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 04:45:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 May 2014 02:45:18 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1400899518.74.0.777441614092.issue13355@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: So now triangular(10, 10, 20) will always return 10? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 06:30:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 24 May 2014 04:30:27 +0000 Subject: [issue18604] Consolidate gui available checks in test.support In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za> Message-ID: <3gbBSd0QmXz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset fef11a65a5e5 by Ned Deily in branch '2.7': Issue #18604: Skip the Tk instantiation test on OS X because it can http://hg.python.org/cpython/rev/fef11a65a5e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 06:34:42 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sat, 24 May 2014 04:34:42 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400906082.28.0.330834629881.issue21477@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Posting a cumulative patch of all htest written so far. They include IOBinding, Tooltips, MultiStatusbar, tabbedpages, objectbrowser, scrolledlist, dynOptionWidget, treewidget, widgetredirector, colordelegator, calltip and multicall, besides aboutDialog, ClassBrowser, PathBrowser, textView and configHelpSourceEdit already posted before. This patch is named week1.diff *Improving run/runall - (run-runall.diff) This patch concerns more with the way run/runall are executed. The only modification for this occurs in the file htest.py I have streamlined run/runall into a single function. The behavior is same as the current htest.py, except for the reuse of a single root window and the addition of a "next" button. The logic behind it is contained in line 206 to line 223 of htest.py when run-runall.diff is applied. In short, a list of tuple containing(spec, kwds and callable object) is used to store the required information. Global variables maintain the above information only for the current test. Once a user finishes a test, the values of the global variables are updated to reflect the values for the next test. The "next" button is disabled for the case when a) it is the last test 2) when run() is called from a module If this approach is desired, please say so. I will work on improving the responsiveness of the root window(Constant size of root dialog, ensuring buttons, labels etc stay in the "same place" and dont "jump" around). ---------- Added file: http://bugs.python.org/file35334/week1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 06:36:28 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sat, 24 May 2014 04:36:28 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400906188.94.0.691600016632.issue21477@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file35335/run-runall.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 06:36:57 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sat, 24 May 2014 04:36:57 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400906217.65.0.748206863401.issue21477@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Removed file: http://bugs.python.org/file35302/about+classbrowser+cfghelpsrcedit+pathbrowser+textview.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 06:40:20 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 24 May 2014 04:40:20 +0000 Subject: [issue18604] Consolidate gui available checks in test.support In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za> Message-ID: <1400906420.37.0.666588825077.issue18604@psf.upfronthosting.co.za> Ned Deily added the comment: Earlier I noted: "Somewhat surprisingly, the segfault doesn't seem to happen under the same conditions with 2.7". I'm not sure now how I came to that conclusion then but it is incorrect: the segfault definitely also occurs under the same conditions with 2.7, at least when using the current ActiveTcl 8.5.15. It did not seem to fail with the Apple system Tk 8.5.9, a more plausible result than not failing at all with 2.7. Next step: test with various Cocoa Tk versions. ---------- stage: resolved -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 06:43:24 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 24 May 2014 04:43:24 +0000 Subject: [issue21522] Add more tkinter tests In-Reply-To: <1400415959.04.0.266142881924.issue21522@psf.upfronthosting.co.za> Message-ID: <1400906604.24.0.252752088495.issue21522@psf.upfronthosting.co.za> Ned Deily added the comment: Yes, that fixes 8.4, thanks! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 06:44:25 2014 From: report at bugs.python.org (theme) Date: Sat, 24 May 2014 04:44:25 +0000 Subject: [issue21559] OverflowError should not happen for integer operations In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za> Message-ID: <1400906665.92.0.845782684644.issue21559@psf.upfronthosting.co.za> theme added the comment: This is a (non-comprehensive) list of issues that describe or imply that OverflowError on integers is normal. - http://bugs.python.org/issue7267 "Attached patch works around the inital issue (u'{0:c}'.format(256)) by raising OverflowError on int.__format__('c') if the value is not in range(0, 256)." - http://bugs.python.org/issue20539 "Patch applied to the default branch (but with OverflowError instead of ValueError for large positive inputs)." - http://bugs.python.org/issue21444 "CPython has historically imposed some artificial implementation specific details in order make the implementation cleaner and faster internally (i.e. a limit on the number of function arguments, sys.maxsize limits, etc.)" - http://bugs.python.org/issue15988 (No message explicitly telling that OverflowError is the right error to raise. However, it is implied that only the error message, not the error type, should be changed) There might be other similar issues out there. Am I opening a can of worms? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 07:33:33 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sat, 24 May 2014 05:33:33 +0000 Subject: [issue16428] turtle with compound shape doesn't get clicks In-Reply-To: <1352299609.35.0.759398778926.issue16428@psf.upfronthosting.co.za> Message-ID: <1400909613.96.0.0238792401006.issue16428@psf.upfronthosting.co.za> Changes by Jessica McKellar : ---------- nosy: +jesstess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 07:35:57 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sat, 24 May 2014 05:35:57 +0000 Subject: [issue17496] OS X test for Tk availability in runtktests.py doesn't work In-Reply-To: <1363809005.08.0.908370147082.issue17496@psf.upfronthosting.co.za> Message-ID: <1400909757.45.0.43125419357.issue17496@psf.upfronthosting.co.za> Changes by Jessica McKellar : ---------- nosy: +jesstess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 07:43:42 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 24 May 2014 05:43:42 +0000 Subject: [issue17496] OS X test for Tk availability in runtktests.py doesn't work In-Reply-To: <1363809005.08.0.908370147082.issue17496@psf.upfronthosting.co.za> Message-ID: <1400910222.17.0.120803811291.issue17496@psf.upfronthosting.co.za> Ned Deily added the comment: (See also Issue18604 which has refactored this area.) ---------- keywords: -easy versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 09:12:32 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 24 May 2014 07:12:32 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1400915552.37.0.221434503533.issue17172@psf.upfronthosting.co.za> Terry J. Reedy added the comment: My thoughts on this. Overall, +.something (and increasing as I look at it more ;-). I am opposed to adding this to the relatively long file menu. It has nothing to do with manipulating or editing files. If it is to go in, please put it on the help menu, at least for now, as the intention is to somehow help beginners. If we ever add a demo section or submenu to the Help menu or Demo to the top-level level menu, we can move this. Any patch should be applied to both 3.4 and 3.5. Turtledemo apparently does not exist in 2.7. Idle NEWS items first go into the Idle section of the regular NEWS file. They are supposed to be copied into the idlelib/NEWS with each release. That has sometimes happened but not always. (I should open separate issue to fix both the idlelib files and the procedure.) In any case, NEWS entries should not be added to a patch until it is about to be committed. Otherwise, merge conflicts are possible or even likely. With the main code in turtledemo.__main__ wrapped in a function, we could pass an 'idle' argument so that the demo could modify its behavior when run from Idle. I mention a possibility below. The patch runs turtledemo within the Idle process. It might be better to run it in a separate subprocess: python -c "from turtledemo.__main__ import main; main('idle')" One reason, aside from not leaving all the imports around, is that 3 of the demos print to console. * When clock is stopped, a traceback is printed; this in mentioned in a tracker issue (and should be fixed). * Penrose prints each info about each round; this text could/should be put in a popup text window. * Tree prints '1024'; this could be eliminated or put on the status bar under the text window, as another demo does. When Idle is run windowless with pythonw on Windows, attempts to print to the non-existent console crash the process. There have been several bug issues about this. The current patch should not be pushed with turtledemo as is unless tested with installed 3.4.1 by hand-patching idlelib. Or, all console prints should be eliminated. However, a future addition to turtledemo could create a problem. That is why I think it better that only idlelib code run within the idle process. I am bothered a bit that there is little relationship between Idle and turtledemo. Both using tkinter seems not too relevant. That both tend to be used by less experienced Python users seems a bit thin. The relationship would be stronger if there were other demos (which I would like) or if there were option in the demo to load the code for a particular example into an Idle editor window. (Each demo will run independently in an Idle user process - text output, including tracebacks resulting from ungracefully closing an example before it is done, appears in the Shell window.) ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 09:22:34 2014 From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=) Date: Sat, 24 May 2014 07:22:34 +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: <1400916154.2.0.821881539938.issue21167@psf.upfronthosting.co.za> Hrvoje Nik?i? added the comment: Note that defaulting to unsafe math in extensions will make *their* use of the Py_NAN macro break under icc. If we go that route ("-fp-model strict" for Python build, but not for extensions), we should also apply the attached patch that defines Py_NAN as Py_HUGE_VAL / Py_HUGE_VAL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 09:31:16 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sat, 24 May 2014 07:31:16 +0000 Subject: [issue17496] OS X test for Tk availability in runtktests.py doesn't work In-Reply-To: <1363809005.08.0.908370147082.issue17496@psf.upfronthosting.co.za> Message-ID: <1400916676.1.0.882619859068.issue17496@psf.upfronthosting.co.za> Jessica McKellar added the comment: Some IRC discussion about what contributors should do while this is unresolved, and the bigger plan for comprehensively addressing this: 01:53 < ned_deily> jesstess, saw your nosy on Issue17496. Beware that it's really a can of worms and definitely was misclassified as easy. Lots of edge cases, some not discussed in the issue. 03:01 < jesstess> ned_deily: can you update the ticket with edge cases not yet discussed? The issue is making life hard for some of our interns, so I'd love to see some progress on it. 03:02 < jesstess> ned_deily: I also found ronaldoussoren's conclusions hard to follow. I think a re-statement of what the best solution for the problem is would be really helpful, if you have opinions on it. 03:04 < ned_deily> jesstess, can you say how it is causing problems? 03:08 < jesstess> ned_deily: They are working on Tkinter tickets, and their primary development platform happens to be OSX, where the tests are getting skipped. One has set up a Linux VM already, which is fine, but it's a confusing issue to hit for new contributors and they also want to have the confidence that changes and new tests pass on OSX before submitting patches for review. 03:09 < ned_deily> jesstess, OK. Alas, Tk is a bit of a problem on any platform and it's pretty much a mess on OS X. 03:15 < ned_deily> jesstess, Currently, there are three different variants of Tk in use on OS X. And the most commonly used variant, the Cocoa Tk 8.5, is still relatively new and has had major bugs (still present in the version shipped by Apple in OS X) and has variations from minor release to minor release. 03:20 < ned_deily> jesstess, The plan is to make things a lot easier to test by making it easier to use a custom-built Tk for OS X. In the meantime, there really is no easy way around things. Fixing #17496 by itself won't allow testing on OS X. 03:20 < ned_deily> jesstess, For the time being, I would suggest just testing as best as possible on whatever platforms one can and submitting the patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 10:49:30 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 24 May 2014 08:49:30 +0000 Subject: [issue20689] socket.AddressFamily is absent in html pydoc In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1400921370.94.0.66509866858.issue20689@psf.upfronthosting.co.za> Berker Peksag added the comment: I couldn't reproduce this issue. I'm attaching HTML output of both socket.AddressFamily and socket.SocketType enum types. ---------- nosy: +berker.peksag Added file: http://bugs.python.org/file35336/socket.AddressFamily.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 10:49:48 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 24 May 2014 08:49:48 +0000 Subject: [issue20689] socket.AddressFamily is absent in html pydoc In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1400921388.7.0.866172034993.issue20689@psf.upfronthosting.co.za> Changes by Berker Peksag : Added file: http://bugs.python.org/file35337/socket.SocketType.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 12:06:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 May 2014 10:06:02 +0000 Subject: [issue20689] socket.AddressFamily is absent in html pydoc In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1400925962.82.0.847654923886.issue20689@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Try "./python -m pydoc -w socket". ---------- Added file: http://bugs.python.org/file35338/socket.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 12:26:32 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 May 2014 10:26:32 +0000 Subject: [issue21569] PEP 466: Python 2.7 What's New preamble changes Message-ID: <1400927192.68.0.366242673147.issue21569@psf.upfronthosting.co.za> New submission from Nick Coghlan: Some proposed changes to the introductory section of the Python 2.7 What's New document. Key changes: * I updated the Future of Python 2.x section to describe the status quo, rather than preserving the original speculation from 2010 * I added a new section to record the changes made in maintenance releases * I moved the DeprecationWarning change down to its own section, since it is really independent of Python 2.7 being the last release Open questions: * the current wording makes it clear that while it's hard to get features backported, PEP 466 isn't necessarily a one time deal. I'm open to changing that to instead just describe PEP 466 as is, without saying anything about using the PEP process to get other changes backported * I currently have the "New Features in Maintenance Releases" section near the top. Since it's hyperlinked from the "Future of Python 2.x" section anyway, perhaps I should move it towards the end instead? It occurred to me while writing this that we'll potentially have an influx of conservative Python users reading the doc this year, as RHEL 7 and CentOS 7 become generally available, finally upgrading the default Python in that ecosystem to 2.7. ---------- assignee: ncoghlan components: Documentation messages: 219031 nosy: benjamin.peterson, gvanrossum, ncoghlan priority: normal severity: normal status: open title: PEP 466: Python 2.7 What's New preamble changes type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 12:50:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 24 May 2014 10:50:14 +0000 Subject: [issue21559] OverflowError should not happen for integer operations In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za> Message-ID: <1400928614.48.0.757683192689.issue21559@psf.upfronthosting.co.za> Stefan Krah added the comment: OverflowError vs. ValueError is a debatable issue (msg215873). In my view ValueError should be raised in most of the cases. I do not see anything wrong with the docs though, since the link you posted talks about "arithmetic operations". ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 13:35:55 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 24 May 2014 11:35:55 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1400931355.03.0.0789557281655.issue13355@psf.upfronthosting.co.za> Stefan Krah added the comment: While NumPy is of course not normative, this is what they do: >>> numpy.random.triangular(left=1, right=2, mode=0) Traceback (most recent call last): File "", line 1, in File "mtrand.pyx", line 3218, in mtrand.RandomState.triangular (numpy/random/mtrand/mtrand.c:13407) ValueError: left > mode >>> numpy.random.triangular(left=1, right=2, mode=3) Traceback (most recent call last): File "", line 1, in File "mtrand.pyx", line 3220, in mtrand.RandomState.triangular (numpy/random/mtrand/mtrand.c:13433) ValueError: mode > right >>> numpy.random.triangular(left=1, right=1, mode=1) Traceback (most recent call last): File "", line 1, in File "mtrand.pyx", line 3222, in mtrand.RandomState.triangular (numpy/random/mtrand/mtrand.c:13459) ValueError: left == right ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 14:05:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 May 2014 12:05:08 +0000 Subject: [issue15809] 2.7 IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1400933108.58.0.334724075388.issue15809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Only ufix_utf8 (with the utf-8 encoding of stdin/stdout/stderr) and ufix_locale (with hacked tracebacks) make sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 14:10:16 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 May 2014 12:10:16 +0000 Subject: [issue8243] curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR' In-Reply-To: <1352121880.55.0.191535515397.issue8243@psf.upfronthosting.co.za> Message-ID: <1400933416.58.0.371155173195.issue8243@psf.upfronthosting.co.za> Georg Brandl added the comment: Knowledge of RST should be more than enough; there is not much Sphinx-specific markup, and even that you won't pick up easily while looking at the file. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 14:10:27 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 May 2014 12:10:27 +0000 Subject: [issue8243] curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR' In-Reply-To: <1352121880.55.0.191535515397.issue8243@psf.upfronthosting.co.za> Message-ID: <1400933427.84.0.011285546481.issue8243@psf.upfronthosting.co.za> Georg Brandl added the comment: you WILL pick up, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 14:19:52 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 24 May 2014 12:19:52 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1400933992.69.0.642514057624.issue1820@psf.upfronthosting.co.za> Stefan Krah added the comment: Hi Andrew. Did you by any chance sign the contributor agreement? [It's perfectly okay if you don't want to, but then we cannot use the patch from #20230.] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 14:28:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 May 2014 12:28:19 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1400934499.24.0.893181444891.issue18695@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: BDFL says (http://permalink.gmane.org/gmane.comp.python.devel/146074): """Given that the claim "Python 2 doesn't support Unicode filenames" is factually incorrect (in Python 2.7, most filesystem calls in fact do support Unicode, at least on some platforms), I think individual functions in the os module that are found lacking should be considered bugs, and if someone goes through the effort to supply an otherwise acceptable fix, we shouldn't reject it on the basis that we don't want to consider supporting Unicode filenames.""" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 15:20:58 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 May 2014 13:20:58 +0000 Subject: [issue21569] PEP 466: Python 2.7 What's New preamble changes In-Reply-To: <1400927192.68.0.366242673147.issue21569@psf.upfronthosting.co.za> Message-ID: <1400937658.88.0.870270479947.issue21569@psf.upfronthosting.co.za> Nick Coghlan added the comment: Added Brett to the nosy list for feedback, since the porting guide is mostly his work. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 15:33:50 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 24 May 2014 13:33:50 +0000 Subject: [issue20269] Inconsistent behavior in pdb when pressing Ctrl-C In-Reply-To: <1389778132.96.0.0363637857633.issue20269@psf.upfronthosting.co.za> Message-ID: <1400938430.38.0.686281196268.issue20269@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The patch with a test case. ---------- Added file: http://bugs.python.org/file35339/sigint_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 15:55:14 2014 From: report at bugs.python.org (Brandon) Date: Sat, 24 May 2014 13:55:14 +0000 Subject: [issue21570] String being confused with datetime.datetime object. Message-ID: <1400939714.27.0.921682878277.issue21570@psf.upfronthosting.co.za> New submission from Brandon: Observe the following code: import MySQLdb, MySQLdb.cursors, datetime """ ... mysqlCursor is a cursor object from a connection to database from the MySQLdb module ... """ mysqlCursor.execute("SELECT NOW()") timeRow = mysqlCursor.fetchall() currentDateTime = datetime.datetime.strptime(timeRow[0]["NOW()"], "%Y-%m-%d %H:%M:%S") I get the following error: TypeError: must be string, not datetime.datetime HOWEVER, when I cast timeRow[0]["NOW()"] to a string like: str(timeRow[0]["NOW()"]) , it works fine. For whatever reason the Python interpreter seems to interpret the string from the row of the MySQLdb cursor result as a datetime.datetime object. I have no explanation for this, besides it looking like a date time in the format of YYYY-mm-dd HH:MM:SS. I have not tried this in Python 3.x, but the bug is in the latest compile of version 2.7.6 from the FTP distribution site. ---------- components: Interpreter Core messages: 219041 nosy: brandon priority: normal severity: normal status: open title: String being confused with datetime.datetime object. type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From mal at egenix.com Sat May 24 16:05:20 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Sat, 24 May 2014 16:05:20 +0200 Subject: [issue21570] String being confused with datetime.datetime object. In-Reply-To: <1400939714.27.0.921682878277.issue21570@psf.upfronthosting.co.za> References: <1400939714.27.0.921682878277.issue21570@psf.upfronthosting.co.za> Message-ID: <5380A720.1030003@egenix.com> On 24.05.2014 15:55, Brandon wrote: > > Observe the following code: > > import MySQLdb, MySQLdb.cursors, datetime > """ ... mysqlCursor is a cursor object from a connection to database from the MySQLdb module ... """ > mysqlCursor.execute("SELECT NOW()") > timeRow = mysqlCursor.fetchall() > currentDateTime = datetime.datetime.strptime(timeRow[0]["NOW()"], "%Y-%m-%d %H:%M:%S") > > I get the following error: > > TypeError: must be string, not datetime.datetime > > HOWEVER, when I cast timeRow[0]["NOW()"] to a string like: str(timeRow[0]["NOW()"]) , it works fine. > > For whatever reason the Python interpreter seems to interpret the string from the row of the MySQLdb cursor result as a datetime.datetime object. I have no explanation for this, besides it looking like a date time in the format of YYYY-mm-dd HH:MM:SS. It's likely that MySQLdb returns the datetime value as Python datetime.datetime object, so not really surprising that you get a TypeError. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Sat May 24 16:05:33 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 24 May 2014 14:05:33 +0000 Subject: [issue21570] String being confused with datetime.datetime object. In-Reply-To: <1400939714.27.0.921682878277.issue21570@psf.upfronthosting.co.za> Message-ID: <5380A720.1030003@egenix.com> Marc-Andre Lemburg added the comment: On 24.05.2014 15:55, Brandon wrote: > > Observe the following code: > > import MySQLdb, MySQLdb.cursors, datetime > """ ... mysqlCursor is a cursor object from a connection to database from the MySQLdb module ... """ > mysqlCursor.execute("SELECT NOW()") > timeRow = mysqlCursor.fetchall() > currentDateTime = datetime.datetime.strptime(timeRow[0]["NOW()"], "%Y-%m-%d %H:%M:%S") > > I get the following error: > > TypeError: must be string, not datetime.datetime > > HOWEVER, when I cast timeRow[0]["NOW()"] to a string like: str(timeRow[0]["NOW()"]) , it works fine. > > For whatever reason the Python interpreter seems to interpret the string from the row of the MySQLdb cursor result as a datetime.datetime object. I have no explanation for this, besides it looking like a date time in the format of YYYY-mm-dd HH:MM:SS. It's likely that MySQLdb returns the datetime value as Python datetime.datetime object, so not really surprising that you get a TypeError. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 16:05:45 2014 From: report at bugs.python.org (Brett Cannon) Date: Sat, 24 May 2014 14:05:45 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1400940345.19.0.580605466008.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: Nope, I commented where I meant to. I wanted a way to promote people to **always** create modules with properly initialized attributes while also dealing with the module creation dance at the same time. Otherwise it will require expanding the API of types.ModuleType() to accommodate specs while also needing to expose a function to do the proper thing to get a module for a loader and **still** have a function to set up a module properly based on what was potentially returned from create_module(). Rolling it all into a single function that just gets you a module ready for use seems like the most practical solution from an API perspective. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 16:07:35 2014 From: report at bugs.python.org (Brett Cannon) Date: Sat, 24 May 2014 14:07:35 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1400940455.22.0.082048232723.issue21235@psf.upfronthosting.co.za> Brett Cannon added the comment: Issue #20383 is tracking adding an API to simply getting the proper module and having it be initialized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 16:11:50 2014 From: report at bugs.python.org (Brandon) Date: Sat, 24 May 2014 14:11:50 +0000 Subject: [issue21570] String being confused with datetime.datetime object. In-Reply-To: <1400939714.27.0.921682878277.issue21570@psf.upfronthosting.co.za> Message-ID: <1400940710.94.0.15771063113.issue21570@psf.upfronthosting.co.za> Brandon added the comment: Type returned as datetime, I was not familiar with the MySQLdb code. Sorry for the bad report. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 16:11:57 2014 From: report at bugs.python.org (Brandon) Date: Sat, 24 May 2014 14:11:57 +0000 Subject: [issue21570] String being confused with datetime.datetime object. In-Reply-To: <1400939714.27.0.921682878277.issue21570@psf.upfronthosting.co.za> Message-ID: <1400940717.85.0.658827803416.issue21570@psf.upfronthosting.co.za> Changes by Brandon : ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 16:28:31 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 May 2014 14:28:31 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1400941711.53.0.81553111077.issue20383@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'd ask "Why not a class method?", but I already know the answer (types.ModuleType is implemented in C, so it would be unnecessarily painful to implement it that way). Given that, the utility function approach sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 17:30:10 2014 From: report at bugs.python.org (Geoffrey Spear) Date: Sat, 24 May 2014 15:30:10 +0000 Subject: [issue21555] gcmodule.c could use pytime.h In-Reply-To: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> Message-ID: <1400945410.56.0.273383915639.issue21555@psf.upfronthosting.co.za> Geoffrey Spear added the comment: Per pitrou's suggestion, eliminate get_time altogether and use _PyTime_INTERVAL macro. ---------- Added file: http://bugs.python.org/file35340/issue21555-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 19:00:02 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 24 May 2014 17:00:02 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1400950802.22.0.0647327832235.issue18695@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Ok, I will go on then. > You have eaten "return NULL;" in posix_mkfifo. What do you mean? > If TESTFN_UNICODE.encode(TESTFN_ENCODING) fails (on POSIX locale), it will be better to run tests with > unicode(TESTFN, 'ascii') than skip them. Agreed. > Tests should check that results for unicode filename is same as for str filename. What do you mean? Can you provide an example? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 19:22:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 24 May 2014 17:22:03 +0000 Subject: [issue21555] gcmodule.c could use pytime.h In-Reply-To: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> Message-ID: <3gbWZv3FKjz7LjT@mail.python.org> Roundup Robot added the comment: New changeset d151ee749f5a by Antoine Pitrou in branch 'default': Issue #21555: simplify code in gcmodule.c by using the pytime.h functions instead of trying to call time.time() via the C API. http://hg.python.org/cpython/rev/d151ee749f5a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 19:25:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 24 May 2014 17:25:58 +0000 Subject: [issue21555] gcmodule.c could use pytime.h In-Reply-To: <1400785566.33.0.612618667653.issue21555@psf.upfronthosting.co.za> Message-ID: <1400952358.61.0.201175906431.issue21555@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch committed. Thank you for contributing, Geoffrey! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 21:33:24 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 24 May 2014 19:33:24 +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: <1400960004.86.0.506395332044.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Tal, I was referring to this mail: https://mail.python.org/pipermail/python-dev/2014-January/132066.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 22:03:48 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 24 May 2014 20:03:48 +0000 Subject: [issue21550] Add Python implementation of the tar utility In-Reply-To: <1400669354.09.0.317678574527.issue21550@psf.upfronthosting.co.za> Message-ID: <1400961828.47.0.490036931795.issue21550@psf.upfronthosting.co.za> ?ric Araujo added the comment: IIRC, when the tarfile module CLI was added, there was a decision to keep it short and simple, not mimic the whole tar(1) interface. Python core ships with modules that should be featurefull, but we don?t put much focus or effort on general utilities: the only globally installed scripts are directly useful to Python devs (idle, pydoc, pyvenv, 2to3); the stdlib modules with a CLI are quick helpers (python -m SimpleHTTPServer) or smoke tests or demos IIRC; Tools/scripts have an even lower level of usefulness and maintenance. I sympathize with the use case of finding missing pieces in tarfile, but I?m wary about the maintenance burden (code maintenance if it matches tar(1) fully, support if it does not, endless discussions about installing it on Windows like what happened for Tools/scripts/diff.py, etc). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 22:31:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 May 2014 20:31:30 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1400963490.41.0.975733052333.issue21402@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, if we allow to change signature of theses functions, here is a patch which fixes _list_from_layouttuple and _val_or_dict and rewrites tests. Mocked TkApp is used because test_functions should run without the gui resource enabled. ---------- keywords: +patch Added file: http://bugs.python.org/file35341/ttk_val_or_dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 22:32:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 May 2014 20:32:02 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1400963522.56.0.578248522065.issue21402@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 22:50:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 May 2014 20:50:17 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1400950802.22.0.0647327832235.issue18695@psf.upfronthosting.co.za> Message-ID: <2793019.LX2NAr7MII@raxxla> Serhiy Storchaka added the comment: > > You have eaten "return NULL;" in posix_mkfifo. > What do you mean? You deleted "return NULL;" after "if (!PyArg_ParseTuple(...))" in the posix_mkfifo() function. > > Tests should check that results for unicode filename is same as for str > > filename. > What do you mean? Can you provide an example? For example test_statvfs should check that os.statvfs(TESTFN_UNICODE) == os.statvfs(TESTFN_UNICODE_ENCODED) (where TESTFN_UNICODE_ENCODED is relevant 8-bit str). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 23:10:11 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 24 May 2014 21:10:11 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400965811.22.0.160745708406.issue21477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: run-runall.diff import cleanly to 3.4. Running all the tests works well enough that I am applying this, with minor changes, to be a base for further patches. Good job. The few problems I fixed: 1. AutoCompleteWindow.py had \n added at the beginning. I just deleted it. 2. 2 files had an unused 'import tkinter'. I deleted those lines. (Any new imports, that are used, should be 'import tkinter as tk' so that is the only place where the Tkinter/tkinter change shows up in the Idle file.) 3. patchcheck found 7 files with extra whitespace to be deleted. Things to do starting from this. 1. See review comments on htest.run(). 2. See review comments on text changes. 3. See review comments on individual tests. There will be more of these, but run changes and 4) below are the most important now. 4. Many wrappers create a separate root=Tk() (and mainloop) ins4tead of reusing the parent arg. The result is that clicking [Next] does not delete the test window, as it is not a child of the main window. The test window has to be closed separately. So unless the test *requires* a new root and mainloop, please delete them. (Modal dialogs have to be closed explicitly - message should say so.) 5. When I changed root = tk.Tk() to root = parent in _editor_window, the test seemed to continue to work fine. Why did you comment it out? Please restore it and make any change necessary to _editor_window to work with the revised run(). ---------- Added file: http://bugs.python.org/file35342/run-runall-34.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 23:29:38 2014 From: report at bugs.python.org (Jan Kanis) Date: Sat, 24 May 2014 21:29:38 +0000 Subject: [issue21571] Python build should check CPATH, C_INCLUDE_PATH for module dependencies Message-ID: <1400966978.12.0.900228617975.issue21571@psf.upfronthosting.co.za> New submission from Jan Kanis: When building, pythons setup.py tries to find external sources for optional modules such as ssl, sqlite, etc. For that it searches the CFLAGS environment variable for -I options. C compilers such as gcc and clang also interpret CPATH and C_INCLUDE_PATH as extra search paths for headers/sources. Setup.py should do the same and also look in paths specified in those environment variables. ---------- components: Build messages: 219056 nosy: JanKanis priority: normal severity: normal status: open title: Python build should check CPATH, C_INCLUDE_PATH for module dependencies type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 23:50:56 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sat, 24 May 2014 21:50:56 +0000 Subject: [issue21562] curses getsxy() should be curses getxy() in https://docs.python.org/3/library/curses.html#curses.cursxy In-Reply-To: <1400870816.3.0.300590440768.issue21562@psf.upfronthosting.co.za> Message-ID: <1400968256.6.0.23320460431.issue21562@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Python 3.5. File "_cursesmodule.c", line 3522. Marking this bug as invalid. Please, reopen if you think I am mistaken. ---------- assignee: docs at python -> jcea nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 24 23:51:38 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sat, 24 May 2014 21:51:38 +0000 Subject: [issue21562] curses getsxy() should be curses getxy() in https://docs.python.org/3/library/curses.html#curses.cursxy In-Reply-To: <1400870816.3.0.300590440768.issue21562@psf.upfronthosting.co.za> Message-ID: <1400968298.95.0.563046302411.issue21562@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 00:01:23 2014 From: report at bugs.python.org (akira) Date: Sat, 24 May 2014 22:01:23 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1400968883.81.0.499408077675.issue21332@psf.upfronthosting.co.za> akira added the comment: > The short answer is: no, you don't have to make you thread thread > safe, as long as it can reliably run even in the presence of > background threads (like the tkinter threads Victor mentions). https://mail.python.org/pipermail/python-dev/2014-May/134541.html It seems the test may be left as is. Please, review the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 00:13:51 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 24 May 2014 22:13:51 +0000 Subject: [issue15293] AST nodes do not support garbage collection In-Reply-To: <1341744454.01.0.740763019773.issue15293@psf.upfronthosting.co.za> Message-ID: <1400969631.25.0.486546979164.issue15293@psf.upfronthosting.co.za> Benjamin Peterson added the comment: How are you reproducing the bug? In Python 2, the AST base class doesn't have a __dict__, and it's subtypes do support GC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 00:15:41 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 24 May 2014 22:15:41 +0000 Subject: [issue21534] 404 on documentation download links In-Reply-To: <1400506899.65.0.0656735087144.issue21534@psf.upfronthosting.co.za> Message-ID: <1400969741.89.0.284545592453.issue21534@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 00:41:04 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 24 May 2014 22:41:04 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400971264.12.0.226363622789.issue21477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since I wanted to get this large patch applied as a basis for further work, I went ahead with the 2.7 backport. I am listing the issues in converting run-runall-34.diff to run-runall-27.diff to help Saimadhav do this in the future. 1. /tkinter/Tkinter/ 7 places (easy). 2. /print(xxx)/print xxx/ 3 places in 2 idlelib files, but leave print(widget.result) alone in htest 3. /importlib.machinery/imp/ in Pathbrowser.py 4. In textView.py, the 2.7 line text = file(filename, 'r').read() was changed in 3.x to two lines: with open(filename, 'r') as f: text = f.read() Since inserting or deleting a line in a diff file (as opposed to the within-line edits above) is tricky, and since this line is part of a chunk being deleted, I left this alone in the -27.diff resulting from the changes above. The diff uploaded included the handpatch changes. (Note: some time ago, I converted all open statements to 'with open' in 2.7 and 3.x. I did not think of 'file(' as a synonym for 'open('. Any other uses of 'file(' should be converted also.) 5. The surprise I had forgotten about. 'nonlocal', used in the new version of run(), is new in 3.0! Fortunately, I remember the ugly hack we used in 2.x. It does mean, however, that the run code is different in 2.7. Future patches to run should only patch run(). 6. ColorDelegator: the code in the 3.x test is displayed for me as ? ?Sc I replaced source with a string literal. I think we should use a revised version of this, with everything that should be colored, in 3.x also and skip the file read. ---------- Added file: http://bugs.python.org/file35343/run-runall-27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 00:49:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 24 May 2014 22:49:27 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <3gbfrg5TXXz7Llp@mail.python.org> Roundup Robot added the comment: New changeset ece24bcd1a6f by Terry Jan Reedy in branch '2.7': Issue #21477: Idle htest: merge and modify run and runall; add many tests. http://hg.python.org/cpython/rev/ece24bcd1a6f New changeset 038cbbef4539 by Terry Jan Reedy in branch '3.4': Issue #21477: Idle htest: merge and modify run and runall; add many tests. http://hg.python.org/cpython/rev/038cbbef4539 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 01:02:16 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 24 May 2014 23:02:16 +0000 Subject: [issue21572] Use generic license web page rather than requiring release-specific license pages Message-ID: <1400972536.12.0.296163327906.issue21572@psf.upfronthosting.co.za> New submission from Ned Deily: Currently the "license" command for the interactive interpreter falls back to attempting to download a release-specific license URL if LICENSE.txt is not found locally. This adds the requirement to the release process to create a release-specific license file for each release. However, as was implemented in Issue19043, we now use a generic license page in the documentation that no longer needs to be updated for each release (http://www.python.org/psf/license/ -> https://docs.python.org/2/license.html). Suggest changing Lib/site.py to use the generic URL as the fallback, thus eliminating the need to create a redundant downloads license page for each release. For 2.7: diff --git a/Lib/site.py b/Lib/site.py --- a/Lib/site.py +++ b/Lib/site.py @@ -436,7 +436,7 @@ for supporting Python development. See www.python.org for more information.""") here = os.path.dirname(os.__file__) __builtin__.license = _Printer( - "license", "See http://www.python.org/%.3s/license.html" % sys.version, + "license", "See http://www.python.org/psf/license/", ["LICENSE.txt", "LICENSE"], [os.path.join(here, os.pardir), here, os.curdir]) For 3.x: diff --git a/Lib/site.py b/Lib/site.py --- a/Lib/site.py +++ b/Lib/site.py @@ -373,7 +373,7 @@ dirs.extend([os.path.join(here, os.pardir), here, os.curdir]) builtins.license = _sitebuiltins._Printer( "license", - "See http://www.python.org/download/releases/%.5s/license" % sys.version, + "See http://www.python.org/psf/license/", files, dirs) For PEP 101: diff --git a/pep-0101.txt b/pep-0101.txt --- a/pep-0101.txt +++ b/pep-0101.txt @@ -487,8 +487,6 @@ ___ Comment out the "This is a preview release" or the "This is a production release" paragraph as appropriate - ___ Update the license in `download/releases/X.Y.Z/license` - Note, you don't have to copy any release files into this directory; they only live on dinsdale in the ftp directory. ---------- messages: 219062 nosy: benjamin.peterson, georg.brandl, larry, ned.deily priority: normal severity: normal stage: patch review status: open title: Use generic license web page rather than requiring release-specific license pages versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 01:03:42 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 24 May 2014 23:03:42 +0000 Subject: [issue21572] Use generic license web page rather than requiring release-specific license pages In-Reply-To: <1400972536.12.0.296163327906.issue21572@psf.upfronthosting.co.za> Message-ID: <1400972618.22635.121200097.2775CA84@webmail.messagingengine.com> Benjamin Peterson added the comment: Big +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 01:19:28 2014 From: report at bugs.python.org (Lita Cho) Date: Sat, 24 May 2014 23:19:28 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1400973568.87.0.541529555373.issue17172@psf.upfronthosting.co.za> Lita Cho added the comment: I did not know that NEWS items should not be edited unless it is about to be committed. The previous comments suggested to put it in. Thank you for the feedback. I can move the Turtle Demp into the Help Menu rather than the File menu. I agree that it seems out of place. I can also make it such that it runs the demo as an external process rather than within IDLE. That way, it is completely separate by IDLE and we don't create a dependency. I think if we were to load in future demos, they could be run as other processes rather than within IDLE, so that future additions don't end up crashing IDLE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 01:31:18 2014 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 24 May 2014 23:31:18 +0000 Subject: [issue7094] Add alternate float formatting styles to new-style formatting. In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za> Message-ID: <1400974278.4.0.759839330685.issue7094@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'm going to go ahead and close this. Alternate formatting was added to float and complex. I think leaving this issue open just confuses whether or not that support was added. I know I had to go back and double check. Since decimal never participated in %-formatting, there are no "migration to .format()" issues with it. I agree that it's unlikely anyone would want it, and if we want to add it, it would be a new, separate issue. ---------- resolution: later -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 01:44:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 24 May 2014 23:44:28 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1400975068.53.0.73843116205.issue21477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I just discovered today that Rietveld can do diffs between diffs, so to speak. For example, http://bugs.python.org/review/21477/diff2/11941:11942/Lib/idlelib/idle_test/htest.py showed the changes between patched htest in 3.4 and 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 02:18:58 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 25 May 2014 00:18:58 +0000 Subject: [issue21572] Use generic license web page rather than requiring release-specific license pages In-Reply-To: <1400972536.12.0.296163327906.issue21572@psf.upfronthosting.co.za> Message-ID: <1400977137.94.0.45794862541.issue21572@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sounds like a pretty obvious improvement. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 03:48:25 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sun, 25 May 2014 01:48:25 +0000 Subject: [issue21573] Clean up turtle.py code formatting Message-ID: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> New submission from Jessica McKellar: Lib/turtle.py has some code formatting issues. Let's clean them up to make the module easier to read as interns start working on it this summer. Specifically: 1. Run turtle.py through a pep8 checker and fix the issues that are reasonable to fix. 2. Run turtle.py through a linter like pyflakes and fix reasonable linter issues. 3. Examine commented out code, and either remove it or open a ticket if it represents an issue that should be fixed. 4. Examine # XXX comments, and either remove them if they are no longer applicable, or open tickets for them if they still represent bugs and then remove them. ---------- assignee: jesstess keywords: gsoc messages: 219068 nosy: jesstess priority: normal severity: normal stage: needs patch status: open title: Clean up turtle.py code formatting type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 04:41:35 2014 From: report at bugs.python.org (theme) Date: Sun, 25 May 2014 02:41:35 +0000 Subject: [issue21559] OverflowError should not happen for integer operations In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za> Message-ID: <1400985695.79.0.849169048304.issue21559@psf.upfronthosting.co.za> theme added the comment: skrah: I am not sure what link are you referring to. However, no matter which link you are talking about, the documentation still doesn't match the behavior no matter how you interpret it. Some possible interpretations of the documentation on OverflowError: - OverflowError is raised only by "arithmetic operations" on non-integers in the strictest sense possible (e.g. +,-,*,/,**) , which does not include library functions. This interpretation seems absurd to me. - OverflowError is raised by arithmetic operations on "non-integers", where "integers" refer only to python integers, which never overflow, and excludes C integers. This seems pretty awkward, since this implies that the behavior of library functions regarding overflows is implementation-defined (aka undefined behavior) to some extent, and I don't think this is good. - OverflowError is raised by arithmetic operations on non-integers, which can be initiated by either the user, a user script or a library function. However, the issues linked in msg219024 involve library functions that obviously deals only with integers. Resolving behaviors to match this interpretation seems pretty logical to me, but will most likely cause a lot of implementation issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 04:44:34 2014 From: report at bugs.python.org (Lita Cho) Date: Sun, 25 May 2014 02:44:34 +0000 Subject: [issue21573] Clean up turtle.py code formatting In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> Message-ID: <1400985874.8.0.734877201803.issue21573@psf.upfronthosting.co.za> Changes by Lita Cho : ---------- nosy: +Lita.Cho _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 05:30:15 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 25 May 2014 03:30:15 +0000 Subject: [issue17095] Modules/Setup *shared* support broken In-Reply-To: <1359669296.59.0.227426586133.issue17095@psf.upfronthosting.co.za> Message-ID: <1400988615.79.0.64524345476.issue17095@psf.upfronthosting.co.za> Ned Deily added the comment: Your original patch LGTM. However, since it was written, Setup *shared* support became even more broken due to changes in Makefile macros. Attached is an updated patch. I've never tried customizing Setup before so I don't have a lot of confidence that it now works as expected in all cases, but I tried a few cases (like building _ssl with a non-standard OpenSSL on OS X) and they did work. ---------- nosy: +ned.deily stage: -> patch review versions: +Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file35344/issue17095_modules_setup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 05:44:59 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 25 May 2014 03:44:59 +0000 Subject: [issue21571] Python build should check CPATH, C_INCLUDE_PATH for module dependencies In-Reply-To: <1400966978.12.0.900228617975.issue21571@psf.upfronthosting.co.za> Message-ID: <1400989499.45.0.542541422654.issue21571@psf.upfronthosting.co.za> Ned Deily added the comment: setup.py already does that but only for builds on OS X (darwin); see http://hg.python.org/cpython/file/default/setup.py#l539. The comments there suggest to me that the code was made conditional to OS X to avoid introducing regressions in builds on other platforms. The restriction could be removed but probably only for a feature release (e.g. 3.5). Another approach that has been suggested is to add either configure options (like in Issue21541) or environment variables (Issue5575). In theory, the best approach might be to use the customization features provided by Modules/Setup*; unfortunately, at the moment there are some major problems with that in current Python 3.4 releases (see Issue17095 for a proposed patch for 3.4). ---------- nosy: +ned.deily type: behavior -> enhancement versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 05:51:05 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 25 May 2014 03:51:05 +0000 Subject: [issue21573] Clean up turtle.py code formatting In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> Message-ID: <1400989865.3.0.292359370843.issue21573@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +gregorlingl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 07:14:18 2014 From: report at bugs.python.org (Lita Cho) Date: Sun, 25 May 2014 05:14:18 +0000 Subject: [issue21573] Clean up turtle.py code formatting In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> Message-ID: <1400994858.9.0.344052978076.issue21573@psf.upfronthosting.co.za> Lita Cho added the comment: I'm claiming this ticket. Plan to work on it during my OPW internship. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 09:04:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 07:04:13 +0000 Subject: [issue21552] String length overflow in Tkinter In-Reply-To: <1400769722.86.0.708994855199.issue21552@psf.upfronthosting.co.za> Message-ID: <1401001453.0.0.0922818704994.issue21552@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a little simpler patch. Instead of checking string length in custom converter, it is checked after invocation of PyArg_ParseTuple. Also added bigmem tests. ---------- Added file: http://bugs.python.org/file35345/tkinter_strlen_overflow_alt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 09:58:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 07:58:36 +0000 Subject: [issue21343] os.path.relpath returns inconsistent types In-Reply-To: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za> Message-ID: <1401004716.05.0.380483601652.issue21343@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why you should check the type? There is no difference between '.' and u'.'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 10:02:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 08:02:35 +0000 Subject: [issue21331] Reversing an encoding with unicode-escape returns a different result In-Reply-To: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za> Message-ID: <1401004954.99.0.771835210965.issue21331@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 10:28:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 08:28:22 +0000 Subject: [issue20197] Support WebP image format detection in imghdr module In-Reply-To: <1389217099.41.0.299916311184.issue20197@psf.upfronthosting.co.za> Message-ID: <1401006502.27.0.456975316774.issue20197@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 10:39:16 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 May 2014 08:39:16 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1401007156.7.0.27556177509.issue8743@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching a draft patch with tests. ---------- Added file: http://bugs.python.org/file35346/fix_set_abc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 10:45:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 25 May 2014 08:45:47 +0000 Subject: [issue20197] Support WebP image format detection in imghdr module In-Reply-To: <1389217099.41.0.299916311184.issue20197@psf.upfronthosting.co.za> Message-ID: <3gbw4p1JF4z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 4fd17e28d4bf by Serhiy Storchaka in branch 'default': Issue #20197: Added support for the WebP image type in the imghdr module. http://hg.python.org/cpython/rev/4fd17e28d4bf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 11:31:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 09:31:55 +0000 Subject: [issue20197] Support WebP image format detection in imghdr module In-Reply-To: <1389217099.41.0.299916311184.issue20197@psf.upfronthosting.co.za> Message-ID: <1401010315.5.0.530430004451.issue20197@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Fabrice and Claudiu. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 11:37:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 09:37:01 +0000 Subject: [issue21574] Port image types detections from PIL to the imghdr module Message-ID: <1401010621.11.0.919611847501.issue21574@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: It would be good to add support of all image types which are supported in PIL to the imghdr module. ---------- components: Library (Lib) keywords: easy messages: 219078 nosy: Claudiu.Popa, effbot, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Port image types detections from PIL to the imghdr module type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 11:40:21 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 25 May 2014 09:40:21 +0000 Subject: [issue21574] Port image types detections from PIL to the imghdr module In-Reply-To: <1401010621.11.0.919611847501.issue21574@psf.upfronthosting.co.za> Message-ID: <1401010821.15.0.409070544624.issue21574@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Sounds good, I'll create a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 11:44:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 09:44:45 +0000 Subject: [issue19925] Add unit test for spwd module In-Reply-To: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za> Message-ID: <1401011085.77.0.72569655294.issue19925@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka type: -> enhancement versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 12:05:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 25 May 2014 10:05:03 +0000 Subject: [issue18918] help('FILES') finds no documentation In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za> Message-ID: <3gbxrF6R1mz7LlQ@mail.python.org> Roundup Robot added the comment: New changeset 3fa76139c908 by Serhiy Storchaka in branch '3.4': Issue #18918: Removed non-existing topic from a list of available topics. http://hg.python.org/cpython/rev/3fa76139c908 New changeset e5bac5b2f38d by Serhiy Storchaka in branch 'default': Issue #18918: Removed non-existing topic from a list of available topics. http://hg.python.org/cpython/rev/e5bac5b2f38d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 12:13:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 10:13:33 +0000 Subject: [issue18918] help('FILES') finds no documentation In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za> Message-ID: <1401012813.35.0.206111555124.issue18918@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed in Python 3. Thanks Claudiu. But it is not clear why this topic is absent in 2.7. ---------- nosy: +serhiy.storchaka versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 13:06:04 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sun, 25 May 2014 11:06:04 +0000 Subject: [issue19925] Add unit test for spwd module In-Reply-To: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za> Message-ID: <1401015964.54.0.743777001177.issue19925@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Thanks, Serhiy, for the review! Here is the updated patch. ---------- Added file: http://bugs.python.org/file35347/unittest_for_spwd_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 13:28:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 11:28:53 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1401017333.24.0.890134882185.issue19385@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is no need to speed up methods which do IO (__getitem__, __setitem__, __delitem__). However method which works only with an index (keys, iterkeys, __contains__, __len__) can be optimized. In the __contains__ method an exception can be raised not only by nen-existent __contains__ of None, but from __hash__ or __eq__ methods of a key, so we should distinguish these cases. ---------- stage: resolved -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file35348/issue19385_speed_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 14:34:11 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 25 May 2014 12:34:11 +0000 Subject: [issue20766] reference leaks in pdb In-Reply-To: <1393326154.87.0.194575074306.issue20766@psf.upfronthosting.co.za> Message-ID: <1401021251.84.0.565429842024.issue20766@psf.upfronthosting.co.za> Xavier de Gaye added the comment: An improved patch with a test case. ---------- Added file: http://bugs.python.org/file35349/refleak_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 14:36:25 2014 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Sun, 25 May 2014 12:36:25 +0000 Subject: [issue21575] list.sort() should show arguments in tutorial Message-ID: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za> New submission from Jan-Philip Gehrcke: Currently, the tutorial for the list sort method does not show allowed arguments: list.sort() Sort the items of the list in place. (see e.g. https://docs.python.org/3.4/tutorial/datastructures.html) Is there a reason why we do not show the arguments there? For simplicity? One should note that a web search for Python's list methods ranks that page pretty high. We could list the defaults, as in the built-in help: L.sort(cmp=None, key=None, reverse=False) And could link to https://docs.python.org/2/library/functions.html#sorted for an explanation. ---------- assignee: docs at python components: Documentation messages: 219085 nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, jgehrcke priority: normal severity: normal status: open title: list.sort() should show arguments in tutorial versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 15:13:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 25 May 2014 13:13:27 +0000 Subject: [issue21565] multiprocessing: use contex-manager protocol for synchronization primitives In-Reply-To: <1400879607.2.0.100700742941.issue21565@psf.upfronthosting.co.za> Message-ID: <3gc21g05gRz7LmT@mail.python.org> Roundup Robot added the comment: New changeset 9724eb19f6d0 by Charles-Fran?ois Natali in branch 'default': Issue #21565: multiprocessing: use contex-manager protocol for synchronization http://hg.python.org/cpython/rev/9724eb19f6d0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 15:24:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 25 May 2014 13:24:10 +0000 Subject: [issue19925] Add unit test for spwd module In-Reply-To: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za> Message-ID: <3gc2G14k5Dz7LjX@mail.python.org> Roundup Robot added the comment: New changeset c35274fe5b35 by Serhiy Storchaka in branch '2.7': Issue #19925: Added tests for the spwd module. Original patch by Vajrasky Kok. http://hg.python.org/cpython/rev/c35274fe5b35 New changeset 9bdbe0b08dff by Serhiy Storchaka in branch '3.4': Issue #19925: Added tests for the spwd module. Original patch by Vajrasky Kok. http://hg.python.org/cpython/rev/9bdbe0b08dff New changeset 4b187f5aa960 by Serhiy Storchaka in branch 'default': Issue #19925: Added tests for the spwd module. Original patch by Vajrasky Kok. http://hg.python.org/cpython/rev/4b187f5aa960 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 15:25:07 2014 From: report at bugs.python.org (Andy Maier) Date: Sun, 25 May 2014 13:25:07 +0000 Subject: [issue21561] help() on enum34 enumeration class creates only a dummy documentation In-Reply-To: <1400866031.36.0.493061688069.issue21561@psf.upfronthosting.co.za> Message-ID: <1401024307.46.0.637979823166.issue21561@psf.upfronthosting.co.za> Andy Maier added the comment: The pydoc.py of Python 3.4 that supposedly has been fixed has a lot of changes compared to 2.7, but the place where I applied my "fix" in TextDoc.docclass() is unchanged. So it seems that my fix should be regarded only to be a quick fix, and the real fix would be somewhere in the 3.4 pydoc.py. I tried to understand the changes but gave up after a while. My quick fix (with a better text than one that contains "TBD") is still better than not having it fixed, but more ideally the real fix should be rolled back to the 2.7 pydoc.py. Is there anything else I can do to help with this bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 15:33:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 13:33:54 +0000 Subject: [issue19925] Add unit test for spwd module In-Reply-To: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za> Message-ID: <1401024834.78.0.500009926979.issue19925@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed with some changes. geteuid() is used instead getuid(), and checked that os.geteuid exists (see test_shutil). Checked deprecated attributes sp_nam and sp_pwd. Added tests for the calling getspnam() with wrong number of arguments and with bytes (on 3.x) or unicode (2.7) name. Thank you Vajrasky for your contribution. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 15:36:49 2014 From: report at bugs.python.org (beta) Date: Sun, 25 May 2014 13:36:49 +0000 Subject: [issue21576] Overwritten (custom) uuid inside dictionary Message-ID: <1401025009.13.0.783307535122.issue21576@psf.upfronthosting.co.za> New submission from beta: Results: Block: 2d = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0} Block: 2e = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0} Block: 2f = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 0} Block: 8c = {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 1} same as {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 1} Block: 8d = {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 1} same as {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 1} Block: 4e = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} Block: 4f = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} Block: 4g = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} Block: 4h = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 2} Block: 6d = {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3} same as {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3} Block: 6e = {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3} same as {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3} Block: d3 = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4} Block: d4 = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4} Block: d5 = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 4} Block: 10h = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5} Block: 10i = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5} Block: 10j = {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5} same as {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5} Block: j3 = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} Block: j4 = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} Block: j5 = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} Block: j6 = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 6} Block: 10d = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} Block: 10e = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} Block: 10f = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} Block: 10g = {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} same as {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7} Actually SetPositions = {} result: { '10d': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, '10e': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, '10f': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, '10g': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, '10h': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}, '10i': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}, '10j': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}, '2d': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}, '2e': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}, '2f': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}, '4e': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, '4f': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, '4g': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, '4h': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, '6d': {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3}, '6e': {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3}, '8c': {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3}, '8d': {'Blocks': 2, 'Name': 'Mijnenveger', 'uuid': 3}, 'd3': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}, 'd4': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}, 'd5': {'Blocks': 3, 'Name': 'Fregatten', 'uuid': 5}, 'j3': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, 'j4': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, 'j5': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}, 'j6': {'Blocks': 4, 'Name': 'Kruiser', 'uuid': 7}} uuid are overwritten, but where? It seems like a Python bug, but don't really know to be sure, so sorry if it isn't one. ---------- files: 1.py messages: 219090 nosy: beta990 priority: normal severity: normal status: open title: Overwritten (custom) uuid inside dictionary versions: Python 3.4 Added file: http://bugs.python.org/file35350/1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 15:45:08 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 25 May 2014 13:45:08 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1401025508.82.0.832585783337.issue8743@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, interesting - I completely missed the comparison operators in my patch and tests. Your version looks good to me, though. That looks like a patch against 2.7 - do you want to add 2.7 & 3.4 back to the list of target versions for the fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 16:36:16 2014 From: report at bugs.python.org (Florent Rougon) Date: Sun, 25 May 2014 14:36:16 +0000 Subject: [issue17679] sysconfig generation uses some env variables multiple times In-Reply-To: <1365515508.55.0.936246153534.issue17679@psf.upfronthosting.co.za> Message-ID: <1401028575.99.0.309173268989.issue17679@psf.upfronthosting.co.za> Changes by Florent Rougon : ---------- nosy: +frougon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 16:55:53 2014 From: report at bugs.python.org (Matt Bachmann) Date: Sun, 25 May 2014 14:55:53 +0000 Subject: [issue21343] os.path.relpath returns inconsistent types In-Reply-To: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za> Message-ID: <1401029753.15.0.918514439927.issue21343@psf.upfronthosting.co.za> Matt Bachmann added the comment: There is a difference! '.' is a bytes string and u'.' is a unicode one! I found this problem because I work on a project that supports both python2 and python3. In python3 I pass in unicode I get back unicode. In python2.7 I pass in unicode and I get back a bytes string. We need to ensure that all data in the system is unicode. Under 2.7 I get unicode sometimes and bytes other times so I need to do this ugly check root_rel_path = os.path.relpath(self._cwd, self._root) if isinstance(root_rel_path, six.binary_type): root_rel_path = root_rel_path.decode() in order to ensure that my string is once again of the correct type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 17:04:44 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 25 May 2014 15:04:44 +0000 Subject: [issue21565] multiprocessing: use contex-manager protocol for synchronization primitives In-Reply-To: <1400879607.2.0.100700742941.issue21565@psf.upfronthosting.co.za> Message-ID: <1401030284.35.0.167041024633.issue21565@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed (I've added a versionchanged as suggested by Antoine), closing. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 17:21:42 2014 From: report at bugs.python.org (Matt Bachmann) Date: Sun, 25 May 2014 15:21:42 +0000 Subject: [issue21343] os.path.relpath returns inconsistent types In-Reply-To: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za> Message-ID: <1401031302.38.0.314879722615.issue21343@psf.upfronthosting.co.za> Matt Bachmann added the comment: Perhaps this is the bug I should be filing but here is why this comes up for me. I get different output from this function if I pass in two types. On my machine: os.path.relpath(u'test_srcl.txt', u'.') returns u'test_src.txt' os.path.relpath(u'test_srcl.txt', '.') returns u'../../Users/bachmann/Code/diff-cover/diff_cover/tests/fixtures/test_src.txt' I make a couple calls to this function, if the first call gives me back a byte string and I pass it to the second call I get the incorrect result. So I need to decode. If the function always gave back the same type as I gave it I would not have this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 17:39:50 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 25 May 2014 15:39:50 +0000 Subject: [issue18381] unittest warnings counter In-Reply-To: <1373114259.86.0.274298241842.issue18381@psf.upfronthosting.co.za> Message-ID: <1401032390.63.0.0597803774176.issue18381@psf.upfronthosting.co.za> Berker Peksag added the comment: I get a test failure when I run the test suite with unittest.patch: test_Exit (unittest.test.test_program.Test_TestProgram) ... test test_unittest crashed -- Traceback (most recent call last): File "/home/berker/projects/cpython-default/Lib/test/regrtest.py", line 1278, in runtest_inner test_runner() File "/home/berker/projects/cpython-default/Lib/test/test_unittest.py", line 8, in test_main support.run_unittest(unittest.test.suite()) File "/home/berker/projects/cpython-default/Lib/test/support/__init__.py", line 1764, in run_unittest _run_suite(suite) File "/home/berker/projects/cpython-default/Lib/test/support/__init__.py", line 1730, in _run_suite result = runner.run(suite) File "/home/berker/projects/cpython-default/Lib/unittest/runner.py", line 178, in run test(result) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 87, in __call__ return self.run(*args, **kwds) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 125, in run test(result) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 87, in __call__ return self.run(*args, **kwds) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 125, in run test(result) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 87, in __call__ return self.run(*args, **kwds) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 125, in run test(result) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 87, in __call__ return self.run(*args, **kwds) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 125, in run test(result) File "/home/berker/projects/cpython-default/Lib/unittest/case.py", line 647, in __call__ return self.run(*args, **kwds) File "/home/berker/projects/cpython-default/Lib/unittest/case.py", line 597, in run testMethod() File "/home/berker/projects/cpython-default/Lib/unittest/test/test_program.py", line 119, in test_Exit testLoader=self.FooBarLoader()) File "/home/berker/projects/cpython-default/Lib/unittest/case.py", line 726, in assertRaises return context.handle('assertRaises', callableObj, args, kwargs) File "/home/berker/projects/cpython-default/Lib/unittest/case.py", line 173, in handle callable_obj(*args, **kwargs) File "/home/berker/projects/cpython-default/Lib/unittest/main.py", line 93, in __init__ self.runTests() File "/home/berker/projects/cpython-default/Lib/unittest/main.py", line 244, in runTests self.result = testRunner.run(self.test) File "/home/berker/projects/cpython-default/Lib/unittest/runner.py", line 178, in run test(result) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 87, in __call__ return self.run(*args, **kwds) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 125, in run test(result) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 87, in __call__ return self.run(*args, **kwds) File "/home/berker/projects/cpython-default/Lib/unittest/suite.py", line 125, in run test(result) File "/home/berker/projects/cpython-default/Lib/unittest/case.py", line 647, in __call__ return self.run(*args, **kwds) File "/home/berker/projects/cpython-default/Lib/unittest/case.py", line 597, in run testMethod() File "/home/berker/projects/cpython-default/Lib/unittest/test/test_program.py", line 60, in testFail assert False AssertionError The new patch (see issue18381.diff) fixes that failure. Other changes: * Added documentation * Added a test case for addWarning and TestResult.warnings * Added "print warning" feature ---------- nosy: +berker.peksag versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file35351/issue18381.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 17:47:06 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sun, 25 May 2014 15:47:06 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401032826.39.0.866997895696.issue21477@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Modifications in htest-25052014.diff 1. ClassBrowser, PathBrowser, EditorWindow no longer close parent when closed 2. Sample code in _color_delegator changed to string, instead of reading from file. 3. String text change for Tooltip. 4. Adds htest for FormatParagraph, Percolator, EditorWindow(rather uncomment's spec), StackViewer, KeyBinding 5. Modification to run based on review comments at http://bugs.python.org/review/21477/diff/11937/Lib/idlelib/idle_test/htest.py 6. Other cosmetic changes to spec string 'msg' text. When this diff(subject to passing review and feedback) is pushed, I will make a corresponding patch for 2.7 ---------- Added file: http://bugs.python.org/file35352/htest-25052014.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 18:27:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 16:27:46 +0000 Subject: [issue21343] os.path.relpath returns inconsistent types In-Reply-To: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za> Message-ID: <1401035266.47.0.487640288634.issue21343@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In Python 2 str is coerced to unicode, so most functions should return the same (or compatible) result for str and unicode argument if it contains only 7-bit ASCII characters. Of course there are several obvious exceptions, such as type() or repr(). And presumably there are several bugs. Apparently the actual bug in your case is that os.path.relpath(u'test_srcl.txt', u'.') and os.path.relpath(u'test_srcl.txt', '.') return totally different results. What are os.getcwd(), os.getcwdu(), ntpath.abspath(ntpath.normpath(p)) for p in [u'test_srcl.txt', 'test_srcl.txt', u'.', '.'] in your case? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 19:29:12 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 May 2014 17:29:12 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1401038952.3.0.245941922332.issue8743@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 19:51:59 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 May 2014 17:51:59 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1401040319.47.0.885145727343.issue8743@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Adding tests for non-set iterables as suggested by Serhiy. ---------- Added file: http://bugs.python.org/file35353/fix_set_abc2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 20:32:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 18:32:19 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <1401042739.21.0.842608296537.issue10203@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 20:50:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 18:50:33 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <1401043833.51.0.86143118663.issue10203@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Perhaps it is worth to add a test for negative indices (valid (-1) and invalid (< -length)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 20:59:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 18:59:05 +0000 Subject: [issue21560] gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string In-Reply-To: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za> Message-ID: <1401044345.97.0.430228502688.issue21560@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 21:08:06 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 25 May 2014 19:08:06 +0000 Subject: [issue21575] list.sort() should show arguments in tutorial In-Reply-To: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za> Message-ID: <1401044886.44.0.578770652665.issue21575@psf.upfronthosting.co.za> ?ric Araujo added the comment: I assume it is on purpose that the tutorial does not show all methods with all their arguments. It could overwhelm readers with too much information, and would also duplicate the full doc that?s in the reference. A link from this tutorial page to the list reference (and maybe the sorting howto) could be a good addition. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 21:34:41 2014 From: report at bugs.python.org (Damian) Date: Sun, 25 May 2014 19:34:41 +0000 Subject: [issue12972] Color prompt + readline In-Reply-To: <1315927772.69.0.871921956001.issue12972@psf.upfronthosting.co.za> Message-ID: <1401046481.43.0.312235474677.issue12972@psf.upfronthosting.co.za> Damian added the comment: Just a quick comment that I ran into this again, but turns out that it's not an issue with python. Rather, this is a quirk with how readline works... https://stackoverflow.com/questions/9468435/look-how-to-fix-column-calculation-in-python-readline-if-use-color-prompt Color prompts need to be wrapped by RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 21:37:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 May 2014 19:37:12 +0000 Subject: [issue21493] Add test for ntpath.expanduser In-Reply-To: <1399975960.27.0.370722329224.issue21493@psf.upfronthosting.co.za> Message-ID: <1401046632.79.0.0092426563111.issue21493@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. But most other tests in this file use tester() to test str and bytes. And it would be good to test multicomponent arguments (e.g. '~test\\foo\\bar' and '~/foo/bar'). ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 21:41:28 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 25 May 2014 19:41:28 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <1401046888.34.0.127920586334.issue10203@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Thanks. Here's the updated patch. It supports negative indeces (my previous patch didn't do that). ---------- Added file: http://bugs.python.org/file35354/issue10203.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 22:01:23 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 25 May 2014 20:01:23 +0000 Subject: [issue21493] Add test for ntpath.expanduser In-Reply-To: <1399975960.27.0.370722329224.issue21493@psf.upfronthosting.co.za> Message-ID: <1401048083.19.0.497399719842.issue21493@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Here's an updated patch. ---------- Added file: http://bugs.python.org/file35355/issue21493.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 23:26:32 2014 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 25 May 2014 21:26:32 +0000 Subject: [issue18622] reset_mock on mock created by mock_open causes infinite recursion In-Reply-To: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za> Message-ID: <1401053192.24.0.758823862204.issue18622@psf.upfronthosting.co.za> Florent Xicluna added the comment: I've been bitten by this issue with a custom psycopg2 mock. >>> cur = mock.Mock() >>> >>> cur.connection.cursor.return_value = cur >>> cur.reset_mock() RuntimeError: maximum recursion depth exceeded the patch looks ok, except the mix of tab and spaces :-) ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 25 23:45:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 25 May 2014 21:45:08 +0000 Subject: [issue12972] Color prompt + readline In-Reply-To: <1315927772.69.0.871921956001.issue12972@psf.upfronthosting.co.za> Message-ID: <1401054308.0.0.741604551846.issue12972@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks for the followup. This should be useful info for anyone who finds this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 00:44:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 25 May 2014 22:44:45 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <3gcGhr6q44z7LlF@mail.python.org> Roundup Robot added the comment: New changeset d7eea8f608c2 by Terry Jan Reedy in branch '3.4': Issue #21477: Idle htest: modify run; add more tests. http://hg.python.org/cpython/rev/d7eea8f608c2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 00:47:33 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 25 May 2014 22:47:33 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401058053.89.0.752978055927.issue21477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 0. I pushed a slight revision of the patch. See 2) for the main change. In htest, I also did 3), corrected some line spacing issues, and changed 'focussing' to the US spelling 'focusing'. A tested 2.7 version of the attached, htest-25052014-34.py, is top priority. 1. parent.mainloop() - ClassBrower, EditorWindow, PathBrowser: since mainloop is already running, this should have no effect. I had no problem with closing of child window closing parent. Perhaps there is an OS difference, perhaps related to the focus difference. Or this might even be a tk or tkinter bug in not masking OS differences. If the line is necessary for #nix, it seems harmless on Windows. 2. Let us remember that the purpose of htest is to test what cannot be sensibly tested with automated unittests. That includes the visual look of widgets and some behaviors that either cannot be automatically tested or that we currently do not know how to test. The format paragragh methods and functions are well tested, better than a human will, in the current test_formatgraph unittest. I removed this part of the patch. (But see 5. below about moving it.) When I wrote the notes that became htest.txt, a year ago, I had not written any tests other than for calltips. I listed almost all the files that had existig tests. So don't add new tests not mentioned in htest.txt without discussion. And question the existing and proposed tests listed there. For instance, I presume we can use the Text.tag_methods to write an automated ColorDelegator test that checks that tagged words are as expected and that colors match the configured values. We can leave the current test (with patch), until replaced. 3. Class/PathBrowser: not only does double clicking 'not work', it causes an exception to be printed to console or shell, but which seems to be ignored as test continues. The exception is either like this Exception in Tkinter callback Traceback (most recent call last): File "F:\Python\dev\4\py34\lib\idlelib\run.py", line 121, in main seq, request = rpc.request_queue.get(block=True, timeout=0.05) File "F:\Python\dev\4\py34\lib\queue.py", line 175, in get raise Empty queue.Empty During handling of the above exception, another exception occurred: Traceback (most recent call last): File "F:\Python\dev\4\py34\lib\tkinter\__init__.py", line 1487, in __call__ return self.func(*args) File "F:\Python\dev\4\py34\lib\idlelib\TreeWidget.py", line 122, in flip self.item.OnDoubleClick() File "F:\Python\dev\4\py34\Lib\idlelib\ClassBrowser.py", line 174, in OnDoubleClick edit = PyShell.flist.open(self.file) AttributeError: 'module' object has no attribute 'flist' or with just the AttributeError. Unless and until we can suppress the traceback, the message should be changed from 'not work' to 'will print a traceback for an exception that is ignored'. [done] 4. Please comment on point 4 in msg219055. 5. Possible followup idea: By reviewing and running tests for classes I have not previously paid attention to, I learned something about them. After htest is done, polish the test explanations as appropriate to explain each class to someone not familiar with it. Revise run() to start as follows: def run(*tests, *, test_list=None): if test_list is None: test_list = [] Add htour.py (for instance) with a callable and spec for non-htested classes (and behaviors). It could begin like this --- from idlelib.idle_test.htest import run def _format_paragraph(parent): ...(such as in current patch) _format_paragraph_spec = ...(such as in current patch) tour_list = [(_format_paragraph, _format_paragraph_spec),] # automate by scanning globals for callables and grabbing matching specs run(test_list=tour_list) --- This should be a separate issue that follows on this one. If you feel like expanding the above to a preliminary patch, go ahead. 6. For me, many of the htest geometry increments are too small. Example: root.geometry("+%d+%d"%(x, y + 150) # percolator ---------- Added file: http://bugs.python.org/file35356/htest-25052014-34.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 00:51:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 25 May 2014 22:51:14 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401058274.78.0.874685490385.issue21477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yes, remove unscrollable (test2) tree widget (review response). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 00:58:32 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 May 2014 22:58:32 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1401058712.5.0.666210135626.issue8743@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Added tests that include the pure python sets.Set(). Only the binary or/and/sub/xor methods are tested. The comparison operators were designed to only interact with their own kind. A comment from Tim Peters explains the decision raise a TypeError instead of returning NotImplemented (it has unfortunate interactions with cmp()). At any rate, nothing good would come from changing that design decision now, so I'm leaving it alone to fade peacefully into oblivion. ---------- Added file: http://bugs.python.org/file35357/fix_set_abc3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 01:24:47 2014 From: report at bugs.python.org (beta) Date: Sun, 25 May 2014 23:24:47 +0000 Subject: [issue21576] Overwritten (custom) uuid inside dictionary In-Reply-To: <1401025009.13.0.783307535122.issue21576@psf.upfronthosting.co.za> Message-ID: <1401060287.6.0.539764959751.issue21576@psf.upfronthosting.co.za> beta added the comment: import copy ship = {'Name': 'Slagschip', 'Blocks': 5} shipData = copy.deepcopy(ship) # needed, otherwise linked-object shipData['uuid'] = Id # unique Id Is this the correct Python behavior? ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 01:55:48 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 May 2014 23:55:48 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1401062148.42.0.883204184893.issue13355@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Stefan. For us, I don't see the need to add a restriction, possibly breaking code that is currently working fine (with high < mode <= low). The important part is that we now allow low==mode or high==mode and have a smooth transition to low==high. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 02:28:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 00:28:47 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <3gcK0s41DZz7LlF@mail.python.org> Roundup Robot added the comment: New changeset 7ea6c8eb91e2 by Raymond Hettinger in branch '3.4': Issue 13355: Make random.triangular degrade gracefully when low == high. http://hg.python.org/cpython/rev/7ea6c8eb91e2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 02:40:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 00:40:33 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <3gcKGS4fNSz7LlF@mail.python.org> Roundup Robot added the comment: New changeset 6dc5c4ba7544 by Raymond Hettinger in branch '2.7': Issue 13355: Make random.triangular degrade gracefully when low == high. http://hg.python.org/cpython/rev/6dc5c4ba7544 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 02:41:32 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 00:41:32 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1401064892.09.0.769892769388.issue13355@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 03:06:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 01:06:35 +0000 Subject: [issue21558] Fix a typo in the contextlib docs In-Reply-To: <1400817528.11.0.0994185866372.issue21558@psf.upfronthosting.co.za> Message-ID: <3gcKrV4Wsxz7LjR@mail.python.org> Roundup Robot added the comment: New changeset ebeade01bd8e by Raymond Hettinger in branch '3.4': Issue 21558: Fix a typo in the contextlib docs http://hg.python.org/cpython/rev/ebeade01bd8e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 03:07:27 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 01:07:27 +0000 Subject: [issue21558] Fix a typo in the contextlib docs In-Reply-To: <1400817528.11.0.0994185866372.issue21558@psf.upfronthosting.co.za> Message-ID: <1401066447.46.0.592658314597.issue21558@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +ncoghlan resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 03:22:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 01:22:44 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <3gcLC758h6z7LjX@mail.python.org> Roundup Robot added the comment: New changeset 7574f94b1068 by Raymond Hettinger in branch 'default': Issue 21137: Better repr for threading.Lock() http://hg.python.org/cpython/rev/7574f94b1068 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 03:23:20 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 01:23:20 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1401067400.6.0.87892388345.issue21137@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Berker. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 03:28:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 01:28:50 +0000 Subject: [issue15246] Line coverage for collectionts.abc.Set In-Reply-To: <1341367326.82.0.277858740936.issue15246@psf.upfronthosting.co.za> Message-ID: <3gcLL92k3dz7Lk2@mail.python.org> Roundup Robot added the comment: New changeset dc353953ce8b by Raymond Hettinger in branch 'default': Issue 15246: Improve test coverage for collections.abc.Set. (Contributed by James King). http://hg.python.org/cpython/rev/dc353953ce8b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 03:29:17 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 01:29:17 +0000 Subject: [issue15246] Line coverage for collectionts.abc.Set In-Reply-To: <1341367326.82.0.277858740936.issue15246@psf.upfronthosting.co.za> Message-ID: <1401067757.9.0.0066927435601.issue15246@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the patch. Nice work. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 03:41:28 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 01:41:28 +0000 Subject: [issue21575] list.sort() should show arguments in tutorial In-Reply-To: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za> Message-ID: <1401068488.3.0.517039614345.issue21575@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Is there a reason why we do not show the arguments there? It was likely an oversight. I think it should be updated so that people know the options are there. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 03:45:28 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 01:45:28 +0000 Subject: [issue21575] list.sort() should show arguments in tutorial In-Reply-To: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za> Message-ID: <1401068728.87.0.309002588009.issue21575@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file35358/sort_tut.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 04:58:56 2014 From: report at bugs.python.org (tholzer) Date: Mon, 26 May 2014 02:58:56 +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: <1401073136.61.0.421946592332.issue20611@psf.upfronthosting.co.za> tholzer added the comment: No problem, I've attached a patch for socket.py for Python 2.7.3. A few notes: getaddrinfo (and gethostbyname, etc.) are already immune to this bug, so I've just fixed the connect() call. The socket does need to be closed after EINTR, otherwise a EINPROGRESS might get returned on subsequent connect() calls. ---------- Added file: http://bugs.python.org/file35359/socket_2.7.3_eintr_patch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 05:42:02 2014 From: report at bugs.python.org (tholzer) Date: Mon, 26 May 2014 03:42:02 +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: <1401075722.98.0.0675258539887.issue20611@psf.upfronthosting.co.za> tholzer added the comment: I've also attached a potential patch for the C module Modules/socketmodule.c inside internal_connect(). A few notes: This seems to work both without time-out and with time-out sockets (non-blocking). One concern would be a signal storm prolonging the operation beyond the time-out. Should we keep track of the actual time taken in this loop and check it against the 'timeout' parameter ? Also, I don't think we can call PyErr_CheckSignals() in this context. Does this need to happen at all ? ---------- Added file: http://bugs.python.org/file35360/socketmodule_2.7.6_eintr_patch.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 05:48:52 2014 From: report at bugs.python.org (tholzer) Date: Mon, 26 May 2014 03:48:52 +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: <1401076132.94.0.394891703421.issue20611@psf.upfronthosting.co.za> Changes by tholzer : Added file: http://bugs.python.org/file35361/socketmodule_2.7.6_eintr_patch.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 05:49:15 2014 From: report at bugs.python.org (tholzer) Date: Mon, 26 May 2014 03:49:15 +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: <1401076155.09.0.782899160648.issue20611@psf.upfronthosting.co.za> Changes by tholzer : Removed file: http://bugs.python.org/file35360/socketmodule_2.7.6_eintr_patch.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 05:51:43 2014 From: report at bugs.python.org (Jeff Quast) Date: Mon, 26 May 2014 03:51:43 +0000 Subject: [issue20664] _findLib_crle and _get_soname broken on latest SunOS 5.11 In-Reply-To: <1392668740.39.0.330236898998.issue20664@psf.upfronthosting.co.za> Message-ID: <1401076303.4.0.554634157753.issue20664@psf.upfronthosting.co.za> Jeff Quast added the comment: Submitting fix to fallback to alternate '/usr/bin/dump' path, confirmed using SmartOS. As for the issues writing to /lib and /usr/lib from a zone, and the request for "An environment variable .. to override this functionality." I have to disagree: crle(1) already provides facilities to add additional paths. For example, to add `/usr/local/lib' to your dynamic library path, You would simply run, `crle -l /usr/local/lib -u'. I don't *that* belongs in python. ---------- keywords: +patch nosy: +jquast Added file: http://bugs.python.org/file35362/opensolaris-ctypes-python-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 05:52:08 2014 From: report at bugs.python.org (Jeff Quast) Date: Mon, 26 May 2014 03:52:08 +0000 Subject: [issue20664] _findLib_crle and _get_soname broken on latest SunOS 5.11 In-Reply-To: <1392668740.39.0.330236898998.issue20664@psf.upfronthosting.co.za> Message-ID: <1401076328.82.0.622656659217.issue20664@psf.upfronthosting.co.za> Changes by Jeff Quast : Added file: http://bugs.python.org/file35363/opensolaris-ctypes-python-3.x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 06:24:31 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Mon, 26 May 2014 04:24:31 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401078271.47.0.970915028863.issue21477@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file35364/htest-25052014-27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 06:27:28 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 26 May 2014 04:27:28 +0000 Subject: [issue21577] Help for ImportError should show a more useful signature. Message-ID: <1401078448.87.0.796266837202.issue21577@psf.upfronthosting.co.za> New submission from Eric Snow: Currently: __init__(self, /, *args, **kwargs) Proposed: __init__(self, /, *args, name=None, path=None, **kwargs) Even that is still a little vague, but at least it doesn't gloss over the kwonly args added in 3.3. ---------- components: Interpreter Core messages: 219124 nosy: brett.cannon, eric.snow priority: normal severity: normal stage: needs patch status: open title: Help for ImportError should show a more useful signature. type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 06:31:35 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 26 May 2014 04:31:35 +0000 Subject: [issue21578] Misleading error message when ImportError called with invalid keyword args Message-ID: <1401078695.26.0.813929580296.issue21578@psf.upfronthosting.co.za> New submission from Eric Snow: >>> ImportError(spam='spam') Traceback (most recent call last): File "", line 1, in TypeError: ImportError does not take keyword arguments However, it *does* take keyword arguments: >>> ImportError(name='spam', path='spam') ImportError() ---------- components: Interpreter Core messages: 219125 nosy: brett.cannon, eric.snow priority: normal severity: normal stage: needs patch status: open title: Misleading error message when ImportError called with invalid keyword args type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 06:55:06 2014 From: report at bugs.python.org (Matt Bachmann) Date: Mon, 26 May 2014 04:55:06 +0000 Subject: [issue21343] os.path.relpath returns inconsistent types In-Reply-To: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za> Message-ID: <1401080106.52.0.387580984378.issue21343@psf.upfronthosting.co.za> Matt Bachmann added the comment: Looking into the project im working on I discovered why relpath was acting strangely. It is because the project mocks get_cwd but not get_cwdu. Your request helped me track that down :-) So that is not an issue. However, the issue described in the original ticket definitely happens in a clean python shell. I still think it is bad that the method sometimes returns str and sometimes returns unicode, but I see your point that ultimately the byte strings that do come out of here coerce into unicode cleanly. Thanks for working though this with me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 06:58:45 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 26 May 2014 04:58:45 +0000 Subject: [issue15767] add ModuleNotFoundError In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za> Message-ID: <1401080325.02.0.319140236138.issue15767@psf.upfronthosting.co.za> Eric Snow added the comment: Any chance we could revive ModuleNotFoundError? It's nice to be able to distinguish between the failure to *find* the module during import from other uses of ImportError. I'd definitely expect it to work the way Guido explained. Basically only importlib._bootstrap._find_and_load_unlocked() would raise ModuleNotFoundError (when _find_spec() returns None). I've found the exception to be very useful while working on the importlib backport (https://bitbucket.org/ericsnowcurrently/importlib2). My desire for adding ModuleNotFoundError is unrelated to its internal use in importlib that motivated the original request (see msg182332). Here's the signature: ModuleNotFoundError(*args, name=None), inherits from ImportError For reference, here's ImportError: ImportError(*args, name=None, path=None) ModuleNotFoundError would need to be exposed somewhere sensible since once people see in tracebacks they'll want to catch it. :) I'd expect that to be either in builtins or as importlib.ModuleNotFoundError. We may be able to get away with not adding it to builtins, but maybe it would still make sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 07:02:11 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 05:02:11 +0000 Subject: [issue16774] Additional recipes for itertools docs In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za> Message-ID: <1401080531.08.0.0328235022015.issue16774@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 07:04:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 05:04:09 +0000 Subject: [issue16774] Additional recipes for itertools docs In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za> Message-ID: <3gcR6c4By8z7LjR@mail.python.org> Roundup Robot added the comment: New changeset 2781fb146f4a by Raymond Hettinger in branch 'default': Issue 16774: Add a new itertools recipe (suggested by Alexey Kachayev). http://hg.python.org/cpython/rev/2781fb146f4a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 07:05:16 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 05:05:16 +0000 Subject: [issue16774] Additional recipes for itertools docs In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za> Message-ID: <1401080716.73.0.684821105533.issue16774@psf.upfronthosting.co.za> Raymond Hettinger added the comment: In the end, I decided to add a variant of take_last(). Thank you for the suggestion. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 07:13:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 05:13:49 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <3gcRKm1x03zSby@mail.python.org> Roundup Robot added the comment: New changeset 3615cdb3b86d by Raymond Hettinger in branch '2.7': Issue 8743: Improve interoperability between sets and the collections.Set abstract base class. http://hg.python.org/cpython/rev/3615cdb3b86d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 07:20:35 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 26 May 2014 05:20:35 +0000 Subject: [issue21558] Fix a typo in the contextlib docs In-Reply-To: <1400817528.11.0.0994185866372.issue21558@psf.upfronthosting.co.za> Message-ID: <1401081635.93.0.0566533260501.issue21558@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks Raymond, will do. ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 07:21:13 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 26 May 2014 05:21:13 +0000 Subject: [issue21137] Better repr for threading.Lock() In-Reply-To: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za> Message-ID: <1401081673.4.0.252324340255.issue21137@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 07:47:59 2014 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 26 May 2014 05:47:59 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work Message-ID: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> New submission from ???? ?????????: Suppose code: ===================================== import os import tempfile want_to_replace = 'zxc.dat' tmpdir=os.path.dirname(os.path.realpath(want_to_replace)) with tempfile.NamedTemporaryFile(dir=tmpdir) as fff: # do somewhat with fff here... and then: fff.flush() os.fdatasync(fff) os.rename(fff.name, want_to_replace) fff.delete = False ===================================== In python 3.3 and lower that works FINE. In Python 3.4 the fff._closer attribute was introduced, so fff.close=False stopped to work. I think this is major loss of functionality. The "close" attribute was not marked as private, so may be used in past. ---------- components: Library (Lib) messages: 219132 nosy: mmarkk priority: normal severity: normal status: open title: Python 3.4: tempfile.close attribute does not work type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 07:52:24 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 26 May 2014 05:52:24 +0000 Subject: [issue21580] PhotoImage(data=...) apparently has to be UTF-8 or Base-64 encoded Message-ID: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za> New submission from Martin Panter: At the bottom of the ?tkinter? doc page it mentions the ?data? option is available. However I was unable to get it to work well when passing a plain bytes() string in. It seems the bytes() string gets interpreted as UTF-8 somewhere along the line, although the underlying TCL library apparenly handles byte strings fine itself. Passing binary GIF and PNG data in Python would usually produce strange exceptions, crashes, and blank images for me. I found this message with a simple patch which might be useful, though I?m not familiar with the code involved to understand the implications: https://mail.python.org/pipermail/tkinter-discuss/2012-April/003108.html Even if that fix is not appropriate, can I suggest adding to the documentation to say the data should be encoded with one of these options that seem to work? The Base-64 one is probably better. PhotoImage(data=data.decode("latin-1).encode("utf-8")) PhotoImage(data=base64.encodebytes(data)) ---------- assignee: docs at python components: Documentation, Tkinter messages: 219133 nosy: docs at python, vadmium priority: normal severity: normal status: open title: PhotoImage(data=...) apparently has to be UTF-8 or Base-64 encoded versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 07:55:03 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 26 May 2014 05:55:03 +0000 Subject: [issue21436] Consider leaving importlib.abc.Loader.load_module() In-Reply-To: <1399291208.69.0.802643633069.issue21436@psf.upfronthosting.co.za> Message-ID: <1401083703.43.0.890176684957.issue21436@psf.upfronthosting.co.za> Eric Snow added the comment: I'd rather see something like "load_from_spec()" added to importlib.util, a la issue #21235. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 08:03:12 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 26 May 2014 06:03:12 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401084192.06.0.295933086623.issue20383@psf.upfronthosting.co.za> Eric Snow added the comment: Okay, I didn't read closely enough. :) It may be worth updating the title. FWIW, the name "module_from_spec" confused me at first because my brain interpreted that as "load_from_spec". Keeping the name and purpose more focused might be helpful. I have comments below to that effect. If your proposed change still makes sense, could we keep it simpler for now? Something like this: # in importlib.util def module_from_spec(spec, module=None): """...""" methods = _bootstrap._SpecMethods(spec) if module is None: return methods.create() else: methods.init_module_attrs(methods) return module Keeping the 2 methods on _SpecMethods is helpful for the PEP 406 (ImportEngine) superseder that I still want to get back to for 3.5. :) ---------------------------------- > This serves two purposes. One is that it abstracts the > loader.create_module() dance out so that's no longer a worry. I'm not sure what dance you mean here and what the worry is. > But more crucially it also means that if you have the function > create the module for you then it will be returned with all of > its attributes set without having to worry about forgetting that > step. So we would discourage calling ModuleType directly and encourage the use of a function in importlib.util that is equivalent to _SpecMethods.create(). That sounds good to me. The use case for creating module objects directly is a pretty advanced one, but having a public API for that would still be good. >From this point of view I'd expect it to just look like this: def new_module(spec): return _SpecMethods(spec).create() or given what I expect is the common use case currently: def new_module(name, loader): spec = spec_from_loader(name, loader) return _SpecMethods(spec).create() or together: def new_module(spec_or_name, /, loader=None): if isinstance(spec_or_name, str): name = spec_or_name if loader is None: raise TypeError('missing loader') spec = spec_from_loader(name, loader) else: if loader is not None: raise TypeError('got unexpected keyword argument "loader"') spec = spec_or_name return _SpecMethods(spec).create() To kill 2 birds with 1 stone, you could even make that the new signature of ModuleType(), which would just do the equivalent under the hood. That way people keep using the same API that they already are (no need to communicate a new one to them), but they still get the appropriate attributes set properly. > The module argument is just for convenience in those > instances where you truly only want to override the module > creation dance for some reason and really just want the > attribute setting bit. Perhaps it would be better to have a separate function for that (equivalent to just _SpecMethods.init_module_attrs()). However, isn't that an even more uncommon use case outside of the import system itself? > About the only other thing I can think of that people might > still want is something like `importlib.util.load(spec)` I agree it's somewhat orthogonal. I'll address comments to issue #21235. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 08:14:40 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 26 May 2014 06:14:40 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1401084880.24.0.748292383152.issue21235@psf.upfronthosting.co.za> Eric Snow added the comment: How about this replacement for direct use of Loader.load_module(): # in importlib.util def load(spec_or_name, /, **kwargs): # or "load_from_spec" if isinstance(spec_or_name, str): name = spec_or_name if not kwargs: raise TypeError('missing loader') spec = spec_from_loader(name, **kwargs) else: if kwargs: raise TypeError('got unexpected keyword arguments') spec = spec_or_name return _SpecMethods(spec).load() (See a similar proposal for new_module() in msg219135, issue #20383). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 08:16:01 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 26 May 2014 06:16:01 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1401084961.04.0.942748386715.issue21579@psf.upfronthosting.co.za> Berker Peksag added the comment: See issue 18879 for more information about the change. ---------- nosy: +berker.peksag, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 08:27:57 2014 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 26 May 2014 06:27:57 +0000 Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variable In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za> Message-ID: <1401085677.9.0.297040792631.issue18879@psf.upfronthosting.co.za> ???? ????????? added the comment: Is issue 21579 fixed in that bug? too many letters..sorry... ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 09:14:22 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 07:14:22 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <3gcV0s34kmz7LjV@mail.python.org> Roundup Robot added the comment: New changeset cd8b5b5b6356 by Raymond Hettinger in branch '3.4': Issue 8743: Improve interoperability between sets and the collections.Set abstract base class. http://hg.python.org/cpython/rev/cd8b5b5b6356 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 09:40:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 07:40:36 +0000 Subject: [issue21481] Argpase Namespace object methods __eq__ and __ne__ raise TypeError when comparing to None In-Reply-To: <1399910902.34.0.399069985077.issue21481@psf.upfronthosting.co.za> Message-ID: <3gcVb760L3zQfV@mail.python.org> Roundup Robot added the comment: New changeset ba84d1e9a742 by Raymond Hettinger in branch '2.7': Issue #21481: Teach argparse equality tests to return NotImplemented when comparing to unknown types. http://hg.python.org/cpython/rev/ba84d1e9a742 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 09:44:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 07:44:43 +0000 Subject: [issue21481] Argpase Namespace object methods __eq__ and __ne__ raise TypeError when comparing to None In-Reply-To: <1399910902.34.0.399069985077.issue21481@psf.upfronthosting.co.za> Message-ID: <3gcVgt4Tb4zSjF@mail.python.org> Roundup Robot added the comment: New changeset 510c8dc38749 by Raymond Hettinger in branch '3.4': Issue #21481: Teach argparse equality tests to return NotImplemented when comparing to unknown types. http://hg.python.org/cpython/rev/510c8dc38749 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 09:45:10 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 07:45:10 +0000 Subject: [issue21481] Argpase Namespace object methods __eq__ and __ne__ raise TypeError when comparing to None In-Reply-To: <1399910902.34.0.399069985077.issue21481@psf.upfronthosting.co.za> Message-ID: <1401090310.33.0.134916632762.issue21481@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 09:46:41 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 07:46:41 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1401090401.33.0.457708448986.issue13212@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> bob.ippolito nosy: +bob.ippolito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:00:19 2014 From: report at bugs.python.org (Bob Ippolito) Date: Mon, 26 May 2014 08:00:19 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1401091219.06.0.764471856331.issue13212@psf.upfronthosting.co.za> Bob Ippolito added the comment: As Chris Rebert mentioned, the JSON standards have adopted this (unsurprising) behavior. Ruby hasn't, and I doubt Crockford has, but I think they're in the minority at this point. JavaScript's own JSON implementation works the same way json/simplejson does. > JSON.parse(JSON.stringify('yay')) "yay" At best, I think it's probably worth a mention in the documentation, but not worth changing any code over. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:01:54 2014 From: report at bugs.python.org (Bob Ippolito) Date: Mon, 26 May 2014 08:01:54 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1401091314.56.0.443280453015.issue13212@psf.upfronthosting.co.za> Bob Ippolito added the comment: In other words, I would consider this to be fixed by the documentation change made elsewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:02:33 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 08:02:33 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1401091353.55.0.537442358157.issue8743@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:15:16 2014 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Mon, 26 May 2014 08:15:16 +0000 Subject: [issue21575] list.sort() should show arguments in tutorial In-Reply-To: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za> Message-ID: <1401092116.59.0.361728616759.issue21575@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: I have updated the patch with a cross-reference to the sorted() built-in, which explains the arguments. W.r.t. to ?ric's suggestion: the sorted() doc refers to the sorting howto in the wiki. Now everything is connected. ---------- Added file: http://bugs.python.org/file35365/sort_tut_02.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:16:00 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 May 2014 08:16:00 +0000 Subject: [issue21575] list.sort() should show arguments in tutorial In-Reply-To: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za> Message-ID: <1401092160.23.0.436957134828.issue21575@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:20:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 08:20:56 +0000 Subject: [issue21580] PhotoImage(data=...) apparently has to be UTF-8 or Base-64 encoded In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za> Message-ID: <1401092456.28.0.235577884957.issue21580@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +gpolo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:22:40 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 26 May 2014 08:22:40 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1401092560.98.0.975033544189.issue21579@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:30:03 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 26 May 2014 08:30:03 +0000 Subject: [issue20664] _findLib_crle and _get_soname broken on latest SunOS 5.11 In-Reply-To: <1392668740.39.0.330236898998.issue20664@psf.upfronthosting.co.za> Message-ID: <1401093003.65.0.148893596596.issue20664@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:31:07 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 26 May 2014 08:31:07 +0000 Subject: [issue21560] gzip.write changes trailer ISIZE field before type checking - corrupted gz file after trying to write string In-Reply-To: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za> Message-ID: <1401093067.35.0.825135036297.issue21560@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:35:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 08:35:02 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1401093302.4.0.00199615580392.issue13355@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note the catch on 2.7. triangular(10, 10.0) returns 10.0, but triangular(10, 10.0, 10.0) returns 10. If then you divide by the result... I proposed change "return low" to "return low + 0.0". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:46:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 08:46:22 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1401093982.85.0.152717254703.issue21579@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In any case this trick didn't work on Windows. And it can't work on Linux too when use new O_TMPFILE flag (issue21515). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:47:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 08:47:12 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1401094032.74.0.610889931602.issue21579@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 10:57:46 2014 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 26 May 2014 08:57:46 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1401094666.86.0.409388075233.issue21579@psf.upfronthosting.co.za> ???? ????????? added the comment: Yes, but O_TMPFILE should be set ONLY when used with TemporaryFile, not with NamedTemporaryFile. My problem refer only NamedTemporaryFile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 11:33:05 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 26 May 2014 09:33:05 +0000 Subject: [issue21578] Misleading error message when ImportError called with invalid keyword args In-Reply-To: <1401078695.26.0.813929580296.issue21578@psf.upfronthosting.co.za> Message-ID: <1401096785.22.0.32393587788.issue21578@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch with a simple test case. ---------- keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review Added file: http://bugs.python.org/file35366/issue21578.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 12:10:52 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 26 May 2014 10:10:52 +0000 Subject: [issue21054] Improve indexing of syntax symbols In-Reply-To: <1395703578.43.0.642568496743.issue21054@psf.upfronthosting.co.za> Message-ID: <1401099052.42.0.909008827386.issue21054@psf.upfronthosting.co.za> Ezio Melotti added the comment: All the current dependences are currently fixed. Are you planning to add more in the future or can this issue be closed? ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 12:17:35 2014 From: report at bugs.python.org (Sunny K) Date: Mon, 26 May 2014 10:17:35 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1401099455.17.0.615903118396.issue1820@psf.upfronthosting.co.za> Sunny K added the comment: Hi Stefan, I've added a new patch which only adds _fields, combining parts from my earlier patch and Andrew's (his patch does not account for visible unnamed fields). ---------- Added file: http://bugs.python.org/file35367/structseq_fields.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 12:19:31 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 26 May 2014 10:19:31 +0000 Subject: [issue21072] Python docs and downloads not available for Egypt In-Reply-To: <1395872823.34.0.614292416852.issue21072@psf.upfronthosting.co.za> Message-ID: <1401099571.68.0.807863623569.issue21072@psf.upfronthosting.co.za> Ezio Melotti added the comment: IIUC there was a similar issue from China, and on the old site we fixed it by adding http://legacy.python.org/getit/. I don't know what was made to this page to make it work from China and if it still exists on the new website, but maybe the same trick could be used in this case as well? Leo, can you check if the link I posted above works for you and try http://legacy.python.org/download/ as well? ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 12:24:07 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 26 May 2014 10:24:07 +0000 Subject: [issue21077] Turtle Circle Speed 0 In-Reply-To: <1395936990.77.0.953738655575.issue21077@psf.upfronthosting.co.za> Message-ID: <1401099847.45.0.316189387093.issue21077@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 12:28:18 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 26 May 2014 10:28:18 +0000 Subject: [issue21310] ResourceWarning when open() fails with io.UnsupportedOperation: File or stream is not seekable In-Reply-To: <1397877829.49.0.0015217310404.issue21310@psf.upfronthosting.co.za> Message-ID: <1401100098.13.0.16454048521.issue21310@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +haypo, pitrou, serhiy.storchaka type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 12:37:09 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 26 May 2014 10:37:09 +0000 Subject: [issue21429] Input.output error with multiprocessing In-Reply-To: <1399220691.1.0.523621963732.issue21429@psf.upfronthosting.co.za> Message-ID: <1401100629.77.0.630564001228.issue21429@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can you provide more information about the error (e.g. the relevant piece of code where the error generates, if you can reproduce it every time or if it's sporadic, a minimal piece of code that can reproduce the same issue, etc.)? I would also suggest to report this to the supybot issue tracker if the affected code is not specific to Limnoria. ---------- nosy: +ezio.melotti type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 12:38:37 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 26 May 2014 10:38:37 +0000 Subject: [issue21434] python -3 documentation is outdated In-Reply-To: <1399281658.38.0.402381658113.issue21434@psf.upfronthosting.co.za> Message-ID: <1401100716.99.0.824491108286.issue21434@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +terry.reedy stage: patch review -> commit review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 12:40:50 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 26 May 2014 10:40:50 +0000 Subject: [issue21445] Some asserts in test_filecmp have the wrong messages In-Reply-To: <1399362194.49.0.4974401647.issue21445@psf.upfronthosting.co.za> Message-ID: <1401100850.96.0.49264235453.issue21445@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 13:02:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 11:02:06 +0000 Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile? In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za> Message-ID: <1401102126.96.0.866163578912.issue21515@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 13:26:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 11:26:41 +0000 Subject: [issue21310] ResourceWarning when open() fails with io.UnsupportedOperation: File or stream is not seekable In-Reply-To: <1397877829.49.0.0015217310404.issue21310@psf.upfronthosting.co.za> Message-ID: <1401103601.05.0.205713593291.issue21310@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue20074. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:20:19 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 26 May 2014 14:20:19 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1401114019.15.0.364569858201.issue19980@psf.upfronthosting.co.za> Mark Lawrence added the comment: Anybody? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:27:38 2014 From: report at bugs.python.org (Leo Butcher) Date: Mon, 26 May 2014 14:27:38 +0000 Subject: [issue21072] Python docs and downloads not available for Egypt In-Reply-To: <1401099571.68.0.807863623569.issue21072@psf.upfronthosting.co.za> Message-ID: Leo Butcher added the comment: Still not working, they both timeout also the docs subdomain is the same On Mon, May 26, 2014 at 12:19 PM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > IIUC there was a similar issue from China, and on the old site we fixed it > by adding http://legacy.python.org/getit/. > I don't know what was made to this page to make it work from China and if > it still exists on the new website, but maybe the same trick could be used > in this case as well? > > Leo, can you check if the link I posted above works for you and try > http://legacy.python.org/download/ as well? > > ---------- > nosy: +ezio.melotti > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:37:02 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 26 May 2014 14:37:02 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401115022.93.0.790521202511.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: First, about breaking up _SpecMethods: that was entirely on purpose. =) I honestly have found _SpecMethods a bit of a pain to work with because at every place where I have a spec object and I need to operate on it I end up having to wrap it and then call a method on it instead of simply calling a function (it also doesn't help that spec methods is structured as a collection of methods which can just operate as functions since they almost all have ``spec = self.spec`` at the beginning). I get you're hoping to make PEP 406 happen, but it actually needs to happen first. =) And as I said, the methods are essentially functions anyway so undoing any unraveling I may do won't be difficult to revert if PEP 406 actually comes about. IOW _SpecMethods feels like OOP just 'cause and not for any design reasons; it's been making my eye twitch when I look at that class. Second, the dance that an advanced user has to worry about is "does create_module exist, and if so did it not return None and if any of that is not true then return what types.ModuleType would give you" is not exactly one line of code ATM. There is no reason to not abstract that out to do the right thing in the face of a loader. Third, yes this would be to encourage people not to directly call types.ModuleType but call the utility function instead. Fourth, I purposefully didn't bifurcate the code of types.ModuleType based on the type of what the first argument was. At best you could change it to take an optional spec as a second argument and use that, but if you did that and the name doesn't match the spec then what? I'm not going to promote passing in a loader because spec_from_loader() cannot necessarily glean all of the same information a hand-crafted spec could if the loader doesn't have every possible introspection method defined (I'm calling "explicit is better than implicit" to back that up). I also don't think any type should depend on importlib having been previously loaded to properly function if it isn't strictly required, so the code would have to be written entirely in C which I just don't want to write. =) Since it's going beyond simply constructing a new module but also initializing it I think it's fine to keeping it in importlib.util which also makes it all more discoverable for people than having to realize that types.ModuleType is the place to go to create a module and get its attributes initialized. Fifth, fair enough on not needing the module argument. I will refactor the code for internal use of attribute initialization in testing and leave it at that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:37:20 2014 From: report at bugs.python.org (Ian Cordasco) Date: Mon, 26 May 2014 14:37:20 +0000 Subject: [issue10510] distutils upload/register should use CRLF in HTTP requests In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za> Message-ID: <1401115039.98.0.916458531294.issue10510@psf.upfronthosting.co.za> Ian Cordasco added the comment: Per discussion on twitter (https://twitter.com/merwok_/status/468518605135835136) I'm bumping this to make sure it's merged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:49:25 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 26 May 2014 14:49:25 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1401115765.15.0.387583348734.issue21235@psf.upfronthosting.co.za> Brett Cannon added the comment: I think that's the wrong abstraction(it would be fine in a third-party library, though, that's trying to smooth over 3.3->3.4 transitions). Since importlib.util.find_spec() always returns a spec, then you want something more like:: def load(spec): loader = spec.loader if hasattr(loader, 'exec_module'): module = importlib.util.whatever_issue_20383_leads_to() loader.exec_module(module) return module else: loader.load_module(spec.name) return sys.modules[spec.name] Since this is Python 3.5 code we are talking about you don't have to worry about the find_loader/find_module case as find_spec wraps both of those and normalizes it all to just using specs. You could even tweak it to pass the module in explicitly and in the load_module branch make sure that the module is placed in sys.modules first so it essentially becomes a reload (but as both know that's not exactly the same nor pleasant in certain cases so probably best not exposed that way =). If this exists in importlib.util then you make import_module() be (essentially):: def import_module(name, package): fullname = resolve_name(name, package) spec = find_spec(fullname) return load(spec) ---------- dependencies: +Add a keyword-only spec argument to types.ModuleType _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:51:37 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 26 May 2014 14:51:37 +0000 Subject: [issue21581] Consider dropping importlib.abc.Loader.create_module() Message-ID: <1401115897.78.0.38815519118.issue21581@psf.upfronthosting.co.za> New submission from Brett Cannon: As Armin Ronacher pointed out, it's a bit odd having the importlib.abc.Loader ABC have a method whose default does nothing and having the method itself be entirely optional. Might as well just drop it from the ABC and instead just make sure that create_module() is documented appropriately (it's such an advanced use case it might also simplify things to not have it in the typical user's face). ---------- components: Library (Lib) messages: 219159 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Consider dropping importlib.abc.Loader.create_module() type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:51:45 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 26 May 2014 14:51:45 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1401115905.93.0.757427823025.issue21235@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Consider dropping importlib.abc.Loader.create_module() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:52:25 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 26 May 2014 14:52:25 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1401115945.19.0.457439394231.issue21235@psf.upfronthosting.co.za> Brett Cannon added the comment: Opened issue #21581 to discuss Armin's point about importlib.abc.Loader.create_module() being there but not being much use since the method is entirely optional. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:53:28 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Mon, 26 May 2014 14:53:28 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401116008.65.0.827932281005.issue21477@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Summary for htest-26052014-34.diff and htest-26052014-27.diff 1. Adds htest for ReplaceDialog and SearchDialog 2. Removes the two canvases in TreeWidget as per code review comment. Now there is only a single ScrollableCanvas 3. Some text changes in spec dict messages The corresponding 27 patch is to be applied on top of htest-25052014-27.diff. Apart, 1. Wrt point 4 in msg219055, I think wrapper functions are required along with creating a new root. It ensures the parent dialog is not destroyed, even 'accidently' and across different OS. About the concern that clicking '[Next]' does not destroy the child: We could have the following line in wrapper function(which creates a new root)- parent.child = root and, in the "next()" in run(): try: root.child.destroy() except AttributeError: pass To make things more readable, we could perhaps change the 'root' in run() to 'parent' and ensure consistency. With this, clicking '[Next]' destroys the child, before moving onto the next htest. A drawback with this approach would be that, we would need to create a wrapper function for those tests which currently dont have one(See: configNameDialog, configHelpSource, GetKeysDialog etc.) 2. Htest's for GrepDialog, outputwindow, configDialog and Filelist are not progressing because of assert statements in macosxsupport.py. I do not know the reasoning behind the assert statement either. Neither do I know how to 'ignore' it. One way I found out is using the -O flag, but it is not pragmatic. Another way is to have a macosxsupport._tk_type = "other" in the respective wrapper function. But I do not know the effect of such a statement in a OSX environment. If someone with a OSX environment wants to volunteer, please try running Lib/idlelib/configDialog.py with and without the insertion macosxsupport._tk_type = "other". With the insertion, the configDialog works on a Linux gnome environment and doesn't without it. Funnily enough, the configDialog works as-is in Win7 which I tried on a VM. One way would be to insert the above statment only if its a *nix environment. ---------- Added file: http://bugs.python.org/file35368/htest-26052014-34.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:54:02 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Mon, 26 May 2014 14:54:02 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401116042.63.0.96428087735.issue21477@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file35369/htest-26052014-27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 16:59:46 2014 From: report at bugs.python.org (diana) Date: Mon, 26 May 2014 14:59:46 +0000 Subject: [issue21582] use the support.catpured_stdout/stderr context managers - test_asyncore Message-ID: <1401116386.06.0.283011419126.issue21582@psf.upfronthosting.co.za> New submission from diana: Updated test_asyncore to use the support.catpured_stdout/stderr context managers rather than try/finally blocks. ---------- components: Tests files: use_support_captured_test_asyncore.patch keywords: patch messages: 219162 nosy: diana priority: normal severity: normal status: open title: use the support.catpured_stdout/stderr context managers - test_asyncore versions: Python 3.5 Added file: http://bugs.python.org/file35370/use_support_captured_test_asyncore.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 17:01:11 2014 From: report at bugs.python.org (diana) Date: Mon, 26 May 2014 15:01:11 +0000 Subject: [issue21582] use support.catpured context managers - test_asyncore In-Reply-To: <1401116386.06.0.283011419126.issue21582@psf.upfronthosting.co.za> Message-ID: <1401116471.19.0.01714465175.issue21582@psf.upfronthosting.co.za> Changes by diana : ---------- title: use the support.catpured_stdout/stderr context managers - test_asyncore -> use support.catpured context managers - test_asyncore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 18:15:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 26 May 2014 16:15:43 +0000 Subject: [issue21054] Improve indexing of syntax symbols In-Reply-To: <1395703578.43.0.642568496743.issue21054@psf.upfronthosting.co.za> Message-ID: <1401120943.92.0.428508172448.issue21054@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I plan to add more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 19:05:26 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 26 May 2014 17:05:26 +0000 Subject: [issue21434] python -3 documentation is outdated In-Reply-To: <1399281658.38.0.402381658113.issue21434@psf.upfronthosting.co.za> Message-ID: <1401123926.03.0.791916019449.issue21434@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This is documentation for the 2.7 '-3' command line option, which I presume has not changed at least since 2.7.0, rather than for 2to3, which has changed in different 3.x releases. If I am correct, the list of things -3 warns about has not changed. It might be more appropriate to rewrite the intro sentence to something like "Warn about Python 3.x incompatibilities which were not fixed by the original version of :ref:`2to3 <2to3-reference>`." Benjamin, what do you think? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 19:35:10 2014 From: report at bugs.python.org (diana) Date: Mon, 26 May 2014 17:35:10 +0000 Subject: [issue21583] use support.catpured_stderr context manager - test_logging Message-ID: <1401125710.75.0.955154923721.issue21583@psf.upfronthosting.co.za> New submission from diana: - Updated test_asyncore to use the support.catpured_stderr context manager - Removed unused imports ---------- components: Tests files: use_support_captured_stderr_test_logging.patch keywords: patch messages: 219165 nosy: diana priority: normal severity: normal status: open title: use support.catpured_stderr context manager - test_logging versions: Python 3.5 Added file: http://bugs.python.org/file35371/use_support_captured_stderr_test_logging.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 19:45:52 2014 From: report at bugs.python.org (Jessica McKellar) Date: Mon, 26 May 2014 17:45:52 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1401126352.26.0.0358724381507.issue19980@psf.upfronthosting.co.za> Jessica McKellar added the comment: @BreamoreBoy, thanks for following up on this! > I propose the following. help('') returns help on strings in the same way that help([]) and help({}) returns help on lists and dicts respectively, Sounds good. > further help(''.method) returns help on the string method or an attribute error, so this appears to me consistent. This already happens (which I think you are saying, but it's a bit confusing in reading your message which functionality you are proposing to add and which functionality you are restating that already exists). > help('doh') returns enhanced output along the lines Terry suggested in msg206157. Sounds good. > help('module') gives the path to the module as well as the help output, if any, as I think this could be useful in cases where you're looking for problems and have a stdlib module masked by a file of your own. I think you are stating the current functionality? > Note that I've tried looking at the test code and it didn't make much sense to me, pointers welcome. Do you have specific questions? Terry suggests that help() tests for functionality using pydoc live in test_pydoc.py, and that help() tests for functionality not using pydoc live in test_site.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 19:48:10 2014 From: report at bugs.python.org (diana) Date: Mon, 26 May 2014 17:48:10 +0000 Subject: [issue21583] use support.catpured_stderr context manager - test_logging In-Reply-To: <1401125710.75.0.955154923721.issue21583@psf.upfronthosting.co.za> Message-ID: <1401126490.92.0.363513052365.issue21583@psf.upfronthosting.co.za> diana added the comment: oops, typo: - Updated test_logging (not test_asyncore) to use the support.catpured_stderr context manager ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 20:29:15 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 26 May 2014 18:29:15 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1401115022.93.0.790521202511.issue20383@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: tl;dr I'm okay with pulling the functions out of _SpecMethods (and dropping the class) but I'd prefer the distinct functions continue to exist as they are. Also, I still think updating the ModuleType signature is the way to go (given current use cases). :) > First, about breaking up _SpecMethods: that was entirely on purpose. =) ... IOW _SpecMethods feels like OOP just 'cause and not for any design reasons; it's been making my eye twitch when I look at that class. Keep in mind that _SpecMethods is basically a proxy for ModuleSpec that has the methods that ModuleSpec had originally. That was the simplest way to not expose the methods on every module.__spec__. If we didn't care about exposing more API on __spec__, we'd have it all on ModuleSpec. I still wonder if we could have used subclassing instead of proxying (obviating the pain points we've run into) and used a SimpleModuleSpec for __spec__ and ModuleSpec for all other APIs (or ModuleSpec/FullModuleSpec): SimpleModuleSpec # What currently is ModuleSpec. ModuleSpec(SimpleModuleSpec) # Basically this is _SpecMethods. Regardless, _SpecMethods made sense at the time and I still find it helpful to have the functions grouped into a distinct namespace. That said, I agree that it's a pain. :) I'm okay with ditching the class, but would rather we kept the distinct functions that exist now. > Second, the dance that an advanced user has to worry about is "does create_module exist, and if so did it not return None and if any of that is not true then return what types.ModuleType would give you" is not exactly one line of code ATM. There is no reason to not abstract that out to do the right thing in the face of a loader. That's what _SpecMethods.create() already does for you. > Third, yes this would be to encourage people not to directly call types.ModuleType but call the utility function instead. I'm totally on board. :) > Fourth, I purposefully didn't bifurcate the code of types.ModuleType based on the type of what the first argument was. At best you could change it to take an optional spec as a second argument and use that, but if you did that and the name doesn't match the spec then what? I see your point. I just see the trade-offs a little differently. :) This is all about finding the best way of eliminating the problem of people not setting the module attributes properly (and making it easier to do so). From my perspective: * Currently every module must have a spec (and consequently a loader). * Updating the ModuleType signature will encourage setting the spec, etc. better than a separate factory would. If every module must have a spec, then I'd expect that to be part of the ModuleType signature. I can see the use case (though uncommon) for directly creating a module object. Is there a use case for creating a module without a spec? Either way, if it's important enough to ensure that people set the module attrs properly, then we should consider having direct instantiation of ModuleType() issue a warning when created without setting the spec, etc. Regarding the second point, with a separate factory function, people will have to learn about the function and then switch to using it before they get the benefit. Backward compatibility for an updated signature shouldn't be too hard: currently: ModuleType(name, doc=None) updated: ModuleType(name_or_spec, doc=None, *, loader=None) actual: ModuleType(name_or_spec=None, /, name=None, doc=None, *, loader=None) > I'm not going to promote passing in a loader because spec_from_loader() cannot necessarily glean all of the same information a hand-crafted spec could if the loader doesn't have every possible introspection method defined (I'm calling "explicit is better than implicit" to back that up). Regardless of new signature or new factory, I still think the signature should allow for passing in a spec or passing in a name/loader pair. Passing name/loader instead of spec is a convenience for what I anticipate is the most common use case now: given a loader, create a new module. For comparison: mod = new_module(name, loader=loader) vs. spec = spec_from_loader(name, loader=loader) mod = new_module(spec) I'll argue that we can accommodate the common case and if that doesn't work, they can still create their own spec. If this were new functionality then I'd agree with you. > I also don't think any type should depend on importlib having been previously loaded to properly function if it isn't strictly required, so the code would have to be written entirely in C which I just don't want to write. =) If it's in _bootstrap then it's already available. No C required. :) > Since it's going beyond simply constructing a new module but also initializing it I think it's fine to keeping it in importlib.util which also makes it all more discoverable for people than having to realize that types.ModuleType is the place to go to create a module and get its attributes initialized. It seems to me that people haven't been thinking about initializing a module's attributes. This is popping up now because people are starting to take their advanced importing use cases to Python 3 (which I take as a very good sign!). So ModuleType seems like the right place for me. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 20:45:04 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 26 May 2014 18:45:04 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1401129904.94.0.730102111459.issue21235@psf.upfronthosting.co.za> Eric Snow added the comment: I'm just considering current usage: mod = loader.load_module(name) becomes: spec = spec_from_loader(name, loader) mod = load(spec) vs. mod = load(name, loader=loader) I guess I'm torn. I like how the former forces you to consider specs when dealing with the import system. On the other hand, I don't want it to be annoying to have to move to this brave new world (that's exactly why we toned down the deprecations). And on the third hand, perhaps it would be annoying to just a handful of people so we shouldn't sweat it. So if we end up simplifying, load() could look like this: def load(spec): # or "load_from_spec" return _SpecMethods(spec).load() It already takes care of everything we need, including the import lock stuff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 21:22:22 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 26 May 2014 19:22:22 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401132142.73.0.926333872026.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: I think we view the fundamentals of built-in types differently as well. =) A module instance can exist without a spec no problem. As long as you don't pass that module instance through some chunk of code that expects __spec__ -- or any other attribute for that matter -- then the instance is fine and operates as expected. There is nothing fundamental to module objects which dictates any real attribute is set (not even __name__). If I wanted to construct a module from scratch and just wanted a blank module object which I assign attributes to manually then I can do that, and that's what types.ModuleType provides (sans its module name requirement in its constructor which really isn't necessary either). This also means that tying the functionality of the module type to importlib is the wrong direction to have the dependency. That means I refuse to add code to the module type which requires that importlib have been imported and set up. Just think of someone who embeds Python and has no use for imports; why should the module type then be broken because of that choice? That means anything done to the module type needs to be done entirely in C. But luckily for you bytes broke the glass ceiling of pivoting on a type's constructor based on its input type (it is the only one, though). So I'll let go on arguing that one. =) Anyway, I'll think about changing types.ModuleType, but having to implement init_module_attrs() in pure C and then exposing it in _imp just doesn't sound like much fun. And as for your preference that "the distinct functions continue to exist as they are", are you saying you want the code duplicated or that you just don't like me merging the create() and init_module_attrs() functions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 21:38:24 2014 From: report at bugs.python.org (Jessica McKellar) Date: Mon, 26 May 2014 19:38:24 +0000 Subject: [issue3015] tkinter with wantobjects=False has been broken for some time In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za> Message-ID: <1401133104.92.0.730064816277.issue3015@psf.upfronthosting.co.za> Jessica McKellar added the comment: @Lita.Cho: (I'd like to this on the web but the links are still broken after the website port) if you search for `wantobjects` in `Doc/whatsnew/2.3.rst`, there's a description of why the parameter was added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 21:39:05 2014 From: report at bugs.python.org (Robert Snoeberger) Date: Mon, 26 May 2014 19:39:05 +0000 Subject: [issue21563] Segv during call to builtin_execfile in application embedding Python interpreter. In-Reply-To: <1400871636.0.0.265957974694.issue21563@psf.upfronthosting.co.za> Message-ID: <1401133145.92.0.409212838957.issue21563@psf.upfronthosting.co.za> Robert Snoeberger added the comment: I created a patch to add a check for NULL globals or locals. The file execfile.patch is attached. A system error is set with the message "globals and locals cannot be NULL" if either is NULL. An open question I have is how should I create tests for this patch? I verified that the crash doesn't occur when I run the attached execfile_invoke.c program. ---------- keywords: +patch Added file: http://bugs.python.org/file35372/execfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 21:52:48 2014 From: report at bugs.python.org (Eric Snow) Date: Mon, 26 May 2014 19:52:48 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401133968.38.0.0500205393112.issue20383@psf.upfronthosting.co.za> Eric Snow added the comment: I give. :) You've made good points about builtins and C implementations. Also, thinking about issue #21235 has changed my perspective a bit. As to _SpecMethods, I mean just drop the class and turn the methods into functions: * name: -> _spec_ (or whatever) * signature: self -> spec * body: self.spec -> spec * body: self. -> method (there is interplay between methods) And then importlib.util.new_module: def new_module(spec): return _bootstrap._spec_create(spec) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 22:05:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 20:05:45 +0000 Subject: [issue21584] Unraised overflow error in sqlite3.Row indexing Message-ID: <1401134745.16.0.844451458443.issue21584@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When integer index overflows C long, sqlite3.Row.__getitem__() doesn't raise an exception. Instead overflow exception is raised later. >>> import sqlite3 >>> con = sqlite3.connect(":memory:") >>> con.row_factory = sqlite3.Row >>> row = con.execute("select 1 as a, 2 as b").fetchone() >>> row[2**1000] 2 >>> OverflowError: Python int too large to convert to C long ---------- assignee: serhiy.storchaka components: Extension Modules keywords: easy messages: 219174 nosy: Claudiu.Popa, ghaering, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Unraised overflow error in sqlite3.Row indexing type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 22:20:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 20:20:53 +0000 Subject: [issue21584] Unraised overflow error in sqlite3.Row indexing In-Reply-To: <1401134745.16.0.844451458443.issue21584@psf.upfronthosting.co.za> Message-ID: <1401135653.24.0.520189206555.issue21584@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Actually this happens after applying the patch from issue10203. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 22:23:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 20:23:47 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <1401135827.95.0.209020733585.issue10203@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks good, but there is one detail. Whith issue10203.patch when integer index overflows C long, sqlite3.Row.__getitem__() doesn't raise an exception. Instead overflow exception is raised later. >>> import sqlite3 >>> con = sqlite3.connect(":memory:") >>> con.row_factory = sqlite3.Row >>> row = con.execute("select 1 as a, 2 as b").fetchone() >>> row[2**1000] 2 >>> OverflowError: Python int too large to convert to C long ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 22:47:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 20:47:08 +0000 Subject: [issue3015] tkinter with wantobjects=False has been broken for some time In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za> Message-ID: <1401137228.71.0.0110989353291.issue3015@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now I think we shouldn't deprecate and remove wantobjects=False. Tkinter was partially broken with wantobjects=False, on other hand, it was partially broken with wantobjects=True. Many bugs was fixed last months, all tests now work with wantobjects=False, and I hope Tkinter now correctly supports both mode. Besides using in old third-party code, this parameter is very helpful for testing. Tcl/Tk changes internal details from release to release, so when in one release Tk function returns list or integer, in other release it can return special object ('dict' or 'pixel'). Tkinter should be more stable against changing of return type, and wantobjects=False helps in detecting some such cases. I propose to close this issue as fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 22:53:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 May 2014 20:53:59 +0000 Subject: [issue21585] Run Tkinter tests with wantobjects=False Message-ID: <1401137639.41.0.24885887123.issue21585@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The wantobjects attribute of the tkinter module is True by default, and all Tkinter tests run with wantobjects=True. We need to test Tkinter with wantobjects=False too. All Tkinter tests should be ran twice, in both mode. ---------- components: Tests, Tkinter messages: 219178 nosy: gpolo, serhiy.storchaka, zach.ware priority: normal severity: normal stage: needs patch status: open title: Run Tkinter tests with wantobjects=False type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 22:58:26 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Mon, 26 May 2014 20:58:26 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <1401137906.14.0.596564851718.issue10203@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Thanks. Here's a fix. ---------- Added file: http://bugs.python.org/file35373/issue10203_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 23:28:06 2014 From: report at bugs.python.org (Torsten Landschoff) Date: Mon, 26 May 2014 21:28:06 +0000 Subject: [issue21505] cx_freeze multiprocessing bug In-Reply-To: <1400047714.39.0.600066285372.issue21505@psf.upfronthosting.co.za> Message-ID: <1401139686.49.0.517111455175.issue21505@psf.upfronthosting.co.za> Torsten Landschoff added the comment: That sounds like you did not initialize the freeze support of the multiprocessing module: https://docs.python.org/3/library/multiprocessing.html#multiprocessing.freeze_support Basically, you need to add the following code to your main, before anything else: from multiprocessing import freeze_support freeze_support() Interestingly, the documentation states that starting a new Process instance without freeze_support will raise a RuntimeError. Maybe the detection of that situation failed in your case? ---------- nosy: +torsten _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 26 23:35:00 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 26 May 2014 21:35:00 +0000 Subject: [issue21536] extension built with a shared python cannot be loaded with a static python In-Reply-To: <1400525402.57.0.75792320709.issue21536@psf.upfronthosting.co.za> Message-ID: <1401140100.14.0.0670624962396.issue21536@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > PHP might be close to our case: Debian includes a libphp5.so > (in /usr/lib/php5), yet neither /usr/bin/php5 nor the Apache libphp5.so > link against it, and all the PHP modules (in > /usr/lib/php5/20100525+lfs/) don't link with the shared library - > on Debian. I wonder how it is on systems that actually use the PHP > shared library. Regardless of libphp5.so, the modules in /usr/lib/php5/20100525 don't link against /usr/lib/apache2/modules/libphp5.so, though the latter is obviously able to load those modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 00:01:47 2014 From: report at bugs.python.org (Daniel Fisher) Date: Mon, 26 May 2014 22:01:47 +0000 Subject: [issue21586] Minor error "How To Sockets" Message-ID: <1401141706.98.0.611136529928.issue21586@psf.upfronthosting.co.za> New submission from Daniel Fisher: There is a minor error in the documentation page "https://docs.python.org/2/howto/sockets.html" Line 31 of the sample program of the program listed under "Using a Socket" reads chucks.append(chunk). It should read chunks.append(chunk). Without this minor correction, the sample program will not run. ---------- assignee: docs at python components: Documentation messages: 219182 nosy: Daniel.Fisher, docs at python priority: normal severity: normal status: open title: Minor error "How To Sockets" versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 00:07:26 2014 From: report at bugs.python.org (Joshua Landau) Date: Mon, 26 May 2014 22:07:26 +0000 Subject: [issue21587] Tabs in source Message-ID: <1401142046.69.0.792186764708.issue21587@psf.upfronthosting.co.za> New submission from Joshua Landau: There are tabs in the source: http://hg.python.org/cpython/file/5c8d71516235/Include/listobject.h#l49 I don't really know, but this seems like a release blocker to me ;). ---------- messages: 219183 nosy: Joshua.Landau priority: normal severity: normal status: open title: Tabs in source _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 00:11:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 22:11:21 +0000 Subject: [issue21586] Minor error "How To Sockets" In-Reply-To: <1401141706.98.0.611136529928.issue21586@psf.upfronthosting.co.za> Message-ID: <3gcsvs0j9Dz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset dc2a123d538a by Benjamin Peterson in branch '2.7': fix typo in variable name (closes #21586) http://hg.python.org/cpython/rev/dc2a123d538a New changeset 62eb4828fdf7 by Benjamin Peterson in branch '3.4': fix typo in variable name (closes #21586) http://hg.python.org/cpython/rev/62eb4828fdf7 New changeset 487e8e071551 by Benjamin Peterson in branch 'default': merge 3.4 (#21586) http://hg.python.org/cpython/rev/487e8e071551 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 00:12:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 22:12:49 +0000 Subject: [issue21587] Tabs in source In-Reply-To: <1401142046.69.0.792186764708.issue21587@psf.upfronthosting.co.za> Message-ID: <3gcsxY1mGZz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset e38e30b0d017 by Benjamin Peterson in branch '2.7': remove tab (closes #21587) http://hg.python.org/cpython/rev/e38e30b0d017 New changeset f7075eb04b75 by Benjamin Peterson in branch '3.4': remove tab (closes #21587) http://hg.python.org/cpython/rev/f7075eb04b75 New changeset 37166903007e by Benjamin Peterson in branch 'default': merge 3.4 (#21587) http://hg.python.org/cpython/rev/37166903007e ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 00:24:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 26 May 2014 22:24:49 +0000 Subject: [issue21536] extension built with a shared python cannot be loaded with a static python In-Reply-To: <1400525402.57.0.75792320709.issue21536@psf.upfronthosting.co.za> Message-ID: <1401143089.28.0.741973174716.issue21536@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm, apparently the -l flag was added in #832799, for a rather complicated case where the interpreter is linked with a library dlopened by an embedding application (I suppose for some kind of plugin system). The OP there also mentions RTLD_GLOBAL as a workaround (or perhaps the right way of achieving the desired effect). (also, the OP didn't mention why he used a shared library build, instead of linking Python statically with the dlopened library) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 00:39:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 May 2014 22:39:03 +0000 Subject: [issue21434] python -3 documentation is outdated In-Reply-To: <1399281658.38.0.402381658113.issue21434@psf.upfronthosting.co.za> Message-ID: <3gctWp3nHRz7Lrq@mail.python.org> Roundup Robot added the comment: New changeset ae2e8bfda7d7 by Benjamin Peterson in branch '2.7': remove list of example incompatibilities (closes #21434) http://hg.python.org/cpython/rev/ae2e8bfda7d7 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 00:55:31 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 26 May 2014 22:55:31 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1401144931.72.0.321871695873.issue21304@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Looks like there's a debugging turd in the test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 01:47:33 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 26 May 2014 23:47:33 +0000 Subject: [issue21581] Consider dropping importlib.abc.Loader.create_module() In-Reply-To: <1401115897.78.0.38815519118.issue21581@psf.upfronthosting.co.za> Message-ID: <1401148053.16.0.0292259991261.issue21581@psf.upfronthosting.co.za> Nick Coghlan added the comment: I suggest waiting until we update the C extension import system before making a final decision - that was the concrete use case for the feature, so it may become less confusing once that is added. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 02:42:54 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 27 May 2014 00:42:54 +0000 Subject: [issue21581] Consider dropping importlib.abc.Loader.create_module() In-Reply-To: <1401115897.78.0.38815519118.issue21581@psf.upfronthosting.co.za> Message-ID: <1401151374.21.0.169090911807.issue21581@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 03:28:00 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 27 May 2014 01:28:00 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401154080.97.0.308792055461.issue21477@psf.upfronthosting.co.za> Ned Deily added the comment: "2. Htest's for GrepDialog, outputwindow, configDialog and Filelist are not progressing because of assert statements in macosxsupport.py." The asserts are to ensure that none of the Tk-variant tests (isCarbonTk(), isCocoaTk(), et al) are called before _initializeTkVariantTests(root) has been called. And _initializeTkVariantTests can only be called after the initial calls to Tk have been made to create an initial window environment; it's only at that point that we can call Tk to enquire what variant of Tk we are running under (macosxSupport.py:28 and 33). _initializeTkVariantTests is called from macosxSupport.setupApp which is called from PyShell.main. This is fine for normal IDLE startup but it doesn't take into account the module level tests. Ideally, you do want to have run _initializeTkVariantTests before running GUI tests so that the behavior is properly conditioned on Tk variant type, so stubbing out the Tk type with macosxsupport._tk_type = "other' is not desirable. Perhaps the best way to deal with it is to create a common GUI test initialization function that is called by all of the GUI tests; the initialization function would be responsible for creating the Tk() root, calling _initializeTkVariantTests, and any other common steps that might arise. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 03:30:59 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 May 2014 01:30:59 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1401154259.04.0.396858870511.issue13742@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 03:31:45 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 May 2014 01:31:45 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1401154305.21.0.839943526919.issue13742@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file35374/keymerge.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 03:40:38 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 27 May 2014 01:40:38 +0000 Subject: [issue21467] IDLE icon not included in Windows installer In-Reply-To: <1399734291.3.0.637734238717.issue21467@psf.upfronthosting.co.za> Message-ID: <1401154838.04.0.78523212062.issue21467@psf.upfronthosting.co.za> R. David Murray added the comment: Issue number was mistyped in commit message. Commit was 730eeb10cd81. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 03:44:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 May 2014 01:44:12 +0000 Subject: [issue21575] list.sort() should show arguments in tutorial In-Reply-To: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za> Message-ID: <3gcydR09R6z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 1b96949bfc97 by Raymond Hettinger in branch 'default': Issue 21575: Show list.sort() arguments in the tutorial. http://hg.python.org/cpython/rev/1b96949bfc97 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 03:47:13 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 27 May 2014 01:47:13 +0000 Subject: [issue21468] NNTPLib connections become corrupt after long periods of activity In-Reply-To: <1399738998.21.0.285283528599.issue21468@psf.upfronthosting.co.za> Message-ID: <1401155233.1.0.917338578694.issue21468@psf.upfronthosting.co.za> R. David Murray added the comment: This is likely to be hard to reproduce (but perhaps someone will try). The best hope of getting it fixed is probably for you to investigate it yourself. Were you using ssl? Also, have you tried all the python versions you selected, and if so, which exact versions? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 03:49:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 May 2014 01:49:36 +0000 Subject: [issue21575] list.sort() should show arguments in tutorial In-Reply-To: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za> Message-ID: <3gcylg71yfz7Lkm@mail.python.org> Roundup Robot added the comment: New changeset be77b213ace0 by Raymond Hettinger in branch '2.7': Issue 21575: Show list.sort() arguments in the tutorial. http://hg.python.org/cpython/rev/be77b213ace0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 03:50:09 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 May 2014 01:50:09 +0000 Subject: [issue21575] list.sort() should show arguments in tutorial In-Reply-To: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za> Message-ID: <1401155409.55.0.715590912186.issue21575@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 03:57:38 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 May 2014 01:57:38 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1401155858.44.0.506516299174.issue17390@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I taught a python class this week with Python 2.7.7 and the learners found this change to be an impediment to usability. The filename and fullpath are the most important pieces of information in the title bar. They are now obscured by the version information which is somewhat unimportant (it has already been shown in the shell window and it is uncommon to run multiple versions of python using IDLE at the same time). Looking to Microsoft Excel and Word as comparative examples, they only show the document name. I conclude that this change should be reverted. For the time being, I can't continue to use IDLE in 2.7.7 to teach with. Not seeing the filename is especially important when many small windows are open (as they usually are during tdd and pdb sessions). ---------- nosy: +rhettinger priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 04:00:59 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 May 2014 02:00:59 +0000 Subject: [issue16638] support multi-line docstring signatures in IDLE calltips In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za> Message-ID: <1401156059.54.0.795611057637.issue16638@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Using Python 2.7.7 is a classroom setting revealed that this change is sometimes helpful and sometimes problematic. The big tip windows are VERY distracting during live coding demos and learners are reporting that it breaks their concentration. On the other hand, it is nice when a function is being encountered for the first time. I recommend providing a way to turn this feature off or limit it to displaying a given function in full no more than once. ---------- nosy: +rhettinger priority: normal -> high status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 05:06:58 2014 From: report at bugs.python.org (Alex Gaynor) Date: Tue, 27 May 2014 03:06:58 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <1401160018.91.0.454070613848.issue21304@psf.upfronthosting.co.za> Alex Gaynor added the comment: New patch removes the pdb nonsense in the test. ---------- Added file: http://bugs.python.org/file35375/pbkdf2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 07:09:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 27 May 2014 05:09:14 +0000 Subject: [issue21588] Idle: make editor title bar user configurable Message-ID: <1401167354.94.0.454935095166.issue21588@psf.upfronthosting.co.za> New submission from Terry J. Reedy: #17390 changes the title bars for (so far), shell and editor windows. While the editor window change helps me (for reasons given on the issue) and got no objection, before being pushed, from people nosy on the issue, others have found it objectionable in practice. Since no one solution satisfies all use cases, I propose to make the editor_title format user configurable. Since extra keywords are ignored, as in >>> "{short}".format(short='abc', long='xyz') 'abc' users can omit and arrange fields as they please in editor_title, which would then be called with all 3 variable field values. editor_title.format(short=short, long=long, version=version) I believe editor_title = '{short} - {long}' produces the previous title. That can be the default. A complication is that EditorWindow is also the base window class for Shell and Output windows. The title is calculated and set in a generic def saved_change_hook(self): # line 921 in 3.3 However, I believe that having non-empty short and long names is unique to editor windows (must recheck). If so. the format call could go in the second line of if short and long: title = short + " - " + long If untitled files were given a 'long' title of '(no file)', then they would be handled by the same clause. Explaining why a window is 'untitled' (no file to title it from) might be a benefit anyway. Some other possible solutions: Add parameter editor=False to saved_change_hook. Make EditorWindow a subclass of a generic Base Editor and move things specific to EditorWindow to the subclass. ---------- assignee: terry.reedy messages: 219198 nosy: terry.reedy priority: high severity: normal stage: needs patch status: open title: Idle: make editor title bar user configurable type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 07:11:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 27 May 2014 05:11:28 +0000 Subject: [issue21588] Idle: make editor title bar user configurable In-Reply-To: <1401167354.94.0.454935095166.issue21588@psf.upfronthosting.co.za> Message-ID: <1401167488.47.0.0173972211496.issue21588@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Another possibility is to separate the calculation of the title from setting it. This would make it much easier to unittest the calculation of the title. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 07:13:35 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 27 May 2014 05:13:35 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1401167615.72.0.169059216525.issue17390@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since no title format can satisfy everyone, I propose to make it user configurable. The default can be the old style. I opened #21588 for that and marked it high priority. ---------- priority: high -> normal versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 07:21:18 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 May 2014 05:21:18 +0000 Subject: [issue21439] Numerous minor issues in Language Reference In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> Message-ID: <3gd3Rx59r5z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 053ba3c2c190 by Raymond Hettinger in branch '3.4': Issue 21439: Minor issues in the reference manual. http://hg.python.org/cpython/rev/053ba3c2c190 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 07:22:37 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 May 2014 05:22:37 +0000 Subject: [issue21439] Numerous minor issues in Language Reference In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> Message-ID: <1401168157.55.0.213497507611.issue21439@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Most of the comments ended-up being useful and we applied. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 07:53:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 27 May 2014 05:53:14 +0000 Subject: [issue19903] Idle: Use inspect.signature for calltips In-Reply-To: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za> Message-ID: <1401169994.13.0.87333601247.issue19903@psf.upfronthosting.co.za> Terry J. Reedy added the comment: My understanding is that when a builtin is converted, a) the docstring signature disappears, and b) getfullargspec calls str(signature). I need to check what now happens with .getfullargspec version .signature for uncoverted builtins and if any changes should be made now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 08:05:53 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 27 May 2014 06:05:53 +0000 Subject: [issue16638] support multi-line docstring signatures in IDLE calltips In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za> Message-ID: <1401170753.13.0.599052756898.issue16638@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As I said previously, the only reason for the change was get all the docstring signature lines for builtins, after they were changed from 1 to many. I was not thrilled with having to do this. However, I felt that just presenting the arbitrary first of many lines was (and would be) a bug. For 3.4+, this is a temporary measure until Argument Clinic is applied to enough builtins to make it sensible to switch calltips to using str(inspect.signature). See #19903. When A.C. is applied to a function, the signature is no longer in the docstring, which instead starts with 'Returns (or whatever) just as for python-coded functions. Since A.C. and #19903 do not apply to 2.7, feel free to develop a more permanent alternative for 2.7. Perhaps just say and have a click on that line do the expansion instead of dismissing the box. If you do, I can check whether the A.C conversion has been slow enough to make temporary application to 3.4 worthwhile, or if *really* slow, to 3.5. The click idea, while still needed, might be combined with using .signature, but I have to recheck its current behavior. ---------- assignee: terry.reedy -> type: behavior -> enhancement versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 08:47:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 May 2014 06:47:56 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <3gd5Mw04kcz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 72a8a107eed1 by Terry Jan Reedy in branch '2.7': Issue #21477: Idle htest: modify run; add more tests. http://hg.python.org/cpython/rev/72a8a107eed1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 08:56:17 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 27 May 2014 06:56:17 +0000 Subject: [issue21498] configparser accepts keys beginning with comment_chars when writing In-Reply-To: <1399992449.17.0.699994077825.issue21498@psf.upfronthosting.co.za> Message-ID: <1401173777.24.0.397932692968.issue21498@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- assignee: -> lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 09:30:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 May 2014 07:30:06 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <1401175806.16.0.803544279214.issue10203@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Compare with tuple: >>> (1, 2)[2**1000] Traceback (most recent call last): File "", line 1, in IndexError: cannot fit 'int' into an index-sized integer ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 09:31:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 May 2014 07:31:54 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <3gd6Ld4D00z7LjW@mail.python.org> Roundup Robot added the comment: New changeset e770d8c4291c by Terry Jan Reedy in branch '2.7': Issue #21477: Add htests for Search and Replace dialogs. http://hg.python.org/cpython/rev/e770d8c4291c New changeset b8e4bb1e1090 by Terry Jan Reedy in branch '3.4': Issue #21477: Add htests for Search and Replace dialogs. http://hg.python.org/cpython/rev/b8e4bb1e1090 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 09:49:30 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 27 May 2014 07:49:30 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <1401176970.41.0.0953550707489.issue10203@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Thanks. Patch modified. ---------- Added file: http://bugs.python.org/file35376/issue10203_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 09:52:24 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 27 May 2014 07:52:24 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401177144.45.0.350067090841.issue21477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think it time to make running through all or just some of the tests more pleasant. If we reversed the order [next], [test name], test instruction, then [next] would not just up and down. If the window were set to a constant width, then it would not jump back and forth either. The width should be just wide enough for the longest lines we use in htest.py, or can we just allow them to wrap? To select just a one or a few tests (like just Search, Replace, and Tree for the 2605.. patch), a drop down list box would be nice. It could be beside the next box. With a constant width, there would be room. Doing the test reminded me that Search (find) and Replace have a severe bug on Windows of not highlighting the the found text while the box is still open. There was an issue where this was supposedly fixed, but it is not. Find is usable by closing the box and using cntl-G for find next. But this does not work for replace, making replace useless on windows unless one is really sure about replace all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 09:56:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 27 May 2014 07:56:07 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401177367.93.0.171928937727.issue21477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, I recently saw that some of the builtin extensions call macosxsupport. I though then that it would be better if such calls were somehow handled automatically. I have no idea how and when to make them and so I don't know if the existing calls are needed or if other calls should be added. So I like your idea. It seems like it should be a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 09:58:03 2014 From: report at bugs.python.org (James Meneghello) Date: Tue, 27 May 2014 07:58:03 +0000 Subject: [issue21468] NNTPLib connections become corrupt after long periods of activity In-Reply-To: <1399738998.21.0.285283528599.issue21468@psf.upfronthosting.co.za> Message-ID: <1401177483.56.0.435831880388.issue21468@psf.upfronthosting.co.za> James Meneghello added the comment: Yeah, I didn't have a lot of time so I chose just to work around it. When I get a chance I'll have a better look. Good point: I didn't think to try it with SSL off (SSL is enabled for all connections by default with this application). I'll test this and see if it still breaks. I tested it with 3.2.5, 3.3.2, 3.4.0a (was the latest at the time) on Ubuntu 64-bit. As said, didn't encounter the same problems with those versions on Windows 8 64-bit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 11:29:06 2014 From: report at bugs.python.org (Nikolay Bogoychev) Date: Tue, 27 May 2014 09:29:06 +0000 Subject: [issue16099] robotparser doesn't support request rate and crawl delay parameters In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za> Message-ID: <1401182946.88.0.543657391092.issue16099@psf.upfronthosting.co.za> Nikolay Bogoychev added the comment: Updated patch, all comments addressed, sorry for the 6 months delay. Please review ---------- Added file: http://bugs.python.org/file35377/robotparser_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 12:21:21 2014 From: report at bugs.python.org (Richard Marko) Date: Tue, 27 May 2014 10:21:21 +0000 Subject: [issue16446] pdb raises BdbQuit on 'quit' when started with set_trace In-Reply-To: <1352416193.43.0.475440625813.issue16446@psf.upfronthosting.co.za> Message-ID: <1401186081.81.0.27172373116.issue16446@psf.upfronthosting.co.za> Richard Marko added the comment: Would be nice to have this commited as without this change - if self.quitting: - return # None + if not self.botframe: + self.botframe = frame it's not possible to quit Bdb (and the code it's executing) as it just returns and doesn't raise BdbQuit. ---------- nosy: +rmarko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 12:26:34 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 27 May 2014 10:26:34 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1401186394.01.0.933569883102.issue14776@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: @jcea: So here is my proposal for dealing with this: let's take what I currently have (e.g. tracepoints for function entry/function exit) and extend my patch to also work with DTrace in a similar fashion. Then, when we have a working patch for both Systemtap and DTrace, we can start adding more tracepoints as needed/as we see fit. Sounds good? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 14:09:31 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 27 May 2014 12:09:31 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1401192571.08.0.373398507928.issue14776@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Could you possibly create a new issue and add me to its NOSY? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 14:22:37 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Tue, 27 May 2014 12:22:37 +0000 Subject: [issue21589] Use better idiom in unittest example Message-ID: <1401193357.7.0.00487480253361.issue21589@psf.upfronthosting.co.za> New submission from Claudiu.Popa: Hello. This patch proposes using `assertIn` in the first unittest example, instead of `assertTrue(x in seq)`. This is clearer and recommending it first is better for beginners. ---------- assignee: docs at python components: Documentation files: unittest_better_idiom.patch keywords: patch messages: 219216 nosy: Claudiu.Popa, docs at python priority: normal severity: normal status: open title: Use better idiom in unittest example type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35378/unittest_better_idiom.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 14:29:16 2014 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 27 May 2014 12:29:16 +0000 Subject: [issue21589] Use better idiom in unittest example In-Reply-To: <1401193357.7.0.00487480253361.issue21589@psf.upfronthosting.co.za> Message-ID: <1401193756.28.0.184869393125.issue21589@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is a duplicate of #11468. ---------- nosy: +ezio.melotti, rhettinger resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Improve unittest basic example in the doc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 14:55:10 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 May 2014 12:55:10 +0000 Subject: [issue11468] Improve unittest basic example in the doc In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za> Message-ID: <1401195310.91.0.392249180147.issue11468@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:04:30 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 27 May 2014 13:04:30 +0000 Subject: [issue20689] socket.AddressFamily is absent in html pydoc In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1401195870.9.0.843995781473.issue20689@psf.upfronthosting.co.za> Vajrasky Kok added the comment: I found the culprit. The AddressFamily is not registered in _socket module. I created a preliminary patch to show the culprit. ---------- keywords: +patch nosy: +vajrasky Added file: http://bugs.python.org/file35379/pydoc_display_AddressFamily.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:06:35 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 27 May 2014 13:06:35 +0000 Subject: [issue21590] Systemtap and DTrace support Message-ID: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> New submission from Bohuslav "Slavek" Kabrda: This is a tracking bug for development of combined systemtap and dtrace patch for Python. The separate patches were submitted at [1] (systemtap) and [2] (dtrace). Since it was agreed that it'd be best to merge the two patches to reuse as much code as possible between them, I'm opening this issue to track the progress and discuss possible improvements and suggestions. [1] http://bugs.python.org/issue14776 [2] http://bugs.python.org/issue13405 ---------- components: Interpreter Core messages: 219219 nosy: bkabrda, jcea priority: normal severity: normal status: open title: Systemtap and DTrace support type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:07:23 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 27 May 2014 13:07:23 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1401196043.93.0.384966611862.issue14776@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: I opened a bug for tracking progress of development of the combined dtrace and systemtap support: http://bugs.python.org/issue21590 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:07:46 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 27 May 2014 13:07:46 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1401196066.4.0.70337597563.issue13405@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: I opened a bug for tracking progress of development of the combined dtrace and systemtap support: http://bugs.python.org/issue21590 ---------- nosy: +bkabrda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:18:29 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 27 May 2014 13:18:29 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1401196709.65.0.0876294317022.issue21590@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Bohuslav, do you have Jabber/XMPP?. Mine is "jcea at jabber.org". This thing will require real time communication. I rather prefer XMPP/Jabber, but I could accept IRC :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:21:00 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 May 2014 13:21:00 +0000 Subject: [issue20689] socket.AddressFamily is absent in html pydoc In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1401196860.67.0.770487827269.issue20689@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: -berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:43:16 2014 From: report at bugs.python.org (Dave Malcolm) Date: Tue, 27 May 2014 13:43:16 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1401198196.96.0.199652690411.issue21590@psf.upfronthosting.co.za> Changes by Dave Malcolm : ---------- nosy: +dmalcolm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:46:39 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 27 May 2014 13:46:39 +0000 Subject: [issue21235] importlib's spec module create algorithm is not exposed In-Reply-To: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za> Message-ID: <1401198399.16.0.49363550541.issue21235@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm not torn so let that settle your torment. =) Considering we are talking about the standard library for a language that has a mantra of "explicit is better than implicit" I think worrying about an added line to very little code since so few people muck with this stuff is enough to not worry about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:51:56 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 27 May 2014 13:51:56 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401198716.14.0.454872927755.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: Why do you want a one-liner wrapper for the functions for the public API when they are exactly the same? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 15:56:19 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 27 May 2014 13:56:19 +0000 Subject: [issue21581] Consider dropping importlib.abc.Loader.create_module() In-Reply-To: <1401115897.78.0.38815519118.issue21581@psf.upfronthosting.co.za> Message-ID: <1401198979.82.0.69082814115.issue21581@psf.upfronthosting.co.za> Brett Cannon added the comment: This issue is not talking about dropping create_module() from the algorithm (I need it for the lazy loader), just from the ABC since it's a do-nothing implementation that doesn't have to be there. Otherwise it should be made a required method and possibly even not have its ``return None`` special-casing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 16:05:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 May 2014 14:05:30 +0000 Subject: [issue20689] socket.AddressFamily is absent in html pydoc In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1401199530.09.0.888083027237.issue20689@psf.upfronthosting.co.za> STINNER Victor added the comment: "I found the culprit. The AddressFamily is not registered in _socket module. I created a preliminary patch to show the culprit." That's not surprising, this type is created in socket (socket.py), not in _socket (the C module). Your patch is wrong. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 20:30:36 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 27 May 2014 18:30:36 +0000 Subject: [issue21539] pathlib's Path.mkdir() should allow for "mkdir -p" functionality In-Reply-To: <1400558036.91.0.766972225791.issue21539@psf.upfronthosting.co.za> Message-ID: <1401215436.75.0.736011996913.issue21539@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 20:32:01 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 27 May 2014 18:32:01 +0000 Subject: [issue21539] pathlib's Path.mkdir() should allow for "mkdir -p" functionality In-Reply-To: <1400558036.91.0.766972225791.issue21539@psf.upfronthosting.co.za> Message-ID: <1401215521.42.0.97346059002.issue21539@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I've just been writing some new code to use pathlib and ran into this one myself. An exist_ok=False is fine, although it's a slight shame that for backward compatibility we can't adopt os.makedirs() signature exactly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 18:26:18 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 27 May 2014 16:26:18 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401207978.03.0.232339333353.issue20383@psf.upfronthosting.co.za> Eric Snow added the comment: You're right that it doesn't have to be a one-line wrapper or anything more than an import-from in importlib.util. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 20:56:36 2014 From: report at bugs.python.org (Dominic Cerquetti) Date: Tue, 27 May 2014 18:56:36 +0000 Subject: [issue18807] Allow venv to create copies, even when symlinks are supported In-Reply-To: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za> Message-ID: <1401216996.2.0.74574809834.issue18807@psf.upfronthosting.co.za> Dominic Cerquetti added the comment: Requesting re-open of this issue, using --closes to force no symlinks to be created still results in venv trying to create symlinks. I'm using Python 3.4 with the following command inside a vagrant Ubuntu 14.04 virtualbox image. The folder is a SMB mount from a windows host, which does not allow symlinks. Expected behavior: os.symlink() is never called when you run: python3.4 -m venv --copies Actual behavior: os.symlink() is still called in a few places such as: http://hg.python.org/cpython/file/b8e4bb1e1090/Lib/venv/__init__.py line: 147 line: 215 I have a fix for line 215 that I'm testing now (basically just need to call copier() instead of os.symlink()). I don't want to mess with line 147 due to it being OSX specific and I have no way to test it. But in theory it should also just be a call to copier() ---------- nosy: +Dominic.Cerquetti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 21:09:11 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 May 2014 19:09:11 +0000 Subject: [issue21578] Misleading error message when ImportError called with invalid keyword args In-Reply-To: <1401078695.26.0.813929580296.issue21578@psf.upfronthosting.co.za> Message-ID: <1401217751.41.0.124253146218.issue21578@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review, Eric. Here's a new patch. ---------- Added file: http://bugs.python.org/file35381/issue21578_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 19:01:22 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 27 May 2014 17:01:22 +0000 Subject: [issue16446] pdb raises BdbQuit on 'quit' when started with set_trace In-Reply-To: <1352416193.43.0.475440625813.issue16446@psf.upfronthosting.co.za> Message-ID: <1401210082.02.0.128903710001.issue16446@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Yes the patch does change the semantics of the quit command: * no change when pdb is run as a script or with 'python -m pdb script_name'. As stated in the doc, the 'quit command': "Quit from the debugger. The program being executed is aborted." * but when a set_trace() breakpoint is inserted, 'quit' just terminates the debugger and the program continues its execution. It is the purpose of the patch to prevent an inconvenient crash with BdbQuit in that case. The idea is that the hard-coded breakpoint was set to investigate a local problem and one may want to let it run afterwards (for example to check its behavior after having changed some its internal state with pdb). Sorry, I should have documented that behavior change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 16:51:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 May 2014 14:51:19 +0000 Subject: [issue20689] socket.AddressFamily is absent in html pydoc In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1401202279.42.0.525438383291.issue20689@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, now I see what is wrong. Actually AddressFamily is missing in text output of pydoc too. Because "AddressFamily" is not included in the __all__ list. SocketType is included, but this is different SocketType, SocketType from _socket (see issue20386). Here is a patch which fixes this issue. ---------- assignee: -> serhiy.storchaka stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file35380/socket__all__.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 19:11:39 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 27 May 2014 17:11:39 +0000 Subject: [issue21439] Numerous minor issues in Language Reference In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> Message-ID: <1401210699.22.0.221011660757.issue21439@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: test needed -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 19:11:26 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 27 May 2014 17:11:26 +0000 Subject: [issue21439] Numerous minor issues in Language Reference In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za> Message-ID: <1401210686.41.0.411862522143.issue21439@psf.upfronthosting.co.za> Zachary Ware added the comment: A few comments on the committed patch. The quoted diff is trimmed to just the hunks I have comments on. On Tue, May 27, 2014 at 12:21 AM, raymond.hettinger wrote: > diff --git a/Doc/reference/compound_stmts.rst b/Doc/reference/compound_stmts.rst > --- a/Doc/reference/compound_stmts.rst > +++ b/Doc/reference/compound_stmts.rst > @@ -170,17 +170,25 @@ > A :keyword:`break` statement executed in the first suite terminates the loop > without executing the :keyword:`else` clause's suite. A :keyword:`continue` > statement executed in the first suite skips the rest of the suite and continues > -with the next item, or with the :keyword:`else` clause if there was no next > +with the next item, or with the :keyword:`else` clause if there is no next > item. > > -The suite may assign to the variable(s) in the target list; this does not affect > -the next item assigned to it. > +The for-loop makes assignments to the variables(s) in the target list. > +This overwrites all previous assignments to those variables including > +those made in the suite of the for-loop:: > + > + for i in range(10): > + print(i) > + i = 5 # this will not affect the for-loop > + # be i will be overwritten with the next Typo here, looks like an unfinished thought. "because" rather than "be"? > + # index in the range > + > > .. index:: > builtin: range > > Names in the target list are not deleted when the loop is finished, but if the > -sequence is empty, it will not have been assigned to at all by the loop. Hint: > +sequence is empty, they will not have been assigned to at all by the loop. Hint: > the built-in function :func:`range` returns an iterator of integers suitable to > emulate the effect of Pascal's ``for i := a to b do``; e.g., ``list(range(3))`` > returns the list ``[0, 1, 2]``. > diff --git a/Doc/reference/expressions.rst b/Doc/reference/expressions.rst > --- a/Doc/reference/expressions.rst > +++ b/Doc/reference/expressions.rst > @@ -520,11 +521,11 @@ > > The primary must evaluate to an object of a type that supports attribute > references, which most objects do. This object is then asked to produce the > -attribute whose name is the identifier (which can be customized by overriding > -the :meth:`__getattr__` method). If this attribute is not available, the > -exception :exc:`AttributeError` is raised. Otherwise, the type and value of the > -object produced is determined by the object. Multiple evaluations of the same > -attribute reference may yield different objects. > +attribute whose name is the identifier. This production can be customized by > +overriding the :meth:`__getattr__` method). If this attribute is not available, Orphaned ')' on this line. > +the exception :exc:`AttributeError` is raised. Otherwise, the type and value of > +the object produced is determined by the object. Multiple evaluations of the > +same attribute reference may yield different objects. > > > .. _subscriptions: > @@ -1244,10 +1245,9 @@ > lambda_expr: "lambda" [`parameter_list`]: `expression` > lambda_expr_nocond: "lambda" [`parameter_list`]: `expression_nocond` > > -Lambda expressions (sometimes called lambda forms) have the same syntactic position as > -expressions. They are a shorthand to create anonymous functions; the expression > -``lambda arguments: expression`` yields a function object. The unnamed object > -behaves like a function object defined with :: > +Lambda expressions (sometimes called lambda forms) are create anonymous Unfinished thought here; "are create" -> "are used to create"? > +functions. The expression ``lambda arguments: expression`` yields a function > +object. The unnamed object behaves like a function object defined with :: While we're here, the object is in fact named, its name (__name__) is "". It's not a valid identifier, but it is its name. > > def (arguments): > return expression > @@ -1310,13 +1310,15 @@ > > .. index:: pair: operator; precedence > > -The following table summarizes the operator precedences in Python, from lowest > +The following table summarizes the operator precedence in Python, from lowest This sentence still doesn't read correctly to me; the simplest fix that makes sense to my brain is to remove "the" ("... summarizes operator precedence ..."). I would welcome any other better wording. > precedence (least binding) to highest precedence (most binding). Operators in > the same box have the same precedence. Unless the syntax is explicitly given, > operators are binary. Operators in the same box group left to right (except for > -comparisons, including tests, which all have the same precedence and chain from > -left to right --- see section :ref:`comparisons` --- and exponentiation, which > -groups from right to left). > +exponentiation, which groups from right to left). > + > +Note that comparisons, membership tests, and identity tests, all have the same > +precedence and have a left-to-right chaining feature as described in the > +:ref:`comparisons` section. > > > +-----------------------------------------------+-------------------------------------+ > diff --git a/Doc/reference/simple_stmts.rst b/Doc/reference/simple_stmts.rst > --- a/Doc/reference/simple_stmts.rst > +++ b/Doc/reference/simple_stmts.rst > @@ -7,7 +7,7 @@ > > .. index:: pair: simple; statement > > -Simple statements are comprised within a single logical line. Several simple > +A simple statement is comprised within a single logical line. Several simple I agree with the OP that "comprised within" doesn't cut it. Does his suggestion of "must fit" instead of "is comprised" work or is there a better wording? > statements may occur on a single line separated by semicolons. The syntax for > simple statements is: > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 16:51:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 May 2014 14:51:53 +0000 Subject: [issue20689] socket.AddressFamily is absent in pydoc output In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1401202313.0.0.0481127369714.issue20689@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: socket.AddressFamily is absent in html pydoc -> socket.AddressFamily is absent in pydoc output _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 19:16:23 2014 From: report at bugs.python.org (honglei jiang) Date: Tue, 27 May 2014 17:16:23 +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: <1401210983.92.0.507450642061.issue20140@psf.upfronthosting.co.za> honglei jiang added the comment: Python?canopy-1.3.0.1715.win-x86_64\ OS?Win8.1 64 >>>directory 'F:\\Flask\\EmberJS\\\xd6\xd0\xce\xc4\\Prj\\static' >>>os.path.isdir(directory) True >>>filename u'todomvc/architecture-examples/angularjs/index.html' >>>os.path.join(directory,filename) Traceback (most recent call last): File "c:\Users\honglei\AppData\Local\Enthought\Canopy\User\Lib\site-packages\flask\helpers.py", line 1, in # -*- coding: utf-8 -*- File "C:\Users\honglei\AppData\Local\Enthought\Canopy\App\appdata\canopy-1.3.0.1715.win-x86_64\Lib\ntpath.py", line 108, in join path += "\\" + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xd6 in position 17: ordinal not in range(128) >>>f=os.path.join(directory.decode(sys.getfilesystemencoding()),filename) >>>os.path.isfile(f) True ---------- nosy: +jhonglei _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 19:17:19 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 27 May 2014 17:17:19 +0000 Subject: [issue11468] Improve unittest basic example in the doc In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za> Message-ID: <1401211039.36.0.638015474756.issue11468@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 16:57:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 May 2014 14:57:21 +0000 Subject: [issue20689] socket.AddressFamily is absent in pydoc output In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1401202641.33.0.236568501465.issue20689@psf.upfronthosting.co.za> STINNER Victor added the comment: I suggested to not document new enums of the socket module (ex: AddressFamily, SocketType) when they were added. I don't think that they should be part of Python public API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 22:04:02 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 27 May 2014 20:04:02 +0000 Subject: [issue18807] Allow venv to create copies, even when symlinks are supported In-Reply-To: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za> Message-ID: <1401221042.96.0.555352770974.issue18807@psf.upfronthosting.co.za> Vinay Sajip added the comment: While you may be right about line 215, line 147 isn't analogous, because in the latter case it's a symlink to a directory. We don't really want the entire lib directory tree *copied* into lib64 (and in any case, the populating of lib will happen much after venv creatuion, when things are installed into the venv: a copy is of no use here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 22:36:29 2014 From: report at bugs.python.org (Lita Cho) Date: Tue, 27 May 2014 20:36:29 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1401222989.82.0.915761974.issue17172@psf.upfronthosting.co.za> Lita Cho added the comment: I am currently in the process of editing this patch such that the Turtle Demo launches from the Help Menu and spawns a separate process. However, I am deciding whether if the separate process should be asynchronous or not. Currently, I have it working with the subprocess module, but the IDLE window is hanging. I can use the multiprocess module or Popen to make it asynchronous. However, I am not sure where the clean-up should happen once the turtle process has been terminated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 22:48:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 27 May 2014 20:48:31 +0000 Subject: [issue21539] pathlib's Path.mkdir() should allow for "mkdir -p" functionality In-Reply-To: <1401215521.42.0.97346059002.issue21539@psf.upfronthosting.co.za> Message-ID: <5384FA1B.9030607@free.fr> Antoine Pitrou added the comment: Le 27/05/2014 20:32, Barry A. Warsaw a ?crit : > > I've just been writing some new code to use pathlib and ran into > this one myself. An exist_ok=False is fine, although it's a slight shame that for backward compatibility we can't adopt os.makedirs() signature exactly. What do you mean by that? The os.makedirs() signature is os.makedirs(name, mode=0o777, exist_ok=False) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 23:06:55 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 27 May 2014 21:06:55 +0000 Subject: [issue21539] pathlib's Path.mkdir() should allow for "mkdir -p" functionality In-Reply-To: <5384FA1B.9030607@free.fr> Message-ID: <20140527170643.36272ae1@anarchist.wooz.org> Barry A. Warsaw added the comment: On May 27, 2014, at 08:48 PM, Antoine Pitrou wrote: >What do you mean by that? The os.makedirs() signature is >os.makedirs(name, mode=0o777, exist_ok=False) Right, but this is Path.mkdir's signature: Path.mkdir(mode=0o777, parents=False) so it's too late to make exist_ok=False the second argument (i.e. the one after `mode`). Oh well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 23:16:49 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 27 May 2014 21:16:49 +0000 Subject: [issue21578] Misleading error message when ImportError called with invalid keyword args In-Reply-To: <1401078695.26.0.813929580296.issue21578@psf.upfronthosting.co.za> Message-ID: <1401225409.66.0.732542909193.issue21578@psf.upfronthosting.co.za> Eric Snow added the comment: Looks good to me. Thanks for doing this. If no one objects in the meantime, I'll commit this in a few days. ---------- assignee: -> eric.snow stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 23:25:30 2014 From: report at bugs.python.org (Dominic Cerquetti) Date: Tue, 27 May 2014 21:25:30 +0000 Subject: [issue18807] Allow venv to create copies, even when symlinks are supported In-Reply-To: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za> Message-ID: <1401225930.24.0.522752834867.issue18807@psf.upfronthosting.co.za> Dominic Cerquetti added the comment: Preliminary patch for line 215, per earlier description. While this doesn't appear to break anything and creates both copies and symlinks correctly, I do have these four failing unit tests: test_multiprocessing_fork test_multiprocessing_forkserver test_multiprocessing_main_handling test_multiprocessing_spawn I don't have time right now to look into it to see if they're related to my change (at first glance, it looks like not). ---------- keywords: +patch Added file: http://bugs.python.org/file35382/venv-symlink-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 23:33:43 2014 From: report at bugs.python.org (Dominic Cerquetti) Date: Tue, 27 May 2014 21:33:43 +0000 Subject: [issue18807] Allow venv to create copies, even when symlinks are supported In-Reply-To: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za> Message-ID: <1401226423.17.0.643950326202.issue18807@psf.upfronthosting.co.za> Dominic Cerquetti added the comment: Ok cool, as you said line 215 then seems to be the only one that needs it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 23:45:43 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 May 2014 21:45:43 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1401227143.05.0.421990895687.issue17172@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > the IDLE window is hanging Check to make sure it is actually hung. The event-loop can make it look hung but it is actually just waiting for an event. An IDLE restart suffices to kill it sometimes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 27 23:48:30 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 May 2014 21:48:30 +0000 Subject: [issue11468] Improve unittest basic example in the doc In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za> Message-ID: <1401227310.45.0.855611716418.issue11468@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I'm going to test some other module (math or somesuch) rather than the built-in string methods. The normal use of unittest is to import both the unittest module and the module under test. I want to show that pattern (which is somewhat different from doctests where the tests are typically in the same file as the code being tested). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 00:26:57 2014 From: report at bugs.python.org (Lita Cho) Date: Tue, 27 May 2014 22:26:57 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1401229617.27.0.363454084627.issue17172@psf.upfronthosting.co.za> Lita Cho added the comment: Okay, maybe "hanging" is not the right word. The IDLE window becomes busy since it spawned off the Turtle demo subprocess, and it is waiting for the subprocess to finish. After I close the Turtle window, it returns back to normal. I was wondering if the Turtle Demo should be a separate asynchronous process so that users could use the IDLE window as well as the Turtle demo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 00:28:44 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 27 May 2014 22:28:44 +0000 Subject: [issue18132] buttons in turtledemo disappear on small screens In-Reply-To: <1370353605.18.0.929519765734.issue18132@psf.upfronthosting.co.za> Message-ID: <1401229724.21.0.303015947303.issue18132@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 04:14:59 2014 From: report at bugs.python.org (Lita Cho) Date: Wed, 28 May 2014 02:14:59 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1401243299.36.0.753574089255.issue17172@psf.upfronthosting.co.za> Lita Cho added the comment: I currently have a patch where the Turtle Demo now shows up in the Help menu rather than in File menu. I also have it such that Turtle is now launched as a separate process rather than within the IDLE process. Currently, the commend is calling ./python.exe so it uses my build of Python rather than my system's python. But I can change that once people agree this is the right way to go. ---------- Added file: http://bugs.python.org/file35383/turtle_demo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 04:26:36 2014 From: report at bugs.python.org (Lita Cho) Date: Wed, 28 May 2014 02:26:36 +0000 Subject: [issue3015] tkinter with wantobjects=False has been broken for some time In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za> Message-ID: <1401243996.9.0.82114969301.issue3015@psf.upfronthosting.co.za> Lita Cho added the comment: Serhiy, does that mean this is fixed the way it is? Do I need to do anything else to close out this issue? It looks like wantobjects is set to False, currently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 05:22:49 2014 From: report at bugs.python.org (Lita Cho) Date: Wed, 28 May 2014 03:22:49 +0000 Subject: [issue6639] turtle: _tkinter.TclError: invalid command name ".10170160" In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za> Message-ID: <1401247369.97.0.708980785108.issue6639@psf.upfronthosting.co.za> Lita Cho added the comment: So I have a patch that fixes the original problem, but doesn't fix the crash with the tdemo_round_dance.py. However, I was wondering why TurtleScreen._RUNNING = True in the _destroy method. Can anyone shed some light on this? Here is the current state of my patch. ---------- keywords: +patch Added file: http://bugs.python.org/file35384/turtle_bug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 05:55:33 2014 From: report at bugs.python.org (paul j3) Date: Wed, 28 May 2014 03:55:33 +0000 Subject: [issue21208] Change default behavior of arguments with type bool when options are specified In-Reply-To: <1397339884.4.0.416428545862.issue21208@psf.upfronthosting.co.za> Message-ID: <1401249333.63.0.883310305185.issue21208@psf.upfronthosting.co.za> paul j3 added the comment: Last year someone asked on Stackoverflow about using 'type=bool'. My answer is at: http://stackoverflow.com/questions/15008758/parsing-boolean-values-with-argparse/19233287#19233287 'type' is supposed to be a function that takes a string, and converts to a desired Python object (e.g. number), and in the process validates it. The builtin 'bool()' is not a good choice for this. 'bool("")' returns False, all other strings return True, that includes strings like "false", "no", "False". If you want those strings to be interpreted as boolean False, you need to write your own 'str2bool' function. But normally boolean values are entered via 'store_true' and 'store_false' actions. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 06:11:19 2014 From: report at bugs.python.org (paul j3) Date: Wed, 28 May 2014 04:11:19 +0000 Subject: [issue21416] argparse should accept bytes arguments as originally passed In-Reply-To: <1399050639.0.0.425035380654.issue21416@psf.upfronthosting.co.za> Message-ID: <1401250279.53.0.678682324687.issue21416@psf.upfronthosting.co.za> paul j3 added the comment: Two points to keep in mind: 'argparse' works with 'sys.argv[1:]'. If that does not contain what you want, then you can pass your own 'argv' to 'parse_args'. 'type=bytes' means, call the builtin 'bytes' function with one of the argv strings. If 'bytes' does not handle the string as you want, then you need to write your own function. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 06:33:38 2014 From: report at bugs.python.org (paul j3) Date: Wed, 28 May 2014 04:33:38 +0000 Subject: [issue21416] argparse should accept bytes arguments as originally passed In-Reply-To: <1399050639.0.0.425035380654.issue21416@psf.upfronthosting.co.za> Message-ID: <1401251618.93.0.769507115833.issue21416@psf.upfronthosting.co.za> paul j3 added the comment: 'invalid bytes value' is the error message generated by 'argparse'. The underlying error (for a string like 'xxx') is: print(bytes(sys.argv[1])) TypeError: string argument without an encoding You could use 'bytes' if you somehow supply the encoding, as in: def mybytes(astr): return bytes(astr, 'utf-8') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 06:37:30 2014 From: report at bugs.python.org (paul j3) Date: Wed, 28 May 2014 04:37:30 +0000 Subject: [issue10523] argparse has problem parsing option files containing empty rows In-Reply-To: <1290635267.13.0.585990858581.issue10523@psf.upfronthosting.co.za> Message-ID: <1401251850.42.0.982354902871.issue10523@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 06:55:17 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 28 May 2014 04:55:17 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1401252917.2.0.861824105659.issue17172@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think a patch should reuse the run module function that Idle already has. No need to re-invent something. I will say more tomorrow after sleeping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 07:45:03 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 28 May 2014 05:45:03 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401255903.12.0.879111694504.issue1683368@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I recently ran into this error again. I was writing this class to provide backward-compatible context manager support for zipfile.ZipFile on Python 2.6 and 3.1: class ContextualZipFile(zipfile.ZipFile): """ Supplement ZipFile class to support context manager for Python 2.6 """ def __enter__(self): return self def __exit__(self, type, value, traceback): self.close() def __new__(cls, *args, **kwargs): """ Construct a ZipFile or ContextualZipFile as appropriate """ if hasattr(zipfile.ZipFile, '__exit__'): return zipfile.ZipFile(*args, **kwargs) return super(ContextualZipFile, cls).__new__(cls, *args, **kwargs) At the point where super is called, the author is unaware of the details of the function signature for zipfile.ZipFile.__new__, so simply passes the same arguments as were received by the derived class. However, this behavior raises a DeprecationWarning on Python 2.6 and 3.1 (and would raise an error on Python 3.2 if the code allowed it). What's surprising is that the one cannot simply override a constructor or initializer without knowing in advance which of those methods are implemented (and with what signature) on the parent class. It seems like the construction (calling of __new__) is special-cased for classes that don't implement __new__. What is the proper implementation of ContextualZipFile.__new__? Should it use super but omit the args and kwargs? Should it call object.__new__ directly? Should it check for the existence of __new__ on the parent class (or compare it to object.__new__)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 07:50:00 2014 From: report at bugs.python.org (paul j3) Date: Wed, 28 May 2014 05:50:00 +0000 Subject: [issue20430] Make argparse.SUPPRESS work as an argument "dest" In-Reply-To: <1390963954.16.0.426686215118.issue20430@psf.upfronthosting.co.za> Message-ID: <1401256200.43.0.251438332934.issue20430@psf.upfronthosting.co.za> paul j3 added the comment: If we make this change to '_StoreAction', we need to do it to 4 other subclasses which take the same 'setattr(namespace, self.dest, values)'. An alternative would be to define a 'Namespace' function that does this conditional 'setattr'. How should this 'SUPPRESS' affect the usage and help? I'm seeing "--foo ==SUPPRESS==". Do you have practical need for such a 'SUPPRESS', or are you just trying to make behavior consistent? 'SUPPRESS' is used for '--help' and subparsers because those Actions have important side effects, and we don't want default values to appear in the Namespace. With '_StoreAction', the only effect is to store a value in the Namespace. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 07:52:09 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 28 May 2014 05:52:09 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401256329.66.0.117383559339.issue1683368@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I recently ran into this error again. I was writing this class to provide backward-compatible context manager support for zipfile.ZipFile on Python 2.6 and 3.1: class ContextualZipFile(zipfile.ZipFile): """ Supplement ZipFile class to support context manager for Python 2.6 """ def __enter__(self): return self def __exit__(self, type, value, traceback): self.close() def __new__(cls, *args, **kwargs): """ Construct a ZipFile or ContextualZipFile as appropriate """ if hasattr(zipfile.ZipFile, '__exit__'): return zipfile.ZipFile(*args, **kwargs) return super(ContextualZipFile, cls).__new__(cls, *args, **kwargs) At the point where super is called, the author is unaware of the details of the function signature for zipfile.ZipFile.__new__, so simply passes the same arguments as were received by the derived class. However, this behavior raises a DeprecationWarning on Python 2.6 and 3.1 (and would raise an error on Python 3.2 if the code allowed it). What's surprising is that the one cannot simply override a constructor or initializer without knowing in advance which of those methods are implemented (and with what signature) on the parent class. It seems like the construction (calling of __new__) is special-cased for classes that don't implement __new__. What is the proper implementation of ContextualZipFile.__new__? Should it use super but omit the args and kwargs? Should it call object.__new__ directly? Should it check for the existence of __new__ on the parent class (or compare it to object.__new__)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 07:53:36 2014 From: report at bugs.python.org (paul j3) Date: Wed, 28 May 2014 05:53:36 +0000 Subject: [issue9351] argparse set_defaults on subcommands should override top level set_defaults In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za> Message-ID: <1401256416.38.0.714882979629.issue9351@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 08:43:23 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 28 May 2014 06:43:23 +0000 Subject: [issue21197] venv does not create lib64 directory and appropriate symlinks In-Reply-To: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za> Message-ID: <1401259403.95.0.268665138221.issue21197@psf.upfronthosting.co.za> Vinay Sajip added the comment: Issue #18807 relates to symlinks not being available, or not being wanted by the user creating the environment. The lib64 symlink is (currently) the only case where we symlink to a directory (in the other cases, such as aliases for the interpreter, we can use copies rather than symlinks). I propose to make a change such that if copying rather than symlinking is specified, the lib64 link simply isn't created - a copy would be of no use here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 09:08:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 May 2014 07:08:47 +0000 Subject: [issue18807] Allow venv to create copies, even when symlinks are supported In-Reply-To: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za> Message-ID: <3gdjnR1T6mz7Ljn@mail.python.org> Roundup Robot added the comment: New changeset ce1b8b2ddf07 by Vinay Sajip in branch '3.4': Issue #18807: If copying (no symlinks) specified for a venv, then the python interpreter aliases (python, python3) are now created by copying rather than symlinking. http://hg.python.org/cpython/rev/ce1b8b2ddf07 New changeset f2adaccc13ab by Vinay Sajip in branch 'default': Issue #18807: Merged fix from 3.4. http://hg.python.org/cpython/rev/f2adaccc13ab ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 09:16:13 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 28 May 2014 07:16:13 +0000 Subject: [issue18807] Allow venv to create copies, even when symlinks are supported In-Reply-To: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za> Message-ID: <1401261373.59.0.761574977537.issue18807@psf.upfronthosting.co.za> Vinay Sajip added the comment: I've made the change - not exactly the same as your patch, which was missing an os.chmod() and doing an unnecessary os.path.join() - but thanks for submitting a patch :-). However, note that on 64-bit Linux systems (actually any POSIX other than OS X) a symlink lib64 -> lib is still created. Perhaps this could be omitted, but I'm not sure if that would cause problems with pip. I've posted a note on the relevant issue - #21197. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 10:47:59 2014 From: report at bugs.python.org (Robert Jordens) Date: Wed, 28 May 2014 08:47:59 +0000 Subject: [issue21591] "exec(a, b, c)" not the same as "exec a in b, c" in nested functions Message-ID: <1401266879.61.0.867969486588.issue21591@psf.upfronthosting.co.za> New submission from Robert Jordens: According to the documentation the "exec a in b, c" is equivalent to "exec(a, b, c)". But in the testcase below the tuple form causes a SyntaxError while the statement form works fine. diff -r e770d8c4291c Lib/test/test_compile.py --- a/Lib/test/test_compile.py Tue May 27 03:30:44 2014 -0400 +++ b/Lib/test/test_compile.py Wed May 28 02:45:31 2014 -0600 @@ -90,6 +90,22 @@ with self.assertRaises(TypeError): exec("a = b + 1", g, l) in g, l + def test_nested_qualified_exec(self): + # Can use qualified exec in nested functions. + code = [""" +def g(): + def f(): + if True: + exec "" in {}, {} + """, """ +def g(): + def f(): + if True: + exec("", {}, {}) + """] + for c in code: + compile(c, "", "exec") + def test_exec_with_general_mapping_for_locals(self): class M: SyntaxError: unqualified exec is not allowed in function 'f' it is a nested function (, line 5) ---------- components: Interpreter Core messages: 219259 nosy: Robert.Jordens priority: normal severity: normal status: open title: "exec(a, b, c)" not the same as "exec a in b, c" in nested functions type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 12:03:01 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 May 2014 10:03:01 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <3gdnfV125Lz7Lm7@mail.python.org> Roundup Robot added the comment: New changeset 6e2833ae1718 by Serhiy Storchaka in branch '2.7': Issue #10203: sqlite3.Row now truly supports sequence protocol. In particular http://hg.python.org/cpython/rev/6e2833ae1718 New changeset 6af865f1a59d by Serhiy Storchaka in branch '3.4': Issue #10203: sqlite3.Row now truly supports sequence protocol. In particulr http://hg.python.org/cpython/rev/6af865f1a59d New changeset 474c97a5f0c8 by Serhiy Storchaka in branch 'default': Issue #10203: sqlite3.Row now truly supports sequence protocol. In particulr http://hg.python.org/cpython/rev/474c97a5f0c8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 12:06:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 10:06:50 +0000 Subject: [issue10203] sqlite3.Row doesn't support sequence protocol In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za> Message-ID: <1401271610.46.0.17184832249.issue10203@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Claudiu for your contribution. But please be more careful, your patches contained trailing whitespaces. Thank you Paul for your report. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 12:09:27 2014 From: report at bugs.python.org (Karl Richter) Date: Wed, 28 May 2014 10:09:27 +0000 Subject: [issue21208] Change default behavior of arguments with type bool when options are specified In-Reply-To: <1397339884.4.0.416428545862.issue21208@psf.upfronthosting.co.za> Message-ID: <1401271767.19.0.149990282687.issue21208@psf.upfronthosting.co.za> Karl Richter added the comment: @paul.j3 That's interesting [1]. Documenting argparse.register seems crucial to me (-> reopen or file a new request?). After dealing more with the very sophisticated and complex functionality of argparse I'm sure that this is the only use case where such an unintuitive result may happen, so it's worth adding an explicit negative example in the docs of argparse.add_argument with a hint to the docs about "way that argparse handles types". ---------- [1] (and a very good example for missing capabilities of Q&A sites with regard to the relation of votes of your much better answer and the one with the highest number of votes) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 13:27:01 2014 From: report at bugs.python.org (Thomas Heller) Date: Wed, 28 May 2014 11:27:01 +0000 Subject: [issue5950] Make zipimport work with zipfile containing comments In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za> Message-ID: <1401276421.36.0.495835885811.issue5950@psf.upfronthosting.co.za> Thomas Heller added the comment: > As for progress, the answer is no as the hope is to eventually replace > zipimport with something in pure Python thanks to importlib. Does this mean there is no chance to put this into 3.4 and 3.3, do we really have to wait until 3.5 with it's pure-python zipimport? I (together with the py2exe-users) have the same usecase as Ryan Kelly in msg110014: > I want to digitally sign a frozen python program with appended zipfile, > which involves appending the signature to the EXE. Simple to do if > only zipimport would support appended comments. ---------- nosy: +theller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 13:34:05 2014 From: report at bugs.python.org (jzwinck) Date: Wed, 28 May 2014 11:34:05 +0000 Subject: [issue20430] Make argparse.SUPPRESS work as an argument "dest" In-Reply-To: <1390963954.16.0.426686215118.issue20430@psf.upfronthosting.co.za> Message-ID: <1401276845.33.0.375796393396.issue20430@psf.upfronthosting.co.za> jzwinck added the comment: Yes, I have a practical need for dest=SUPPRESS. One of the reasons is basically what you said: to implement things analogous to --help. In those cases you want to be able to invoke a function (e.g. via type=myfunc) but not store anything. Or you may need to ignore an argument completely for compatibility, but you have logic which expects all the arguments returned by parse_args() to be known and meaningful. In any case, I wrote this ticket because I ran into a concrete need that argparse didn't readily support (which almost never happens!). As for what the usage statement should show: it should behave as if dest=SUPPRESS were not present. If metavar is specified, use that, otherwise use the option name as if dest were not passed in. And we already have the behavior that help=SUPPRESS will hide it from the usage entirely, so that should still work (i.e. dest=SUPPRESS, help=SUPPRESS should hide the option both from --help and the result of parse_args()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 14:11:38 2014 From: report at bugs.python.org (Thomas Dybdahl Ahle) Date: Wed, 28 May 2014 12:11:38 +0000 Subject: [issue21592] Make statistics.median run in linear time Message-ID: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> New submission from Thomas Dybdahl Ahle: The statistics module currently contains the following comment: "FIXME: investigate ways to calculate medians without sorting? Quickselect?" This is important, because users expect standard library functions to use state of the art implementations, and median by sorting has never been that. There are many good linear time alternatives, the classical median-of-k algorithm was posted to the mailing list in a nice version by David Eppstein in 2002 [1]. The fastest method in practice is probably Quick Select in the Floyd-Rivest version [2] which is similar to quick sort. These algorithms also have the feature of letting us select any k-th order statistic, not just the median. This seems conceptually a lot simpler than the current median/median_low/median_high split. However, sticking with the current api, a new implementation would have to support calculating a median as the average of n//2 and (n+1)//2'th order statistics. This could be implemented either by calling the select function twice, or by implementing a multi-select algorithm, which is also a well studied problem [3]. I'll be happy to contribute code, or help out in any other way. [1]: https://mail.python.org/pipermail/python-list/2002-May/132170.html [2]: https://en.wikipedia.org/wiki/Floyd%E2%80%93Rivest_algorithm [3]: https://domino.mpi-inf.mpg.de/intranet/ag1/ag1publ.nsf/0/59C74289A2291143C12571C30017DEA8/$file/Mehlhorn_a_2005_o.pdf ---------- components: Library (Lib) messages: 219265 nosy: Thomas.Dybdahl.Ahle priority: normal severity: normal status: open title: Make statistics.median run in linear time type: performance versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 15:10:29 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 28 May 2014 13:10:29 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1401282629.98.0.353167773384.issue21592@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +steven.daprano stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 15:25:40 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 28 May 2014 13:25:40 +0000 Subject: [issue5950] Make zipimport work with zipfile containing comments In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za> Message-ID: <1401283540.68.0.46153866017.issue5950@psf.upfronthosting.co.za> Brett Cannon added the comment: I actually stopped development of a pure Python zip importer so it won't be in Python 3.5 either (http://bugs.python.org/issue17630). The motivation simply wasn't there if zipimport is going to be sticking around for bootstrapping reasons. This can still get fixed in 3.5 (3.4 is Larry's call). I have added Thomas Wouters and Greg Smith who have done the most work with zipimport to the nosy list to see if they have interest in taking a look at the patch. ---------- nosy: +gregory.p.smith, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 15:53:50 2014 From: report at bugs.python.org (Peter Otten) Date: Wed, 28 May 2014 13:53:50 +0000 Subject: [issue5950] Make zipimport work with zipfile containing comments In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za> Message-ID: <1401285230.51.0.689185113699.issue5950@psf.upfronthosting.co.za> Changes by Peter Otten <__peter__ at web.de>: ---------- nosy: +peter.otten _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 16:00:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 May 2014 14:00:42 +0000 Subject: [issue3015] tkinter with wantobjects=False has been broken for some time In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za> Message-ID: <3gdtwm3v8Kz7LjT@mail.python.org> Roundup Robot added the comment: New changeset c69e8ea3bf10 by Serhiy Storchaka in branch 'default': Issue #3015: _tkinter.create() now creates tkapp object with wantobject=1 by http://hg.python.org/cpython/rev/c69e8ea3bf10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 16:04:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 14:04:10 +0000 Subject: [issue3015] tkinter with wantobjects=False has been broken for some time In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za> Message-ID: <1401285850.01.0.869325734815.issue3015@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Lita Cho, originally reported issue is fixed. I asked Martin (and Guilherme if he is here). Are you agree to close this issue? See issue21585 about extending testing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 16:19:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 14:19:32 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1401286772.63.0.0235262114118.issue21579@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: OK, O_TMPFILE is not related. But Windows is related. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 16:39:26 2014 From: report at bugs.python.org (Joshua Landau) Date: Wed, 28 May 2014 14:39:26 +0000 Subject: [issue21593] Clarify re.search documentation first match Message-ID: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za> New submission from Joshua Landau: The documentation for re.search does not state that it returns the first match. This should be added, or a clarification added if this is implementation-defined. https://docs.python.org/3/library/re.html#re.search --- See also http://stackoverflow.com/questions/23906400/is-regular-expression-search-guaranteed-to-return-first-match ---------- assignee: docs at python components: Documentation messages: 219270 nosy: Joshua.Landau, docs at python priority: normal severity: normal status: open title: Clarify re.search documentation first match versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 16:43:29 2014 From: report at bugs.python.org (Thomas Dybdahl Ahle) Date: Wed, 28 May 2014 14:43:29 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1401288209.47.0.701632345557.issue21592@psf.upfronthosting.co.za> Thomas Dybdahl Ahle added the comment: I have written some proof of concept code here [1], I would appreciate you commenting on it, before I turn it into a patch, as I haven't contributed code to Python before. I have tried to write it as efficiently as possible, but it is of course possible that the c-implemented `sorted()` code will be faster than even the smartest python-implemented select. [1]: http://pastebin.com/30x0j39a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:02:20 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 28 May 2014 15:02:20 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401289340.46.0.528331285247.issue1683368@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- Removed message: http://bugs.python.org/msg219253 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:02:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 28 May 2014 15:02:28 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401289348.29.0.409752626119.issue1683368@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg219255 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:03:45 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 28 May 2014 15:03:45 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401256329.66.0.117383559339.issue1683368@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I recently ran into this error again. I was writing this class to provide backward-compatible context manager support for zipfile.ZipFile on Python 2.6 and 3.1: class ContextualZipFile(zipfile.ZipFile): """ Supplement ZipFile class to support context manager for Python 2.6 """ def __enter__(self): return self def __exit__(self, type, value, traceback): self.close() def __new__(cls, *args, **kwargs): """ Construct a ZipFile or ContextualZipFile as appropriate """ if hasattr(zipfile.ZipFile, '__exit__'): return zipfile.ZipFile(*args, **kwargs) return super(ContextualZipFile, cls).__new__(cls, *args, **kwargs) At the point where super is called, the author is unaware of the details of the function signature for zipfile.ZipFile.__new__, so simply passes the same arguments as were received by the derived class. However, this behavior raises a DeprecationWarning on Python 2.6 and 3.1 (and would raise an error on Python 3.2 if the code allowed it). What's surprising is that the one cannot simply override a constructor or initializer without knowing in advance which of those methods are implemented (and with what signature) on the parent class. It seems like the construction (calling of __new__) is special-cased for classes that don't implement __new__. What is the proper implementation of ContextualZipFile.__new__? Should it use super but omit the args and kwargs? Should it call object.__new__ directly? Should it check for the existence of __new__ on the parent class (or compare it to object.__new__)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:05:09 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 28 May 2014 15:05:09 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401289509.54.0.542244672138.issue1683368@psf.upfronthosting.co.za> Guido van Rossum added the comment: If you don't know enough about the base class you shouldn't be subclassing it. In this particular case you should be overriding __init__, not __new__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:12:49 2014 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 28 May 2014 15:12:49 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1401289969.55.0.182335182153.issue21579@psf.upfronthosting.co.za> ???? ????????? added the comment: So, maybe API change? like delete=True|False|Maybe ? don't think that this is good decisions. My approach is based on ext4 behaviour about delayed allocation and atomic file replacements. In my case, either old file (with contents) or new file appear. In any case, corrupted data cannot appear. This is required behaviour for my application. https://www.kernel.org/doc/Documentation/filesystems/ext4.txt http://lwn.net/Articles/322823/ ======================================================================= auto_da_alloc(*) Many broken applications don't use fsync() when noauto_da_alloc replacing existing files via patterns such as fd = open("foo.new")/write(fd,..)/close(fd)/ rename("foo.new", "foo"), or worse yet, fd = open("foo", O_TRUNC)/write(fd,..)/close(fd). If auto_da_alloc is enabled, ext4 will detect the replace-via-rename and replace-via-truncate patterns and force that any delayed allocation blocks are allocated such that at the next journal commit, in the default data=ordered mode, the data blocks of the new file are forced to disk before the rename() operation is committed. This provides roughly the same level of guarantees as ext3, and avoids the "zero-length" problem that can happen when a system crashes before the delayed allocation blocks are forced to disk. ======================================================================= So, this is essential functionality. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:15:09 2014 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 28 May 2014 15:15:09 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1401290109.08.0.736901181318.issue21579@psf.upfronthosting.co.za> ???? ????????? added the comment: why not to make tmpfileobj.delete as property that really sets self._closer.delete ? this will fix my problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:16:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 May 2014 15:16:17 +0000 Subject: [issue21493] Add test for ntpath.expanduser In-Reply-To: <1399975960.27.0.370722329224.issue21493@psf.upfronthosting.co.za> Message-ID: <3gdwby3JBZz7Lk9@mail.python.org> Roundup Robot added the comment: New changeset 5e599b301ebd by Serhiy Storchaka in branch '2.7': Issue #21493: Added test for ntpath.expanduser(). Original patch by http://hg.python.org/cpython/rev/5e599b301ebd New changeset a981a088512c by Serhiy Storchaka in branch '3.4': Issue #21493: Added test for ntpath.expanduser(). Original patch by http://hg.python.org/cpython/rev/a981a088512c New changeset 5a71a7e60fe6 by Serhiy Storchaka in branch 'default': Issue #21493: Added test for ntpath.expanduser(). Original patch by http://hg.python.org/cpython/rev/5a71a7e60fe6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:23:55 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 28 May 2014 15:23:55 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401290635.69.0.089123753095.issue1683368@psf.upfronthosting.co.za> Terry J. Reedy added the comment: >From what I see, you do not need to change either __new__ or __init__, just add __enter__ and __exit__ , and you only need to do that in 2.6. Since Zipfile is written in Python, you could monkey-patch instead of subclassing, if that is easier in your particular case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:27:46 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 28 May 2014 15:27:46 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1401290866.08.0.939429570102.issue19385@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:39:11 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 28 May 2014 15:39:11 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds In-Reply-To: <1401289509.54.0.542244672138.issue1683368@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > If you don't know enough about the base class you shouldn't be subclassing it. That's important when overriding any API in subclass and absolutely always essential when it comes to __new__ and __init__! That's something that isn't very obvious at first. :( > In this particular case you should be overriding __init__, not __new__. Jason's code is doing something like OSError.__new__ does now, which returns an instance of a subclass depending on the errno. However, while the language supports it, I see that as a viable hack only when backward-compatibilty is a big concern. Otherwise I find factory classmethods to be a much better solution for discoverability and clarity of implementation. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:39:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 15:39:31 +0000 Subject: [issue21493] Add test for ntpath.expanduser In-Reply-To: <1399975960.27.0.370722329224.issue21493@psf.upfronthosting.co.za> Message-ID: <1401291571.33.0.511285357281.issue21493@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Claudiu. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:44:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 May 2014 15:44:16 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <3gdxDH34lbz7MNl@mail.python.org> Roundup Robot added the comment: New changeset 8e5c65719c12 by Serhiy Storchaka in branch '2.7': Issue #21402: tkinter.ttk now works when default root window is not set. http://hg.python.org/cpython/rev/8e5c65719c12 New changeset 4a0987b8f630 by Serhiy Storchaka in branch '3.4': Issue #21402: tkinter.ttk now works when default root window is not set. http://hg.python.org/cpython/rev/4a0987b8f630 New changeset c112a91ad609 by Serhiy Storchaka in branch 'default': Issue #21402: tkinter.ttk now works when default root window is not set. http://hg.python.org/cpython/rev/c112a91ad609 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:51:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 May 2014 15:51:02 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <3gdxN45MqLz7Lxd@mail.python.org> Roundup Robot added the comment: New changeset 95207bcd8298 by Serhiy Storchaka in branch '3.4': Restore performance of some dumb database methods (regression introduced by #19385). http://hg.python.org/cpython/rev/95207bcd8298 New changeset 2e59e0b579e5 by Serhiy Storchaka in branch 'default': Restore performance of some dumb database methods (regression introduced by #19385). http://hg.python.org/cpython/rev/2e59e0b579e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:51:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 15:51:18 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1401292278.91.0.221855749507.issue21402@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 May 28 17:51:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 15:51:56 +0000 Subject: [issue21402] tkinter.ttk._val_or_dict assumes tkinter._default_root exists In-Reply-To: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za> Message-ID: <1401292316.25.0.549969874926.issue21402@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report Stephen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:53:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 15:53:06 +0000 Subject: [issue19385] dbm.dumb should be consistent when the database is closed In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za> Message-ID: <1401292386.08.0.867434645658.issue19385@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Claudiu. ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 17:57:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 15:57:53 +0000 Subject: [issue21343] os.path.relpath returns inconsistent types In-Reply-To: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za> Message-ID: <1401292673.8.0.10716701886.issue21343@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: OK. I say the original issue is not a bug. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 18:06:40 2014 From: report at bugs.python.org (Sebastian Kreft) Date: Wed, 28 May 2014 16:06:40 +0000 Subject: [issue21594] asyncio.create_subprocess_exec raises OSError Message-ID: <1401293200.2.0.763009510158.issue21594@psf.upfronthosting.co.za> New submission from Sebastian Kreft: In some cases asyncio.create_subprocess_exec raises an OSError because there are no file descriptors available. I don't know if that is expected, but IMO I think it would be better to just block until the required numbers of fds are available. Otherwise one would need to do this handling, which is not a trivial task. This issue is happening in Debian 7, with a 3.2.0-4-amd64 kernel, and python 3.4.1 compiled from source. ---------- messages: 219285 nosy: Sebastian.Kreft.Deezer priority: normal severity: normal status: open title: asyncio.create_subprocess_exec raises OSError versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 18:08:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 16:08:53 +0000 Subject: [issue21594] asyncio.create_subprocess_exec raises OSError In-Reply-To: <1401293200.2.0.763009510158.issue21594@psf.upfronthosting.co.za> Message-ID: <1401293333.74.0.707889936666.issue21594@psf.upfronthosting.co.za> STINNER Victor added the comment: "I don't know if that is expected, but IMO I think it would be better to just block until the required numbers of fds are available." Does it mean that it can block forever? It sounds strange to try to make such error silent. Why not retrying in case of such error in your application? asyncio has no idea how to release file descriptors. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 18:16:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 16:16:43 +0000 Subject: [issue21580] PhotoImage(data=...) apparently has to be UTF-8 or Base-64 encoded In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za> Message-ID: <1401293803.08.0.0721207945079.issue21580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: All works to me. >>> import tkinter >>> b = tkinter.Button() >>> with open('Lib/test/imghdrdata/python.gif', 'rb') as f: data = f.read() ... >>> img = tkinter.PhotoImage(data=data) >>> b['image'] = img >>> b.pack() Could you please provide an example which demonstrates the issue? ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 18:18:25 2014 From: report at bugs.python.org (Sebastian Kreft) Date: Wed, 28 May 2014 16:18:25 +0000 Subject: [issue21595] Creating many subprocess generates lots of internal BlockingIOError Message-ID: <1401293905.24.0.60580037819.issue21595@psf.upfronthosting.co.za> New submission from Sebastian Kreft: Using the asyncio.create_subprocess_exec, generates lost of internal error messages. These messages are: Exception ignored when trying to write to the signal wakeup fd: BlockingIOError: [Errno 11] Resource temporarily unavailable Getting the messages depeneds on how many subprocesses are active at the same time. In my system (Debian 7, kernel 3.2.0-4-amd64, python 3.4.1), with 3 or less processes at the same time I don't see any problem, but with 4 or more I got lot of messages. On the other hand, these error messages seem to be innocuous, as no exception seems to be raised. Attached is a test script that shows the problem. It is run as: bin/python3.4 test_subprocess_error.py it requires to have the du command. Let me know if there are any (conceptual) mistakes in the attached code. ---------- files: test_subprocess_error.py messages: 219288 nosy: Sebastian.Kreft.Deezer priority: normal severity: normal status: open title: Creating many subprocess generates lots of internal BlockingIOError versions: Python 3.4 Added file: http://bugs.python.org/file35385/test_subprocess_error.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 18:22:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 16:22:06 +0000 Subject: [issue21579] Python 3.4: tempfile.close attribute does not work In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za> Message-ID: <1401294126.36.0.501543507032.issue21579@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it would be easy to restore this behavior on Posix. ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 18:22:29 2014 From: report at bugs.python.org (Sebastian Kreft) Date: Wed, 28 May 2014 16:22:29 +0000 Subject: [issue21596] asyncio.wait fails when futures list is empty Message-ID: <1401294149.12.0.93780466725.issue21596@psf.upfronthosting.co.za> New submission from Sebastian Kreft: Passing an empty list/set of futures to asyncio.wait raises an Exception, which is a little annoying in some use cases. Probably this was the intended behavior as I see there's a test case for that. If such, then I would propose to document that behavior. ---------- assignee: docs at python components: Documentation messages: 219290 nosy: Sebastian.Kreft.Deezer, docs at python priority: normal severity: normal status: open title: asyncio.wait fails when futures list is empty versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 18:24:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 16:24:48 +0000 Subject: [issue20689] socket.AddressFamily is absent in pydoc output In-Reply-To: <1392846231.92.0.877729526806.issue20689@psf.upfronthosting.co.za> Message-ID: <1401294288.54.0.680739908174.issue20689@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: We should discuss this suggestion on Python-Dev. It affects the use of enums in other modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 18:27:05 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Wed, 28 May 2014 16:27:05 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401294425.64.0.63751124599.issue21477@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Summary for htest-28052014-34.diff and htest-28052014-27.diff 1. Add htest for GrepDialog,UndoDelegator and configDialog 2. Makes changes to the way the help string is displayed. The label has been replaced by a text widget made to look like a label, and also scrollable. The result is that the htest root dialog stays in the same place and same size throughout.(See the code for more information). 3. Some minor change to spec dict strings and in ObjectBrowser for child dialog placement. With this, it leaves AutoCompleteWindow, TkMessageBoxes, Debugger(from 21477-htest.txt) to be tested. OutputWindow - already being tested from GrepDialog. There is nothing extra to be tested separately. FileList - Is it already being tested through EditorWindow? In case there is a need to test them, please say so. The code is ready. RemoteDebugger and RemoteObjectBrowser - I need some input on how to begin with them. Next: Apart from the above htest, a way to destroy the child when user clicks 'next', for certain modules like ClassBrowser, which don't work by the method of http://bugs.python.org/msg219161 ---------- Added file: http://bugs.python.org/file35386/htest-28052014-34.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 18:28:02 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Wed, 28 May 2014 16:28:02 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401294482.68.0.417284002337.issue21477@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file35387/htest-28052014-27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 19:42:15 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 28 May 2014 17:42:15 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401298935.15.0.731160339765.issue1683368@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, I didn't realize why __new__ was being used. But what Jason's code is doing isn't any cleaner than monkey-patching. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 20:44:05 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 28 May 2014 18:44:05 +0000 Subject: [issue18141] tkinter.Image.__del__ can throw an exception if module globals are destroyed in the wrong order In-Reply-To: <1370434176.62.0.932474289882.issue18141@psf.upfronthosting.co.za> Message-ID: <1401302645.05.0.115504960881.issue18141@psf.upfronthosting.co.za> Terry J. Reedy added the comment: My worry about the patch is that is is a bandage covering up a problem elsewhere. 1. You indicate that you only have a problem with your custom build, but not on a standard build. This seems odd. Perhaps the problem is with your build. 2. turtledemo.__main__ only calls root.destroy indirectly via root.wm_protocol("WM_DELETE_WINDOW", self._destroy) def _destroy(self): self.root.destroy() sys.exit() Let's assume that .destroy is called when the exception happens (verifiable by adding "print('destroy called')".) 3. The purpose of Tk.destroy is to cleanly deconstruct the gui before python's random cleanup. Should it have cleared PhotoImage? Image and Variable (and subclasses) are the only classes in tkinter.__init__ with __del__ methods. Both have a tcl.call, so Variable potentially has the same problem as Image. But neither seem to have a problem in routine tkinter use. 4. Why is there a PhotoImage to be deleted? Idle Find in Files does not find 'PhotoImage' in turtledemo/*.py. I believe it is created as follows. turtledemo.DemoWindonw.__init__ contains this odd pair of lines that initializes a turtle.Screen instance with turtle.TurtleScreen.__init__ (TurtleScreen subclasses TurtleScreenBase, not Screen). self.screen = _s_ = turtle.Screen() turtle.TurtleScreen.__init__(_s_, _s_._canvas) The latter call creates a collection of default turtles (_shapes) that includes 'blank', a 1x1 (pixel) blank PhotoImage that gets tkinter._default_root as (default) master. I suspect that adding either of these lines to _destroy would prevent the TclError. del self.screen # before self.root.destroy() import tkinter; tkinter._default_root.destroy() # after self.root 5. While it seems like a buglet for turtle to create a hidden PhotoImage, with an anonymous master, and not clean it up somehow; and while I am puzzled if this never happens with standard builds; it seems plausible that we could patch Variable/Image.__delete__ to be sure they do not leak an exception. Serhiy, what do you think? ---------- nosy: -gpolo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 20:50:04 2014 From: report at bugs.python.org (Lita Cho) Date: Wed, 28 May 2014 18:50:04 +0000 Subject: [issue21585] Run Tkinter tests with wantobjects=False In-Reply-To: <1401137639.41.0.24885887123.issue21585@psf.upfronthosting.co.za> Message-ID: <1401303004.33.0.802150548911.issue21585@psf.upfronthosting.co.za> Changes by Lita Cho : ---------- nosy: +Lita.Cho, jesstess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 21:23:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 28 May 2014 19:23:28 +0000 Subject: [issue18132] buttons in turtledemo disappear on small screens In-Reply-To: <1370353605.18.0.929519765734.issue18132@psf.upfronthosting.co.za> Message-ID: <1401305008.36.0.295963077238.issue18132@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On my widescreen, the buttons are completely gone when I shrink vertically to about 720 pixels. So they must be gone on a 600x800 screen or 720x1280 small widescreen and perhaps on a non-fullscreen window on a 780x10xx screen. I agree with fixing this if possible. The patch applies cleanly to 3.4 and fixes the problem with the buttons. However, it introduces a problem with the vertical canvas scrollbar, on the right. It does not appear when it should and does not scroll the entire canvas when it does appear. Try it with bytedesign, and see if you can fix it with an altered patch. ---------- stage: -> patch review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 21:53:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 28 May 2014 19:53:07 +0000 Subject: [issue21597] Allow turtledemo code pane to get wider. Message-ID: <1401306787.8.0.543638067901.issue21597@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Turtledemo (python -m turtledemo) has a text pane for code and a canvas pane for the actual demo. The code pane is fixed at about 60% of the width needed to display full-width code lines. If the window is expanded horizontally, all the expansion goes to the canvas pane, where it is mostly not needed or used. Almost all the examples are a fixed size on the canvas, independent of the size of the window on the canvas. Having the text pane too narrow makes it harder to read and copy the code than it would be if entire code lines were visible. The default width of the overall window is about 1250 pixels on my big monitor. Many people have more pixels than that. Even on smaller screen, people might like to temporarily allocate more space to the text. So I think the best solution, if possible with tkinter, would be a movable divider. ---------- messages: 219296 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Allow turtledemo code pane to get wider. type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 22:04:04 2014 From: report at bugs.python.org (Samuel Bronson) Date: Wed, 28 May 2014 20:04:04 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1401307444.5.0.200375931431.issue1054041@psf.upfronthosting.co.za> Changes by Samuel Bronson : ---------- nosy: +SamB _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 22:32:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 20:32:12 +0000 Subject: [issue21596] asyncio.wait fails when futures list is empty In-Reply-To: <1401294149.12.0.93780466725.issue21596@psf.upfronthosting.co.za> Message-ID: <1401309132.12.0.987397334885.issue21596@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 22:36:09 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 28 May 2014 20:36:09 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1401309369.15.0.104676211607.issue1820@psf.upfronthosting.co.za> Stefan Krah added the comment: Sunny, is there a definition of "visible positional fields"? Currently, it seems to me that in os.stat_result we have the opposite problem, namely "visible non-positional" fields: For example, st_atime_ns is visible but not indexable: os.stat_result(st_mode=33188, st_ino=524840, st_dev=64513, st_nlink=1, st_uid=0, st_gid=0, st_size=2113, st_atime=1401225421, st_mtime=1398786163, st_ctime=1398786163) >>> x[9] 1398786163 >>> x.st_atime_ns 1401225421887116783 >>> x[10] Traceback (most recent call last): File "", line 1, in IndexError: tuple index out of range ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 22:48:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 May 2014 20:48:56 +0000 Subject: [issue18141] tkinter.Image.__del__ can throw an exception if module globals are destroyed in the wrong order In-Reply-To: <1401302645.05.0.115504960881.issue18141@psf.upfronthosting.co.za> Message-ID: <5290104.K1Mu5HNHd7@raxxla> Serhiy Storchaka added the comment: 1. 3.3 is in security fixes only mode and shutdowning mechanism was changed in 3.4. 2. Looks as some Tk root was not explicitly destroyed and deleted during shutdown stage. 3. Tk.destroy does nothing with images, it destroys only subcomponents and commands. In any case it destroys only Tcl/Tk objects, not Python objects which wrap them. 4. I think we shouldn't use _default_root outside the tkinter package. This is implementation detail. 5. Agree, we could patch Variable/Image.__del__, and proposed patch looks correct (other way is pass TclError as default value for optional parameter: "def __del__(self, TclError=TclError)", both ways are widely used). But I prefer first try to reproduce this in tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:13:35 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 21:13:35 +0000 Subject: [issue21595] Creating many subprocess generates lots of internal BlockingIOError In-Reply-To: <1401293905.24.0.60580037819.issue21595@psf.upfronthosting.co.za> Message-ID: <1401311615.11.0.492863693343.issue21595@psf.upfronthosting.co.za> STINNER Victor added the comment: "Exception ignored when trying to write to the signal wakeup fd" message comes from the signal handler in Modules/signalmodule.c. The problem is that Python gets a lot of SIGCHLD signals (the test scripts creates +300 processes per second on my computer). The producer (signal handler writing the signal number into the "self" pipe) is faster than the consumer (BaseSelectorEventLoop._read_from_self callback). Attached patch should reduce the risk of seeing the message "Exception ignored when trying to write to the signal wakeup fd". The patch reads all pending of the self pipe, instead of just trying to read a signal byte. The test script doesn't write the error message anymore when the patch is applied (the script creates more than 300 processes per second). The patch doesn't solve completly the issue. Other possible enhancements: * Add a flag in the signal handler to notify that a signal was received, and write a single byte until the flag is reset to False. It would avoid to fill the pipe. It requires to implement a custom signal handler implemented in C, different from signal handlers of the Python module. * Add an higher priority to callbacks of signal handlers. Asyncio doesn't support priority on callbacks right now. * Increaze the size of the pipe. On Linux, it looks like "fcntl(fd, F_SETPIPE_SZ, size);" can be used. The maximum size is /proc/sys/fs/pipe-max-size (ex: 1 MB of my Fedora 20). ---------- keywords: +patch nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov Added file: http://bugs.python.org/file35388/asyncio_read_from_self.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:15:59 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 28 May 2014 21:15:59 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401311759.8.0.871714258408.issue1683368@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Maybe I should have focused on a more trivial example to demonstrate the place where my expectation was violated. The use of a real-world example is distracting from my intended point. Consider instead this abstract example: class SomeClass(SomeParentClass): def __new__(cls, *args, **kwargs): return super(SomeClass, cls).__new__(cls, *args, **kwargs) def __init__(self, *args, **kwargs): super(SomeClass, self).__init__(*args, **kwargs) Ignoring for a moment the incongruity of the invocation of __new__ with 'cls' due to __new__ being a staticmethod, the naive programmer expects the above SomeClass to work exactly like SomeParentClass because both overrides are implemented as a trivial pass-through. And indeed that technique will work just fine if the parent class implements both __init__ and __new__, but if the parent class (or one of its parents) does not implement either of those methods, the technique will fail, because the fall through to 'object' class. I believe this incongruity stems from the fact that __new__ and __init__ are special-cased not to be called if they aren't implemented on the class. Therefore, to write SomeClass without knowledge of the SomeParentClass implementation, one could write this instead: class SomeClass(SomeParentClass): def __new__(cls, *args, **kwargs): super_new = super(SomeClass, cls).__new__ if super_new is object.__new__: return super_new(cls) return super_new(cls, *args, **kwargs) def __init__(self, *args, **kwargs): super_init = super(SomeClass, self).__init__ if super_init.__objclass__ is object: return super_init(*args, **kwargs) Now that implementation is somewhat ugly and perhaps a bit brittle (particularly around use of __objclass__). Ignoring that for now, it does have the property that regardless of the class from which it derives, it will work, including: SomeParentClass = datetime.datetime # implements only __new__ SomeParentClass = zipfile.ZipFile # implements only __init__ class SomeParentClass: pass # implements neither __init__ nor __new__ While I would prefer a language construct that didn't require this dance for special casing (or similarly require the programmer to hard-code the dance to a specific implementation of a specific parent class as Guido recommends), at the very least I would suggest that the documentation better reflect this somewhat surprising behavior. Currently, the documentation states [https://docs.python.org/2/reference/datamodel.html#object.__new__] effectively "Typical implementations of __new__ invoke the superclass? __new__() method with appropriate arguments." It's left as an exercise to the reader to ascertain what 'appropriate arguments' are, and doesn't communicate that the introduction or omission of __new__ or __init__ to a class hierarchy affects the process by which a class is constructed/initialized. Greg Smith's blog demonstrates some even more dangerous cases. I don't understand why his concerns weren't addressed, because they seem legitimate, and I agree with his conclusion that the older behavior is more desirable, despite the concerns raised by the OP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:20:32 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 21:20:32 +0000 Subject: [issue21595] Creating many subprocess generates lots of internal BlockingIOError In-Reply-To: <1401293905.24.0.60580037819.issue21595@psf.upfronthosting.co.za> Message-ID: <1401312032.8.0.872094043932.issue21595@psf.upfronthosting.co.za> STINNER Victor added the comment: BaseProactorEventLoop._loop_self_reading() uses an overlapped read of 4096 bytes. I don't understand how it wakes up the event loop. When the operation is done, _loop_self_reading() is scheduled with call_soon() by the Future object. Is it enough to wake up the event loop? Is BaseProactorEventLoop correct? -- Oh, I forgot to explain this part of asyncio_read_from_self.patch: + data = self._ssock.recv(4096) + if not data: + break This break "should never occur". It should only occur if _ssock is no more blocking. But it would be a bug, because this pipe is private and set to non-blocking at its creation. I chose to add the test because it should not hurt to add it "just in case" (and to avoid an unlimited busy loop). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:29:48 2014 From: report at bugs.python.org (paul j3) Date: Wed, 28 May 2014 21:29:48 +0000 Subject: [issue20430] Make argparse.SUPPRESS work as an argument "dest" In-Reply-To: <1390963954.16.0.426686215118.issue20430@psf.upfronthosting.co.za> Message-ID: <1401312588.73.0.687668039207.issue20430@psf.upfronthosting.co.za> paul j3 added the comment: In the attached file I tried another approach - a custom Action class. It gives you the custom behavior now, instead of 2-3 releases in the future. class Action2(Action): # custom action def __init__(self, *args, **kwargs): super(Action2, self).__init__(*args, **kwargs) self.default = SUPPRESS def __call__(self, parser, namespace, values, option_string=None): print('Action2', argparse._get_action_name(self), values) 'self.default=SUPPRESS' keeps the dest out of the namespace without affecting help display. And as with '_HelpAction', the __call__ can do its own thing without modifying the namespace. One thing that this custom Action class does not do well is let you modify the handling of the argument after it is created. For example if an argument is created by an imported parent parser, attributes like 'dest' and 'default' can be changed after the fact, but the argument class can't. In http://bugs.python.org/issue14191 I wrestled with the issue of temporarily disabling subsets of the arguments, first the positionals, and then the optionals, so I could run 'parse_known_args' separately on the two groups. For optionals it was enough to ensure that 'required=False'. For positionals I first used 'nargs=0', and latter enabled a 'nargs=SUPPRESS' option to suppress them. ---------- Added file: http://bugs.python.org/file35389/issue20430.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:37:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 21:37:06 +0000 Subject: [issue1641] asyncore delayed calls feature In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za> Message-ID: <1401313026.09.0.66631632534.issue1641@psf.upfronthosting.co.za> STINNER Victor added the comment: asyncore documentation now starts with this note (which was approved by the asyncore maintainer): "This module exists for backwards compatibility only. For new code we recommend using asyncio." Since asyncio is now part of the stdlib, I don't think that it's worth to enhance asyncore. asyncore has design flaws like its poll() function which doesn't scale well with the number of file descriptors. The latest patch for this issue was written 5 years ago, I don't think that many people are waiting for this feature in asyncore. Delayed calls are part of asyncio core, it's well designed and *efficient*. So I'm now closing this issue. "Upgrade" your code to asyncio! ---------- nosy: +haypo resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:44:33 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 21:44:33 +0000 Subject: [issue777588] asyncore is broken for windows if connection is refused Message-ID: <1401313473.14.0.191150728948.issue777588@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue was opened 11 years ago, when Windows 95, 98, Me, 2000 and XP were used. Python is going to drop support of Windows XP, and most older versions are already no more supported. Does this issue still exist in recent Windows versions? I'm not aware of such bug. Does asyncio have the bug? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:45:45 2014 From: report at bugs.python.org (paul j3) Date: Wed, 28 May 2014 21:45:45 +0000 Subject: [issue21208] Change default behavior of arguments with type bool when options are specified In-Reply-To: <1397339884.4.0.416428545862.issue21208@psf.upfronthosting.co.za> Message-ID: <1401313545.8.0.901584104144.issue21208@psf.upfronthosting.co.za> paul j3 added the comment: In http://bugs.python.org/issue11588#msg212243 I explore the option of using decorators to 'register' custom functions with the parser. There I was adding exclusive/inclusive tests, but the same approach could be used to register custom types and actions. I should start a new issue re. documenting the use of 'register'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:47:11 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 28 May 2014 21:47:11 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401313631.0.0.660443299821.issue1683368@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Based on the example above, I've created a blog post to publish my recommendation for overriding these special methods in a way that's safe regardless of the parent implementation, given the status quo: http://blog.jaraco.com/2014/05/how-to-safely-override-init-or-new-in.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:47:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 21:47:53 +0000 Subject: [issue21119] asyncio create_connection resource warning In-Reply-To: <1396321484.68.0.174945090803.issue21119@psf.upfronthosting.co.za> Message-ID: <1401313673.6.0.417819827761.issue21119@psf.upfronthosting.co.za> STINNER Victor added the comment: Can someone review close-3.patch please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:53:02 2014 From: report at bugs.python.org (Maciej Szulik) Date: Wed, 28 May 2014 21:53:02 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1401313982.64.0.116408809122.issue19662@psf.upfronthosting.co.za> Maciej Szulik added the comment: I'm attaching file issue19662_v1.patch. David please have a look at it and let me know if this is it, if not I'm waiting for your suggestions. ---------- Added file: http://bugs.python.org/file35390/issue19662_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 28 23:56:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 21:56:52 +0000 Subject: [issue21252] Lib/asyncio/events.py has tons of docstrings which are just "XXX" In-Reply-To: <1397662454.57.0.604020798852.issue21252@psf.upfronthosting.co.za> Message-ID: <1401314212.26.0.757987212156.issue21252@psf.upfronthosting.co.za> STINNER Victor added the comment: A first patch to fill remaining XXX docstring of events.py. ---------- keywords: +patch Added file: http://bugs.python.org/file35391/asyncio_events_docstring.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:05:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 May 2014 22:05:25 +0000 Subject: [issue21376] asyncio docs refer to wrong TimeoutError In-Reply-To: <1398708357.06.0.922465155945.issue21376@psf.upfronthosting.co.za> Message-ID: <3gf5h41nYzz7Lmy@mail.python.org> Roundup Robot added the comment: New changeset 6d90e8df01f4 by Victor Stinner in branch '3.4': Issue #21376: document asyncio.TimeoutError http://hg.python.org/cpython/rev/6d90e8df01f4 New changeset 03bb1077b362 by Victor Stinner in branch 'default': (Merge 3.4) Issue #21376: document asyncio.TimeoutError http://hg.python.org/cpython/rev/03bb1077b362 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:06:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 22:06:16 +0000 Subject: [issue21376] asyncio docs refer to wrong TimeoutError In-Reply-To: <1398708357.06.0.922465155945.issue21376@psf.upfronthosting.co.za> Message-ID: <1401314776.82.0.45437489908.issue21376@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks for the report. In fact, asyncio.TimeoutError was not documented at all. It should now be fixed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:07:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 22:07:10 +0000 Subject: [issue21443] asyncio logging documentation clarifications In-Reply-To: <1399321197.68.0.955361534546.issue21443@psf.upfronthosting.co.za> Message-ID: <1401314830.26.0.0754941729479.issue21443@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:09:03 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 28 May 2014 22:09:03 +0000 Subject: [issue21443] asyncio logging documentation clarifications In-Reply-To: <1399321197.68.0.955361534546.issue21443@psf.upfronthosting.co.za> Message-ID: <1401314943.71.0.237865247857.issue21443@psf.upfronthosting.co.za> Guido van Rossum added the comment: Good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:19:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 May 2014 22:19:21 +0000 Subject: [issue21454] asyncio's loop.connect_read_pipe makes pipes non-blocking contrary to the documentation In-Reply-To: <1399575906.07.0.344601032189.issue21454@psf.upfronthosting.co.za> Message-ID: <3gf6086X0zz7Ljy@mail.python.org> Roundup Robot added the comment: New changeset 16f399588b2a by Victor Stinner in branch '3.4': Issue #21454: Fix asyncio.BaseEventLoop.connect_read_pipe doc http://hg.python.org/cpython/rev/16f399588b2a New changeset 8391f99208f6 by Victor Stinner in branch 'default': (Merge 3.4) Issue #21454: Fix asyncio.BaseEventLoop.connect_read_pipe doc http://hg.python.org/cpython/rev/8391f99208f6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:20:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 22:20:03 +0000 Subject: [issue21454] asyncio's loop.connect_read_pipe makes pipes non-blocking contrary to the documentation In-Reply-To: <1399575906.07.0.344601032189.issue21454@psf.upfronthosting.co.za> Message-ID: <1401315603.86.0.538572889712.issue21454@psf.upfronthosting.co.za> STINNER Victor added the comment: Yes, the documentation was wrong. It should now be fixed. Thanks for the report. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:25:29 2014 From: report at bugs.python.org (Milan Oberkirch) Date: Wed, 28 May 2014 22:25:29 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1401315929.64.0.353617069031.issue15014@psf.upfronthosting.co.za> Milan Oberkirch added the comment: Done. ---------- Added file: http://bugs.python.org/file35392/smtplib_auth.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:28:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 22:28:54 +0000 Subject: [issue13451] sched.py: speedup cancel() method In-Reply-To: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za> Message-ID: <1401316134.44.0.175065366651.issue13451@psf.upfronthosting.co.za> STINNER Victor added the comment: > Serhiy, perhaps it would be useful to see if such optimizations can apply to Tulip's (or asyncio's) event loop, since it will probably be the new standard in 3.4. asyncio was designed differently. Cancelling a task doesn't remove it from a list of pending tasks. Cancelled tasks are just skipped when the event loop executes tasks. If you look more closely, a "task" can be a Handle, Future or Task object. A Handle object has a _cancelled attribute, its cancel() method just sets this attribute to True. It's almost the same for a Future object. In the context of a Task object, cancel() is very different because it sends a CancelledError exception into the running code. I see no possible optimization here. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:29:06 2014 From: report at bugs.python.org (Milan Oberkirch) Date: Wed, 28 May 2014 22:29:06 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1401316146.37.0.259864396682.issue15014@psf.upfronthosting.co.za> Changes by Milan Oberkirch : ---------- nosy: +jesstess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:30:35 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 28 May 2014 22:30:35 +0000 Subject: [issue21580] PhotoImage(data=...) apparently has to be UTF-8 or Base-64 encoded In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za> Message-ID: <1401316235.79.0.72789168359.issue21580@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for looking at this. Originally the issue was found by reading the GIF and PNG images on various web pages, such as . However I was also able to produce the problem with the other formats of that Python logo: $ python3 -Wall -bt Python 3.4.1 (default, May 19 2014, 17:40:19) [GCC 4.9.0 20140507 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import tkinter; tk = tkinter.Tk(); text = tkinter.Text(tk); text.pack() >>> with open("/lib/python3.4/test/imghdrdata/python.png", "rb") as file: data = file.read() ... >>> image = tkinter.PhotoImage(format="png", data=data) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/tkinter/__init__.py", line 3384, in __init__ Image.__init__(self, 'photo', name, cnf, master, **kw) File "/usr/lib/python3.4/tkinter/__init__.py", line 3340, in __init__ self.tk.call(('image', 'create', imgtype, name,) + options) _tkinter.TclError: CRC check failed >>> u8png = tkinter.PhotoImage(format="png", data=data.decode("latin-1").encode("utf-8")) >>> text.image_create(tkinter.END, image=u8png) 'pyimage2' The same problem occurs with the PGM and PPM logos, and the Base-64 encoding trick does not work with those; only UTF-8 encoding. However as you discovered, the GIF format logo works no problem when passed unencoded, although it continues to work if I use my UTF-8 encoding trick, which is a bit strange. Perhaps the internal UTF-8 decoding step is passing the invalid UTF-8 straight through? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:50:24 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 28 May 2014 22:50:24 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1401317424.42.0.325028596802.issue17172@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 0. My general interest is in running external programs and in particular, for this issue, python modules intended to be run as main. Some other scripts I would like to be able to easily launch from Idle include List/test.test_idle.py, Tools/Scripts/patchcheck.py, and a possible 'idle_tour.py' (in progress) that would be a live demo/tutorial of some Idle widgets and functions. I would like the list to be user-configurable for other choices. 1. As with any python script, turtledemo can be run now, without modification, in a separate process, asynchronously, from within idle, by loading the file into an editor window and selecting Run / Run Module or hitting F5. Communication and cleanup issues are already solved. Having output appear in the Shell window obviates the need for a separate console window to receive output, keeps it visible even after the external process quits. One thing that remains impossible is to run two separate modules at the same time. A possible inplementation of 'easy to launch' would be to load turtledemo.py into an editor window and generate a '<>' event. This, of course, does more than is needed and has the danger of a user accidentally overwriting the original module code. An alternative would be a stripped down version of ScriptBinding.ScriptBinding._run_module_event. 2. This feature should be implemented as an extension rather than being 'baked' into Idle. Run-module itself is an extension (ScriptBinding.py), as are several other functions (see config-extensions.def). A possible name would be 'external_module.py' An advantage of an extension is that it can be turned off if someone, such as a college course instructor, does not like it present. This change could be made before considering point 1. I would like to have one extension that could handle multiple external modules listed in the config entry. After reading config-bindings.def and some of the extension files, especially RstripExtension.py, I believe this is possible. However, I would expect to add this after there is a patch just for turtledemo. 3. If Run were on the menu of Shell windows, that would be the appropriate place for 'run external module' as opposed 'run editor module'. This would be especially true with multiple entries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:54:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 28 May 2014 22:54:28 +0000 Subject: [issue18141] tkinter.Image.__del__ can throw an exception if module globals are destroyed in the wrong order In-Reply-To: <1370434176.62.0.932474289882.issue18141@psf.upfronthosting.co.za> Message-ID: <1401317668.48.0.784955020646.issue18141@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:56:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 22:56:54 +0000 Subject: [issue21326] asyncio: request clearer error message when event loop closed In-Reply-To: <1398154363.0.0.853788262895.issue21326@psf.upfronthosting.co.za> Message-ID: <1401317814.81.0.329353101683.issue21326@psf.upfronthosting.co.za> STINNER Victor added the comment: I proposed a patch upstream (in Tulip) to solve this issue: http://code.google.com/p/tulip/issues/detail?id=169 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 00:57:52 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 28 May 2014 22:57:52 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1401317872.06.0.391759759804.issue1683368@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hrm. I've always thought that the key point of cooperative MI was the term *cooperative*. Consider a regular (non-constructor) method. You must have a common base class that defines this method, and *that* method shouldn't be calling the super-method (because there isn't one). All cooperative classes extending this method must derive from that base class. It's the same for __init__ and __new__, except that you may treat each (keyword) argument as a separate method. But you must still have a point in the tree to "eat" that argument, and that point must not pass it up the super call chain. If in a particular framework you want unrecognized keyword arguments to the constructor to be ignored, you should define a common base class from which all your cooperative subclasses inherit. But given the prevalence of *single* inheritance, 'object' shouldn't be that common base class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 01:08:32 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 May 2014 23:08:32 +0000 Subject: [issue21252] Lib/asyncio/events.py has tons of docstrings which are just "XXX" In-Reply-To: <1397662454.57.0.604020798852.issue21252@psf.upfronthosting.co.za> Message-ID: <1401318512.13.0.797542943067.issue21252@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch to address Guido's remarks. FYI I copied the documentation from the Doc repository and Lib/asyncio/unix_events.py (for "child watchers"), and so I copied typos :-) I tried to fix all copies of the documentation in my new patch. I didn't mention the API of a "child watcher" because the class is not documented yet... nor get_child_watcher and set_child_watcher functions! (I mean not documented in the Doc/ directory). I suggest to open a new issue to enhance the documentation of this part of the part. ---------- Added file: http://bugs.python.org/file35393/asyncio_events_docstring-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 01:44:14 2014 From: report at bugs.python.org (Lita Cho) Date: Wed, 28 May 2014 23:44:14 +0000 Subject: [issue21585] Run Tkinter tests with wantobjects=False In-Reply-To: <1401137639.41.0.24885887123.issue21585@psf.upfronthosting.co.za> Message-ID: <1401320654.15.0.919943966393.issue21585@psf.upfronthosting.co.za> Lita Cho added the comment: So I don't know what the best way to do this, but I changed the widget_tests.py in order to set tkinter.wantobjects = 0 if a 'wantobjects' flag was passed through test.support.use_resources. Then I added a new test called test_ttk_guionly_wantobj, where it turns on wantobjects. If we create a new module, then we start off with a clean tkinter object. Before I go this route for all the tests, I wanted to make sure if this was the correct way to go about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 01:45:48 2014 From: report at bugs.python.org (Lita Cho) Date: Wed, 28 May 2014 23:45:48 +0000 Subject: [issue21585] Run Tkinter tests with wantobjects=False In-Reply-To: <1401137639.41.0.24885887123.issue21585@psf.upfronthosting.co.za> Message-ID: <1401320748.04.0.937794686479.issue21585@psf.upfronthosting.co.za> Lita Cho added the comment: Patches lived in my Linux machine. I've attached my patch. I will add my module next. ---------- keywords: +patch Added file: http://bugs.python.org/file35394/test_wantobj.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 01:46:33 2014 From: report at bugs.python.org (Lita Cho) Date: Wed, 28 May 2014 23:46:33 +0000 Subject: [issue21585] Run Tkinter tests with wantobjects=False In-Reply-To: <1401137639.41.0.24885887123.issue21585@psf.upfronthosting.co.za> Message-ID: <1401320793.3.0.894198712677.issue21585@psf.upfronthosting.co.za> Changes by Lita Cho : Added file: http://bugs.python.org/file35395/test_ttk_guionly_wantobj.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 01:49:25 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 28 May 2014 23:49:25 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401288209.47.0.701632345557.issue21592@psf.upfronthosting.co.za> Message-ID: <20140528234907.GD10355@ando> Steven D'Aprano added the comment: On Wed, May 28, 2014 at 02:43:29PM +0000, Thomas Dybdahl Ahle wrote: > I have written some proof of concept code here [1], I would appreciate > you commenting on it, before I turn it into a patch, as I haven't > contributed code to Python before. Thanks Thomas! I will try to look at this over the weekend (today is Thursday my time). If I haven't responded by Monday your time, please feel free to send me a reminder. > I have tried to write it as efficiently as possible, but it is of > course possible that the c-implemented `sorted()` code will be faster > than even the smartest python-implemented select. My quick-and-dirty tests suggest that you need at least 10 million items in the list before a pure Python median-of-median algorithm is as fast as the median algorithm based on sorting in C. > [1]: http://pastebin.com/30x0j39a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 03:21:55 2014 From: report at bugs.python.org (Graham Oliver) Date: Thu, 29 May 2014 01:21:55 +0000 Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII characters In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za> Message-ID: <1401326515.18.0.925543737845.issue3991@psf.upfronthosting.co.za> Graham Oliver added the comment: hello I came across this bug when using '?' in a url To get around the problem I used the 'URL encoded' version '%C4%81' instead of '?' See this page http://www.charbase.com/0101-unicode-latin-small-letter-a-with-macron I tried using the 'puny code' for '?' 'xn--yda' but that didn't work ---------- nosy: +Graham.Oliver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 04:18:10 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Thu, 29 May 2014 02:18:10 +0000 Subject: [issue21598] Is __getitem__ and __len__ implementations enough to make a user-defined class sliceable? Message-ID: <1401329890.84.0.11879897607.issue21598@psf.upfronthosting.co.za> New submission from Santoso Wijaya: The reference doc for Python data model says that __getslice__ is deprecated [1], and that __getitem__ should be used instead: """ Deprecated since version 2.0: Support slice objects as parameters to the __getitem__() method. (However, built-in types in CPython currently still implement __getslice__(). Therefore, you have to override it in derived classes when implementing slicing.) """ But I'm getting the following behavior when I try it myself. Is there something I'm missing? $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class tup(object): ... def __getitem__(self, i): ... if i == 0: return 0 ... if i == 1: return 1 ... KeyboardInterrupt >>> class tup(object): ... def __getitem__(self, i): ... if i in (0, 1): return i ... else: raise IndexError() ... def __len__(self): ... return 2 ... >>> t = tup() >>> len(t) 2 >>> t[0], t[1] (0, 1) >>> t[:2] Traceback (most recent call last): File "", line 1, in File "", line 4, in __getitem__ IndexError >>> t[:1] Traceback (most recent call last): File "", line 1, in File "", line 4, in __getitem__ IndexError [1] https://docs.python.org/2/reference/datamodel.html#object.__getslice__ ---------- components: Library (Lib) messages: 219326 nosy: santa4nt priority: normal severity: normal status: open title: Is __getitem__ and __len__ implementations enough to make a user-defined class sliceable? type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 04:25:23 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Thu, 29 May 2014 02:25:23 +0000 Subject: [issue21598] Is __getitem__ and __len__ implementations enough to make a user-defined class sliceable? In-Reply-To: <1401329890.84.0.11879897607.issue21598@psf.upfronthosting.co.za> Message-ID: <1401330323.6.0.724092614181.issue21598@psf.upfronthosting.co.za> Santoso Wijaya added the comment: Hm. The docstring for __getitem__ doesn't mention it can/should be accepting slice object as argument. That's what I'm missing. Doc patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 04:29:08 2014 From: report at bugs.python.org (Santoso Wijaya) Date: Thu, 29 May 2014 02:29:08 +0000 Subject: [issue21598] Is __getitem__ and __len__ implementations enough to make a user-defined class sliceable? In-Reply-To: <1401329890.84.0.11879897607.issue21598@psf.upfronthosting.co.za> Message-ID: <1401330548.42.0.995052396223.issue21598@psf.upfronthosting.co.za> Changes by Santoso Wijaya : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 05:16:17 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 29 May 2014 03:16:17 +0000 Subject: [issue21599] Argument transport in attach and detach method in Server class in base_events file is not used Message-ID: <1401333377.1.0.573803029837.issue21599@psf.upfronthosting.co.za> New submission from Vajrasky Kok: In Lib/asyncio/base_events.py, we have these lines of code: ----------------------------------------------------------- def attach(self, transport): assert self.sockets is not None self.active_count += 1 def detach(self, transport): assert self.active_count > 0 self.active_count -= 1 if self.active_count == 0 and self.sockets is None: self._wakeup() ------------------------------------------------------------ The transport is not used. We can remove them. Here is the patch to remove the arguments. If for higher philosophical reason, we need this unused argument, maybe we can comment it. ---------- components: Library (Lib) files: remove_transport_in_base_events.patch keywords: patch messages: 219328 nosy: haypo, vajrasky priority: normal severity: normal status: open title: Argument transport in attach and detach method in Server class in base_events file is not used type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file35396/remove_transport_in_base_events.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 05:25:38 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 29 May 2014 03:25:38 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1401333938.46.0.172364372216.issue21592@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Yeah, I remember I tried to improve the performance of the median in the past using median-of-k algorithm. But too bad I could not beat sorted C function efficiency. Maybe you have a better luck! ---------- nosy: +vajrasky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 05:34:52 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 29 May 2014 03:34:52 +0000 Subject: [issue17172] Add turtledemo to IDLE menu In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za> Message-ID: <1401334492.67.0.943433016493.issue17172@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I withdraw my suggestion that turtledemo get anything added just for moving code to Idle. What is does need is the ability to widen the code pane so one can more easily read or cut (by normal means). See #21597. One of my concerns about putting turtledemo on the Idle menu is that people will see it as part of Idle. Fine it it works well ;-). Not so fine if it does not. The solution is to fix any important current problems. #18132 (buttons disappear on small screens) has a patch that fixes the problem but creates another. I have not yet looked at the other open turtledemo issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 05:35:28 2014 From: report at bugs.python.org (fumihiko kakuma) Date: Thu, 29 May 2014 03:35:28 +0000 Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules Message-ID: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za> New submission from fumihiko kakuma: It seems that stopall doesn't work when do start patch.dict to sys.modules. I show sample scripts the following. Using stopall test case seems to always refer the first mock foo object. But using stop it refers a new mock foo object. $ cat test_sampmod.py import foo def myfunc(): print "myfunc foo=%s" % foo return foo $ cat test_samp.py import mock import sys import unittest class SampTestCase(unittest.TestCase): def setUp(self): self.foo_mod = mock.Mock() self.m = mock.patch.dict('sys.modules', {'foo': self.foo_mod}) self.p = self.m.start() print "foo_mod=%s" % self.foo_mod __import__('test_sampmod') self.test_sampmod = sys.modules['test_sampmod'] def tearDown(self): if len(sys.argv) > 1: self.m.stop() print ">>> stop patch" else: mock.patch.stopall() print ">>> stopall patch" def test_samp1(self): self.assertEqual(self.foo_mod, self.test_sampmod.myfunc()) def test_samp2(self): self.assertEqual(self.foo_mod, self.test_sampmod.myfunc()) def test_samp3(self): self.assertEqual(self.foo_mod, self.test_sampmod.myfunc()) if __name__ == '__main__': suite = unittest.TestSuite() suite.addTest(unittest.TestLoader().loadTestsFromTestCase(SampTestCase)) unittest.TextTestRunner(verbosity=2).run(suite) $ python test_samp.py stop test_samp1 (__main__.SampTestCase) ... foo_mod= myfunc foo= >>> stop patch ok test_samp2 (__main__.SampTestCase) ... foo_mod= myfunc foo= >>> stop patch ok test_samp3 (__main__.SampTestCase) ... foo_mod= myfunc foo= >>> stop patch ok ---------------------------------------------------------------------- Ran 3 tests in 0.004s OK $ python test_samp.py test_samp1 (__main__.SampTestCase) ... foo_mod= myfunc foo= >>> stopall patch ok test_samp2 (__main__.SampTestCase) ... foo_mod= myfunc foo= FAIL >>> stopall patch test_samp3 (__main__.SampTestCase) ... foo_mod= myfunc foo= FAIL >>> stopall patch ====================================================================== FAIL: test_samp2 (__main__.SampTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_samp.py", line 27, in test_samp2 self.assertEqual(self.foo_mod, self.test_sampmod.myfunc()) AssertionError: != ====================================================================== FAIL: test_samp3 (__main__.SampTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_samp.py", line 30, in test_samp3 self.assertEqual(self.foo_mod, self.test_sampmod.myfunc()) AssertionError: != ---------------------------------------------------------------------- Ran 3 tests in 0.003s FAILED (failures=2) $ ---------- components: Tests messages: 219331 nosy: kakuma priority: normal severity: normal status: open title: mock.patch.stopall doesn't work with patch.dict to sys.modules type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 06:39:16 2014 From: report at bugs.python.org (paul j3) Date: Thu, 29 May 2014 04:39:16 +0000 Subject: [issue9351] argparse set_defaults on subcommands should override top level set_defaults In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za> Message-ID: <1401338356.33.0.292472373621.issue9351@psf.upfronthosting.co.za> paul j3 added the comment: This is not getting much attention for several reasons: - there's quite a backlog of argparse patches and issues - 'set_defaults' is not commonly used. Setting default in 'add_argument' seems more common. - defining the same argument for both the parser and subparser can create other difficulties. - in Bethard's example, 'set_default' sets an attribute that has no connection to any argument. It's a cleaver trick that few users will think to use, and probably won't be of much value. The idea proposed here of using a subnamespace for the subparser is interesting. It reminds me of a StackOverflow question about implementing nested namespaces. http://stackoverflow.com/questions/18668227 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 07:08:32 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 29 May 2014 05:08:32 +0000 Subject: [issue21601] Cancel method for Asyncio Task is not documented Message-ID: <1401340112.56.0.394123736.issue21601@psf.upfronthosting.co.za> New submission from Vajrasky Kok: https://docs.python.org/3.5/library/asyncio-task.html#task The cancel method is not documented although it is a part of public API. Here is the patch to fix the doc. ---------- assignee: docs at python components: Documentation files: fix_doc_asyncio_task.patch keywords: patch messages: 219333 nosy: docs at python, haypo, vajrasky priority: normal severity: normal status: open title: Cancel method for Asyncio Task is not documented versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35397/fix_doc_asyncio_task.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 07:44:38 2014 From: report at bugs.python.org (Syou Ei) Date: Thu, 29 May 2014 05:44:38 +0000 Subject: [issue21602] smtplib.py socket.create_connection() also doesn't handle EINTR properly Message-ID: <1401342278.7.0.65197779911.issue21602@psf.upfronthosting.co.za> New submission from Syou Ei: The smtplib.py also has the same problem. The EINTR cannot be handled properly. 2014-05-21 19:20:15,631 ERROR actions: Notification 'socket_noti' FAILED to send emails to set(['mailtest at tscoss.com']): - [Errno 4] Interrupted system calltrace:Traceback (most recent call last): File "Utils.py", line 719, in sendEmail server = smtplib.SMTP(host, port, timeout=DEFAULT_SOCKET_TIMEOUT) File "/opt/zenoss/lib/python2.7/smtplib.py", line 242, in __init__ (code, msg) = self.connect(host, port) File "/opt/zenoss/lib/python2.7/smtplib.py", line 302, in connect self.sock = self._get_socket(host, port, self.timeout) File "/opt/zenoss/lib/python2.7/smtplib.py", line 277, in _get_socket return socket.create_connection((port, host), timeout) File "/opt/zenoss/lib/python2.7/Write failed: Broken pipecreate_connection ---------- components: Library (Lib) messages: 219334 nosy: flox, gregory.p.smith, haypo, meishao, neologix, pitrou, tholzer priority: normal severity: normal status: open title: smtplib.py socket.create_connection() also doesn't handle EINTR properly type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 07:47:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 29 May 2014 05:47:14 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <3gfHww0VvFz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 90dab7696e89 by Terry Jan Reedy in branch '2.7': Issue #21477: Add htests for GrepDialog, UndoDelegator, and configDialog. http://hg.python.org/cpython/rev/90dab7696e89 New changeset d90905960803 by Terry Jan Reedy in branch '3.4': Issue #21477: Add htests for GrepDialog, UndoDelegator, and configDialog. http://hg.python.org/cpython/rev/d90905960803 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 07:57:35 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 29 May 2014 05:57:35 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401343055.29.0.907438871489.issue21477@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, this patch includes a call to macosxSupport. _initializeTkVariantTests(root) in htest.run. Does this work on mac or is something else needed (like doing the same for individual tests that create another root)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 08:02:16 2014 From: report at bugs.python.org (Syou Ei) Date: Thu, 29 May 2014 06:02:16 +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: <1401343336.24.0.404623905928.issue20611@psf.upfronthosting.co.za> Syou Ei added the comment: http://bugs.python.org/issue21602 The smtplib.py also has the same problem. The EINTR cannot be handled properly. ---------- nosy: +meishao _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 09:41:12 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 May 2014 07:41:12 +0000 Subject: [issue21603] IDLE SaveAs drops the extension in the prompted filename Message-ID: <1401349272.89.0.982652468131.issue21603@psf.upfronthosting.co.za> New submission from Raymond Hettinger: In IDLE, edit and save a file foo.py. Then choose File SaveAs. The dialog box only shows "foo", not "foo.py" which is irritating when renaming a file or saving a variant of a file. ---------- components: IDLE messages: 219338 nosy: rhettinger priority: normal severity: normal status: open title: IDLE SaveAs drops the extension in the prompted filename type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 09:43:30 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 29 May 2014 07:43:30 +0000 Subject: [issue21602] smtplib.py socket.create_connection() also doesn't handle EINTR properly In-Reply-To: <1401342278.7.0.65197779911.issue21602@psf.upfronthosting.co.za> Message-ID: <1401349410.09.0.201955976594.issue21602@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: If you know it's a duplicate, why create a new issue? ---------- resolution: -> duplicate status: open -> closed superseder: -> socket.create_connection() doesn't handle EINTR properly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 10:30:17 2014 From: report at bugs.python.org (Syou Ei) Date: Thu, 29 May 2014 08:30:17 +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: <1401352217.2.0.0741620215983.issue20611@psf.upfronthosting.co.za> Syou Ei added the comment: @neologix, May I attach the patch file of smtplib.py for review? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 10:32:46 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 May 2014 08:32:46 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1401352366.7.0.618305119928.issue13742@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file35398/keymerge2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 10:41:08 2014 From: report at bugs.python.org (=?utf-8?q?Wilfried_L=C3=BCbbe?=) Date: Thu, 29 May 2014 08:41:08 +0000 Subject: [issue21604] Misleading 2to3 fixer name in documentation: standard_error Message-ID: <1401352868.06.0.396054178232.issue21604@psf.upfronthosting.co.za> New submission from Wilfried L?bbe: The documentation https://docs.python.org/2/library/2to3.html#2to3fixer-standard_error calls the fixer "standard_error". But really its name is "standarderror" (the filename is "fix_standarderror.py"). Py3.4.1 and Py3.4 docs are the same: https://docs.python.org/3.4/library/2to3.html#2to3fixer-standard_error https://docs.python.org/3.5/library/2to3.html#2to3fixer-standard_error ---------- assignee: docs at python components: Documentation messages: 219341 nosy: docs at python, wluebbe priority: normal severity: normal status: open title: Misleading 2to3 fixer name in documentation: standard_error versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 10:42:00 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 May 2014 08:42:00 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1401352920.4.0.666009663953.issue13742@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Removed file: http://bugs.python.org/file35398/keymerge2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 10:42:18 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 May 2014 08:42:18 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1401352938.54.0.820394953251.issue13742@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file35399/keymerge2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 10:48:59 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Thu, 29 May 2014 08:48:59 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1401353339.75.0.244548632828.issue21590@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: I'd really prefer IRC, if at all possible for you :) When online, I'm usually on #fedora-python, but I can really come any channel of your choice. Sorry for the delays in communication, I've got a lot on my plate right now and I'll probably not be very quick to respond ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 11:26:53 2014 From: report at bugs.python.org (Florent Xicluna) Date: Thu, 29 May 2014 09:26:53 +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: <1401355613.03.0.253982741956.issue20611@psf.upfronthosting.co.za> Florent Xicluna added the comment: @meishao Previous comments answer your question : http://bugs.python.org/issue20611#msg218836 http://bugs.python.org/issue20611#msg218841 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 12:18:07 2014 From: report at bugs.python.org (Syou Ei) Date: Thu, 29 May 2014 10:18:07 +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: <1401358687.3.0.954204108248.issue20611@psf.upfronthosting.co.za> Syou Ei added the comment: @flox Thank you for your comment. So we just only modify the socket.py to handle the system level call, is it right? Please let me attach the patch file of socket.py for 2.7.2. ---------- Added file: http://bugs.python.org/file35400/socket_2_7_2_patch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 16:22:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 May 2014 14:22:43 +0000 Subject: [issue21605] Add tests for Tkinter images Message-ID: <1401373363.46.0.186205839089.issue21605@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds tests for tkinter's classes BitmapImage and PhotoImage. Some tests are temporary skipped until resolving issue21580. ---------- assignee: serhiy.storchaka components: Tests, Tkinter files: tkinter_test_images.patch keywords: patch messages: 219345 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add tests for Tkinter images type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35401/tkinter_test_images.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 16:27:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 May 2014 14:27:25 +0000 Subject: [issue21580] PhotoImage(data=...) apparently has to be UTF-8 or Base-64 encoded In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za> Message-ID: <1401373645.46.0.279309018312.issue21580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which fixes passing Python bytes to Tcl in Python 3. However it will be not easy to fix this issue in Python 2. See also issue21605 which adds tests for Tkinter images (some of them fails without this patch). ---------- assignee: docs at python -> serhiy.storchaka dependencies: +Add tests for Tkinter images keywords: +patch stage: test needed -> patch review type: -> behavior versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file35402/tkinter_bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 16:51:55 2014 From: report at bugs.python.org (rovf) Date: Thu, 29 May 2014 14:51:55 +0000 Subject: [issue21606] No visual feedback when entering japanese Characters in Entry widget Message-ID: <1401375115.8.0.444639953801.issue21606@psf.upfronthosting.co.za> New submission from rovf: When I enter Japanese text in a tkinter entry widget, I don't get any visual feedback while typing; in particular, I don't get the Kanji selection box of the Kotaeri input method, which makes it impossible to choose the correct Kanji (try, for example, to type the words ??, ?? and ?? in a tkinter entry field). The only possibility is to enter the text in, say, a text editor and then copy them to the tkinter entry widget. The error is specific to Mac OSX (at least to version 10.6). It does not occur on Windows. ---------- components: Tkinter messages: 219347 nosy: rovf priority: normal severity: normal status: open title: No visual feedback when entering japanese Characters in Entry widget type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 18:20:10 2014 From: report at bugs.python.org (Sasha Ovsankin) Date: Thu, 29 May 2014 16:20:10 +0000 Subject: [issue21607] results of `zip` are displayed as ' Message-ID: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za> New submission from Sasha Ovsankin: Python 3.4.0 (default, May 20 2014, 20:42:24) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> zip([1, 2, 3], ["a", "b", "c"]) >>> Python 2.7.5 (default, Mar 9 2014, 22:15:05) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> zip([1, 2, 3], ["a", "b", "c"]) [(1, 'a'), (2, 'b'), (3, 'c')] ---------- components: Library (Lib) messages: 219348 nosy: Sasha.Ovsankin priority: normal severity: normal status: open title: results of `zip` are displayed as ' versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 18:24:35 2014 From: report at bugs.python.org (SilentGhost) Date: Thu, 29 May 2014 16:24:35 +0000 Subject: [issue21607] results of `zip` are displayed as ' In-Reply-To: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za> Message-ID: <1401380675.07.0.290912819836.issue21607@psf.upfronthosting.co.za> SilentGhost added the comment: This is the correct behaviour. In python 3 zip returns an iterator. Detailed information is available in documentation. https://docs.python.org/3/library/functions.html#zip ---------- nosy: +SilentGhost resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 18:38:53 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 29 May 2014 16:38:53 +0000 Subject: [issue21607] results of `zip` are displayed as ' In-Reply-To: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za> Message-ID: <1401381533.26.0.0146983524721.issue21607@psf.upfronthosting.co.za> Eric Snow added the comment: It may be the correct behavior but that doesn't mean we cannot update the repr to be more informative. We've already done that for a number of types that previously used the default __repr__() implementation. So in the case, how hard would it be to have the following repr? >>> zip([1, 2, 3], ["a", "b", "c"]) zip([1, 2, 3], ["a", "b", "c"]) ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 19:03:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 May 2014 17:03:16 +0000 Subject: [issue21607] results of `zip` are displayed as ' In-Reply-To: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za> Message-ID: <1401382996.63.0.787676910195.issue21607@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: "zip(, )" doesn't look more readable to me. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 19:08:22 2014 From: report at bugs.python.org (Sasha Ovsankin) Date: Thu, 29 May 2014 17:08:22 +0000 Subject: [issue21607] results of `zip` are displayed as ' In-Reply-To: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za> Message-ID: <1401383302.03.0.312864009198.issue21607@psf.upfronthosting.co.za> Sasha Ovsankin added the comment: It's also showing up in iPython. list(...) is a reasonable workaround but I disagree with the "not a bug" opinion. This is definitely the regression vs Python 2. Who else can I talk to about reopening this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 19:31:39 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 29 May 2014 17:31:39 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1401384699.76.0.766680426052.issue19662@psf.upfronthosting.co.za> R. David Murray added the comment: Added review comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 19:54:08 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 29 May 2014 17:54:08 +0000 Subject: [issue21607] results of `zip` are displayed as ' In-Reply-To: <1401382996.63.0.787676910195.issue21607@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > "zip(, )" doesn't look more readable to me. Well, that seems more informative to me. Now you know that you're zipping together two list iterators. By "readable" do you mean shorter? In my opinion the size of a repr is less of a concern (though not insignificant) than the usefulness of the information the repr contains. The fact that some objects (like list iterators) don't themselves have informative reprs is an issue for any object with a custom repr that reports it's attrs/args. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 20:16:32 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 May 2014 18:16:32 +0000 Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za> Message-ID: <1401387392.76.0.51342598461.issue21600@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 20:33:14 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 May 2014 18:33:14 +0000 Subject: [issue21603] IDLE SaveAs drops the extension in the prompted filename In-Reply-To: <1401349272.89.0.982652468131.issue21603@psf.upfronthosting.co.za> Message-ID: <1401388394.23.0.93328722629.issue21603@psf.upfronthosting.co.za> Ned Deily added the comment: There are known differences among the various Tk implementations with regard to how file extensions are handled in Tk file dialogs, like IDLE uses; see Issue4832. Can you say which version of Tk was in use (it should be in the About IDLE display) and on what platform? I was not able to reproduce this behavior on any of the current OS X IDLEs and Tks with Save As. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 20:44:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 29 May 2014 18:44:15 +0000 Subject: [issue21226] PyImport_ExecCodeModuleObject not setting module attributes In-Reply-To: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za> Message-ID: <3gfd9V22jCz7Lk1@mail.python.org> Roundup Robot added the comment: New changeset baa7b5555656 by Eric Snow in branch '3.4': Issue #21226: fix a ref leak. http://hg.python.org/cpython/rev/baa7b5555656 New changeset 57130574d1e8 by Eric Snow in branch 'default': Issue #21226: Merge from 3.4. http://hg.python.org/cpython/rev/57130574d1e8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 20:50:34 2014 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 29 May 2014 18:50:34 +0000 Subject: [issue21607] results of `zip` are displayed as ' In-Reply-To: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za> Message-ID: <1401389434.86.0.980718004445.issue21607@psf.upfronthosting.co.za> Mark Lawrence added the comment: How do you display the contents of an iterable without using them up, or have I grossly overlooked something? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 20:52:02 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 May 2014 18:52:02 +0000 Subject: [issue21606] No visual feedback when entering japanese Characters in Entry widget In-Reply-To: <1401375115.8.0.444639953801.issue21606@psf.upfronthosting.co.za> Message-ID: <1401389522.75.0.273941839543.issue21606@psf.upfronthosting.co.za> Ned Deily added the comment: tkinter-based apps depend on the underlying Tk widget for text processing. I know nothing about the various Japanese input methods on OS X but, in spot checking of a few, I observed no visual feedback with Katakana selected until I pressed the Return key, at which point all previously unechoed characters appeared. I observed exactly the same behavior when using the Tk-supplied wish (/usr/local/bin/wish8.5 or 8.6) shell text demo. (This was using the most recent ActiveTcl 8.5.15 and 8.6.1 releases.) If you want to pursue the issue, I suggest checking the Tk project issue tracker and, if necessary, opening a new issue there with steps to reproduce using wish. http://core.tcl.tk/tk/reportlist ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 20:59:06 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 29 May 2014 18:59:06 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1401389946.15.0.730752081792.issue21462@psf.upfronthosting.co.za> Zachary Ware added the comment: Steve or Tim, did one of you want to commit this since you can run a clean test? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 21:16:59 2014 From: report at bugs.python.org (Sasha Ovsankin) Date: Thu, 29 May 2014 19:16:59 +0000 Subject: [issue21607] results of `zip` are displayed as ' In-Reply-To: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za> Message-ID: <1401391019.06.0.46440640234.issue21607@psf.upfronthosting.co.za> Sasha Ovsankin added the comment: >>> How do you display the contents of an iterable without using them up <<< In general case you can't, but zip object _is_ reusable iterable so we can reuse it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 21:28:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 May 2014 19:28:05 +0000 Subject: [issue21310] ResourceWarning when open() fails with io.UnsupportedOperation: File or stream is not seekable In-Reply-To: <1397877829.49.0.0015217310404.issue21310@psf.upfronthosting.co.za> Message-ID: <1401391685.72.0.244936765148.issue21310@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which fixes warnings. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file35403/io_open_resource_warning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 21:36:02 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 29 May 2014 19:36:02 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1401392162.64.0.58899274201.issue14097@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 21:36:47 2014 From: report at bugs.python.org (SilentGhost) Date: Thu, 29 May 2014 19:36:47 +0000 Subject: [issue21607] results of `zip` are displayed as ' In-Reply-To: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za> Message-ID: <1401392207.73.0.348992195597.issue21607@psf.upfronthosting.co.za> SilentGhost added the comment: >> How do you display the contents of an iterable without using them up > In general case you can't, but zip object _is_ reusable iterable so we can reuse it? I think you're misunderstanding what an iterator is or how it functions. Just to make it clear, it cannot be "reused". What Eric suggested, was to look at the inputs of zip and construct a representation of zip object that is more user friendly. The point that Serhiy's is making is that its usefulness is actually fairly limited. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 22:36:06 2014 From: report at bugs.python.org (Maciej Szulik) Date: Thu, 29 May 2014 20:36:06 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1401395766.58.0.592531656064.issue19662@psf.upfronthosting.co.za> Maciej Szulik added the comment: I've implemented all your proposed changes, because for most of your changes I was thinking pretty the same way for the whole day today, to make the code more elegant. The current state of work is attached as issue19662_v2.patch ---------- Added file: http://bugs.python.org/file35404/issue19662_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 22:36:54 2014 From: report at bugs.python.org (Sasha Ovsankin) Date: Thu, 29 May 2014 20:36:54 +0000 Subject: [issue21607] results of `zip` are displayed as ' In-Reply-To: <1401380410.21.0.601003685212.issue21607@psf.upfronthosting.co.za> Message-ID: <1401395814.09.0.487371342431.issue21607@psf.upfronthosting.co.za> Sasha Ovsankin added the comment: Yep, you are right. Even the zip thingy is not reusable. Oh well... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 22:43:15 2014 From: report at bugs.python.org (Bikram Zesto II) Date: Thu, 29 May 2014 20:43:15 +0000 Subject: [issue21608] logging.handlers.HTTPHandler.setFormatter() has no effect Message-ID: <1401396195.13.0.00625347928702.issue21608@psf.upfronthosting.co.za> New submission from Bikram Zesto II: HTTPHandler instance will assign a Formatter to format() but emit() never calls self.format(record) so it has no effect. I know mapLogRecord() does something like this now but would like to reuse Formatters across Handlers instead of subclassing HTTPHandler just for HTTP logging. Does it make sense to assign mapLogRecord by default to self.format but allow it to be over-ridden like other Handlers? ---------- components: Library (Lib) messages: 219365 nosy: bk2zsto priority: normal severity: normal status: open title: logging.handlers.HTTPHandler.setFormatter() has no effect type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 23:03:13 2014 From: report at bugs.python.org (Miquel Garcia) Date: Thu, 29 May 2014 21:03:13 +0000 Subject: [issue21609] Documentation for datetime.datetime uses microseconds instead of microsecond Message-ID: <1401397393.28.0.277127762562.issue21609@psf.upfronthosting.co.za> New submission from Miquel Garcia: In browsing the documentation for datetime.datetime: https://docs.python.org/2/library/datetime.html It states that the datetime.datetime.microseconds returns the number of microseconds but in trying (Python 2.7.1 r271:86832): import datetime print datetime.datetime.now().microseconds The interpreter returns AttributeError: 'datetime.datetime' object has no attribute 'microseconds' The correct way to access the number of microseconds is by: datetime.datetime.now().microsecond # Note the final 's' which is not consistent with the documentation. Many thanks Miquel ---------- assignee: docs at python components: Documentation messages: 219366 nosy: Miquel.Garcia, docs at python priority: normal severity: normal status: open title: Documentation for datetime.datetime uses microseconds instead of microsecond versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 23:10:42 2014 From: report at bugs.python.org (mattip) Date: Thu, 29 May 2014 21:10:42 +0000 Subject: [issue21610] load_module not closing opened files Message-ID: <1401397842.84.0.0447434593999.issue21610@psf.upfronthosting.co.za> New submission from mattip: imputil and modulefinder are opening files but not actively closing them. This causes problems for pypy and is not clean. ---------- components: Library (Lib) files: close_fp_2.7.patch keywords: patch messages: 219367 nosy: mattip priority: normal severity: normal status: open title: load_module not closing opened files type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file35405/close_fp_2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 23:13:36 2014 From: report at bugs.python.org (SilentGhost) Date: Thu, 29 May 2014 21:13:36 +0000 Subject: [issue21609] Documentation for datetime.datetime uses microseconds instead of microsecond In-Reply-To: <1401397393.28.0.277127762562.issue21609@psf.upfronthosting.co.za> Message-ID: <1401398016.44.0.953956683284.issue21609@psf.upfronthosting.co.za> SilentGhost added the comment: Could you provide an actual quote where it refers to datetime.datetime.microseconds? Are you not by any chance confusing it with datetime.timedelta.microseconds? ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 23:15:14 2014 From: report at bugs.python.org (mattip) Date: Thu, 29 May 2014 21:15:14 +0000 Subject: [issue21610] load_module not closing opened files In-Reply-To: <1401397842.84.0.0447434593999.issue21610@psf.upfronthosting.co.za> Message-ID: <1401398114.07.0.721485081965.issue21610@psf.upfronthosting.co.za> mattip added the comment: the issue has already been fixed on HEAD but not backported to 2.7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 29 23:18:07 2014 From: report at bugs.python.org (Miquel Garcia) Date: Thu, 29 May 2014 21:18:07 +0000 Subject: [issue21609] Documentation for datetime.datetime uses microseconds instead of microsecond In-Reply-To: <1401397393.28.0.277127762562.issue21609@psf.upfronthosting.co.za> Message-ID: <1401398287.65.0.831510281551.issue21609@psf.upfronthosting.co.za> Miquel Garcia added the comment: My mistake. Yes you are right, I was confused with the timedelta class. Sorry for the confusion. Many thanks! Miquel ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 00:16:11 2014 From: report at bugs.python.org (tholzer) Date: Thu, 29 May 2014 22:16:11 +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: <1401401771.57.0.305794862797.issue20611@psf.upfronthosting.co.za> tholzer added the comment: Oops, I missed a break statement at the end of socket_2.7.3_eintr_patch.py. I've fixed this now in the attached patch. @meishao Could you please also update your socket_2_7_2_patch.py and add the missing break statement ? ---------- Added file: http://bugs.python.org/file35406/socket_2.7.3_eintr_patch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 00:16:50 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 29 May 2014 22:16:50 +0000 Subject: [issue21608] logging.handlers.HTTPHandler.setFormatter() has no effect In-Reply-To: <1401396195.13.0.00625347928702.issue21608@psf.upfronthosting.co.za> Message-ID: <1401401810.19.0.18919948909.issue21608@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 00:16:55 2014 From: report at bugs.python.org (tholzer) Date: Thu, 29 May 2014 22:16:55 +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: <1401401815.15.0.514715289161.issue20611@psf.upfronthosting.co.za> Changes by tholzer : Removed file: http://bugs.python.org/file35359/socket_2.7.3_eintr_patch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 00:27:55 2014 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 29 May 2014 22:27:55 +0000 Subject: [issue21608] logging.handlers.HTTPHandler.setFormatter() has no effect In-Reply-To: <1401396195.13.0.00625347928702.issue21608@psf.upfronthosting.co.za> Message-ID: <1401402475.23.0.272174759739.issue21608@psf.upfronthosting.co.za> Vinay Sajip added the comment: HTTPHandler doesn't exactly format text for output - it encodes the LogRecord fields into an HTTP GET or POST request, and sends that request to a web server. Since this "formatting" is determined by the HTTP protocol, it is not possible to share it with formatting for other destinations (like console or file). I don't think a patch which somehow shoehorns a Formatter into mapLogRecord() will be acceptable, both for reasons of backward compatibility and also because formatting in general is not the same as encoding for HTTP, and trying to push the two things together seems kludgy. I advise you to subclass HttpHandler if its default behaviour doesn't work for you. After all, that's why we have classes in Python :-) ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 02:04:21 2014 From: report at bugs.python.org (Josiah Carlson) Date: Fri, 30 May 2014 00:04:21 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1401408261.24.0.801019155151.issue1191964@psf.upfronthosting.co.za> Josiah Carlson added the comment: I submitted an issue to the tulip/asyncio bug tracker: https://code.google.com/p/tulip/issues/detail?id=170 And I am uploading a new patch that only includes non-tulip/asyncio related changes, as tulip/asyncio changes will eventually be propagated to Python. ---------- Added file: http://bugs.python.org/file35407/subprocess_7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 02:07:47 2014 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 May 2014 00:07:47 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1401408467.98.0.43625307893.issue1191964@psf.upfronthosting.co.za> Guido van Rossum added the comment: FWIW while the Tulip changes should indeed go into the Tulip repo first, the rest should be committed to the CPython 3.5 tree first. Then I'll commit the Tulip changes, first to the Tulip repo, then to the CPython 3.4 branch (yes!) and then merge that into the 3.5 (default) branch. (Yes, I know it's complicated, but it beats other ways of keeping the Tulip and CPython trees in sync. And I have a script in the Tulip tree that automates most of the work.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 03:01:28 2014 From: report at bugs.python.org (Syou Ei) Date: Fri, 30 May 2014 01:01:28 +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: <1401411688.64.0.406423911848.issue20611@psf.upfronthosting.co.za> Changes by Syou Ei : Removed file: http://bugs.python.org/file35400/socket_2_7_2_patch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 03:03:16 2014 From: report at bugs.python.org (Syou Ei) Date: Fri, 30 May 2014 01:03:16 +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: <1401411796.11.0.0853862440504.issue20611@psf.upfronthosting.co.za> Syou Ei added the comment: @tholzer I've updated socket_2_7_2_patch.py and added the missing break statement. ---------- Added file: http://bugs.python.org/file35408/socket_2_7_2_patch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 03:37:46 2014 From: report at bugs.python.org (tholzer) Date: Fri, 30 May 2014 01:37:46 +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: <1401413866.74.0.422427254484.issue20611@psf.upfronthosting.co.za> tholzer added the comment: And a test case for smtplib: import threading import signal import os import smtplib def go(): running = True pid = os.getpid() def killer(): while running: os.kill(pid, signal.SIGINT) signal.signal(signal.SIGINT, lambda x,y: None) thread = threading.Thread(target=killer) thread.start() while 1: try: smtplib.SMTP('localhost') except Exception, ex: running = False raise if __name__ == '__main__': go() Fails with: socket.error: [Errno 4] Interrupted system call ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 04:44:44 2014 From: report at bugs.python.org (paul j3) Date: Fri, 30 May 2014 02:44:44 +0000 Subject: [issue12776] argparse: type conversion function should be called only once In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za> Message-ID: <1401417884.2.0.0758691586808.issue12776@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 08:43:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 May 2014 06:43:02 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <3gfx6p5pQCz7MBk@mail.python.org> Roundup Robot added the comment: New changeset 6dd5e9556a60 by Gregory P. Smith in branch '2.7': Fix issue #14315: The zipfile module now ignores extra fields in the central http://hg.python.org/cpython/rev/6dd5e9556a60 New changeset 33843896ce4e by Gregory P. Smith in branch '3.4': Fix issue #14315: The zipfile module now ignores extra fields in the central http://hg.python.org/cpython/rev/33843896ce4e New changeset 89be1419472c by Gregory P. Smith in branch 'default': Fix issue #14315: The zipfile module now ignores extra fields in the central http://hg.python.org/cpython/rev/89be1419472c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 08:59:38 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 30 May 2014 06:59:38 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File with a short extra header In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1401433178.08.0.596227633045.issue14315@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This was never an enhancement. zipfile was failing to properly deal with real world data that other zip file tools on the planet were perfectly happy to deal with. That's a bug. Fixed. Practicality beats purity. Be lenient in what you accept. The zipfile module is not meant to be a zip "standard" validation tool. The other discussions in this bug about adding actual features such as a "strict" mode flag could be done but should really go in feature requests of their own. The zipfile module is... not a wonderful body of code (understatement). Example: It is still quite possible to get non zipfile.BadZipFile exceptions such as struct.error based on various arrangements of input data. ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith resolution: -> fixed stage: test needed -> resolved status: open -> closed title: zipfile.ZipFile() unable to open zip File -> zipfile.ZipFile() unable to open zip File with a short extra header type: enhancement -> behavior versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 10:58:56 2014 From: report at bugs.python.org (Dmitry Andreychuk) Date: Fri, 30 May 2014 08:58:56 +0000 Subject: [issue21611] int() docstring - unclear what number is Message-ID: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za> New submission from Dmitry Andreychuk: https://docs.python.org/3.4/library/functions.html?highlight=int#int The docstring for int() function has these sentences: "If x is a number, return x.__int__()." "If x is not a number or if base is given..." Unfortunately the docstring doesn't describe how the function decides if x is a number or not. After searching and experimenting I came to conclusion that it is the presence of x.__int__() method makes int() treat x as a number. But I'm not sure it's a precise requirement or just something that happens to work with current implementation. I think there should be a precise definition of what is considered to be a number there. ---------- assignee: docs at python components: Documentation messages: 219379 nosy: and, docs at python priority: normal severity: normal status: open title: int() docstring - unclear what number is versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 11:28:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 May 2014 09:28:45 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <3gg0p32BDYz7Ljr@mail.python.org> Roundup Robot added the comment: New changeset f5521f5dec4a by Raymond Hettinger in branch 'default': Issue #13742: Add key and reverse parameters to heapq.merge() http://hg.python.org/cpython/rev/f5521f5dec4a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 11:29:28 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 30 May 2014 09:29:28 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1401442168.67.0.402807554135.issue13742@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 11:38:44 2014 From: report at bugs.python.org (Sunny K) Date: Fri, 30 May 2014 09:38:44 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1401442724.87.0.294945433645.issue1820@psf.upfronthosting.co.za> Sunny K added the comment: Hi Stefan, There is a comment at the top in structseq.c /* Fields with this name have only a field index, not a field name. They are only allowed for indices < n_visible_fields. */ char *PyStructSequence_UnnamedField = "unnamed field"; This is the definition of os.stat_result in posixmodule.c: static PyStructSequence_Field stat_result_fields[] = { {"st_mode", "protection bits"}, {"st_ino", "inode"}, {"st_dev", "device"}, {"st_nlink", "number of hard links"}, {"st_uid", "user ID of owner"}, {"st_gid", "group ID of owner"}, {"st_size", "total size, in bytes"}, /* The NULL is replaced with PyStructSequence_UnnamedField later. */ {NULL, "integer time of last access"}, {NULL, "integer time of last modification"}, {NULL, "integer time of last change"}, {"st_atime", "time of last access"}, {"st_mtime", "time of last modification"}, {"st_ctime", "time of last change"}, {"st_atime_ns", "time of last access in nanoseconds"}, {"st_mtime_ns", "time of last modification in nanoseconds"}, {"st_ctime_ns", "time of last change in nanoseconds"}, ... By visible i mean the values present in the repr of the object and by-extension accessible by position. I talked about my problems with os.stat_result in points 3 and 4 of msg202333 i.e repr of os.stat_result takes the first three keys from the attribute-access only fields (the invisible part) and uses them for the last three values in the displayed structseq. With my current patch, _fields for os.stat_result only has 7 values: >>> x = os.stat('.') >>> x._fields ('st_mode', 'st_ino', 'st_dev', 'st_nlink', 'st_uid', 'st_gid', 'st_size') >>> Is this what you expect? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 11:45:09 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 30 May 2014 09:45:09 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1401443109.68.0.542959553438.issue1820@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 11:47:38 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 30 May 2014 09:47:38 +0000 Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za> Message-ID: <1401443258.72.0.884819258746.issue19048@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 12:21:31 2014 From: report at bugs.python.org (Maciej Szulik) Date: Fri, 30 May 2014 10:21:31 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1401445291.83.0.5466048635.issue19662@psf.upfronthosting.co.za> Maciej Szulik added the comment: I've included Leslie's comments in rst file. The 3rd version is attached in issue19662_v3.patch. ---------- Added file: http://bugs.python.org/file35409/issue19662_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 12:22:10 2014 From: report at bugs.python.org (Sunny K) Date: Fri, 30 May 2014 10:22:10 +0000 Subject: [issue1185124] pydoc doesn't find all module doc strings Message-ID: <1401445330.34.0.788004848445.issue1185124@psf.upfronthosting.co.za> Changes by Sunny K : Removed file: http://bugs.python.org/file31844/myfirst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 12:24:40 2014 From: report at bugs.python.org (Sunny K) Date: Fri, 30 May 2014 10:24:40 +0000 Subject: [issue1185124] pydoc doesn't find all module doc strings Message-ID: <1401445480.88.0.147274250244.issue1185124@psf.upfronthosting.co.za> Sunny K added the comment: Hi Victor, can you give this another look? ---------- versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 13:14:03 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 30 May 2014 11:14:03 +0000 Subject: [issue21571] Python build should check CPATH, C_INCLUDE_PATH for module dependencies In-Reply-To: <1400966978.12.0.900228617975.issue21571@psf.upfronthosting.co.za> Message-ID: <1401448443.68.0.0267271509611.issue21571@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I'm pretty sure that I wrote the code Ned refers to, and that's indeed only targeting darwin to avoid breaking other platforms. That code could easily be made actively globally though, the only reason I didn't do so at the time is we were still getting used to the fact that MacOS used the same build infrastructure as other major platforms and hence were overly cautious. Note that this doesn't do the same thing as Jan requests: GCC[1] and clang[2] can add additional directories to their header file search path using environment variables. For Python's setup.py file the following are important: * C_INCLUDE_PATH: a list of directories that are handled as if they are present at the end of the list of -isystem options (that is, system include files at a lower priority that the user provided ones) * CPATH: simular, but for the '-I' option * LIBRARY_PATH: similar, but for the '-L' option All of them have a syntax similar to $PATH. A patch to add support for these variables (and enables the handling of -I and -L for other platforms than darwin) should be easy enough, but I agree with Ned that this would be a new feature because it could break existing build systems (that is, building Python with this patch could result in a different build than without the patch due to the build picking up more or different external libraries). Jan: are you willing to write such a patch? And if so, are you willing to sign a contributor agreement? [1]: http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html [2]: http://clang.llvm.org/doxygen/Tools_8cpp_source.html ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 13:20:42 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 30 May 2014 11:20:42 +0000 Subject: [issue21541] Provide configure option --with-ssl for compilation with custom openssl In-Reply-To: <1400593614.19.0.224440922912.issue21541@psf.upfronthosting.co.za> Message-ID: <1401448842.61.0.180408414289.issue21541@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Isn't Modules/Setup used for builtin modules? The proposed configure flags are easier to find because similar flags are used by other projects using autoconf. Note that on OSX you could use "CFLAGS=-I/path/to/ssl/include LDFLAGS=-L/path/to/ssl/lib", because setup.py contains code to add directories from those flags to its search path for headers and libraries, but only for OSX because I was overly cautious when adding that code. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 13:39:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 May 2014 11:39:17 +0000 Subject: [issue21552] String length overflow in Tkinter In-Reply-To: <1400769722.86.0.708994855199.issue21552@psf.upfronthosting.co.za> Message-ID: <3gg3hf46r9z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 59468bd68789 by Serhiy Storchaka in branch '2.7': Issue #21552: Fixed possible integer overflow of too long string lengths in http://hg.python.org/cpython/rev/59468bd68789 New changeset a90cddfd9e47 by Serhiy Storchaka in branch '3.4': Issue #21552: Fixed possible integer overflow of too long string lengths in http://hg.python.org/cpython/rev/a90cddfd9e47 New changeset 5b80af12ccb7 by Serhiy Storchaka in branch 'default': Issue #21552: Fixed possible integer overflow of too long string lengths in http://hg.python.org/cpython/rev/5b80af12ccb7 New changeset 8c96af2fba28 by Serhiy Storchaka in branch '2.7': Fixed possible integer overflow in getint, getdouble and getboolean too (issue #21552). http://hg.python.org/cpython/rev/8c96af2fba28 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 14:43:39 2014 From: report at bugs.python.org (Thomas Dybdahl Ahle) Date: Fri, 30 May 2014 12:43:39 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1401453819.01.0.41908301981.issue21592@psf.upfronthosting.co.za> Thomas Dybdahl Ahle added the comment: If you have a good, realistic test set, we can try testing quick-select vs sorting. If it's still not good, I can also reimplement it in C. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 16:08:06 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 30 May 2014 14:08:06 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401458886.66.0.331838655609.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: Giving Eric is polymorphic first argument to types.ModuleType() is going to be tricky thanks to the fact that it is not hard-coded anywhere in the C code nor documented that the first argument must be a string (the only way it might come up is from PyModule_GetName() and even then that's not required to work as you would expect). And since we purposefully kept specs type-agnostic, you can't do a type check for a SimpleNamespace. I think the only way for it to work is by attribute check (e.g. is 'name' or 'loader' defined on the object, regardless of value). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 16:16:40 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 30 May 2014 14:16:40 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401459400.49.0.147507265883.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: Another issue with the polymorphic argument is that the module type is one of those rare things written in C with keyword parameter support, so renaming the 'name' argument to 'name_or_spec' could potentially break code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 16:19:04 2014 From: report at bugs.python.org (Bikram Zesto II) Date: Fri, 30 May 2014 14:19:04 +0000 Subject: [issue21608] logging.handlers.HTTPHandler.setFormatter() has no effect In-Reply-To: <1401396195.13.0.00625347928702.issue21608@psf.upfronthosting.co.za> Message-ID: <1401459544.77.0.71089488852.issue21608@psf.upfronthosting.co.za> Bikram Zesto II added the comment: I see what you are saying about implementation kludginess and will likely subclass just to get my app done. On the other hand, I think the POLA(stonishment) violation of ignoring format-related configuration of the Handler (even tho it is a subclass) matters too :-) Was not thinking a Formatter should be put _into_ mapLogRecord. More like idly wondering if mapLogRecord could be implemented as a Formatter. If this sounds like a non-kludge you would be interested in I can work on that. Added benefit being that users could override without subclassing. Maybe this is more like a documentation issue (since there is no indication that HTTPHandler does not/cannot use a Formatter like other of Handlers? ---------- keywords: +patch status: pending -> open Added file: http://bugs.python.org/file35410/logging.handlers.txt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 16:27:54 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 30 May 2014 14:27:54 +0000 Subject: [issue21610] load_module not closing opened files In-Reply-To: <1401397842.84.0.0447434593999.issue21610@psf.upfronthosting.co.za> Message-ID: <1401460074.67.0.622170509001.issue21610@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't have a Python 2.7 repo handy but the patch LGTM. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 16:40:39 2014 From: report at bugs.python.org (irdb) Date: Fri, 30 May 2014 14:40:39 +0000 Subject: [issue21612] IDLE should should not open multiple instances of one file Message-ID: <1401460839.49.0.839937941889.issue21612@psf.upfronthosting.co.za> New submission from irdb: Currently users can open multiple instances of one file in IDLE. Sometimes this leads to confusion and may cause loss of data. I'm not aware of any benefits of this behavior and I think it's better to be prevented by IDLE. Here are the steps to recreate the situation: 1. Create a file named "xyz.py" 2. Right-click on the file and open it with IDLE 3. Add some text 4. Goto 2. 5. Save and close both open IDLE windows. (Your work on the first saved file will be lost.) ---------- components: IDLE messages: 219392 nosy: irdb priority: normal severity: normal status: open title: IDLE should should not open multiple instances of one file _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 16:41:28 2014 From: report at bugs.python.org (irdb) Date: Fri, 30 May 2014 14:41:28 +0000 Subject: [issue21612] IDLE should not open multiple instances of one file In-Reply-To: <1401460839.49.0.839937941889.issue21612@psf.upfronthosting.co.za> Message-ID: <1401460888.18.0.638669893346.issue21612@psf.upfronthosting.co.za> Changes by irdb : ---------- title: IDLE should should not open multiple instances of one file -> IDLE should not open multiple instances of one file _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 16:57:01 2014 From: report at bugs.python.org (Artem Ustinov) Date: Fri, 30 May 2014 14:57:01 +0000 Subject: [issue21613] Installer for mac doesn't store the installation location Message-ID: <1401461821.06.0.907126667727.issue21613@psf.upfronthosting.co.za> New submission from Artem Ustinov: I'm trying to automate the Python uninstallation on mac but I've found that the actual installation location is not stored for Python packages. That location is required since the pkgutil keeps track of installed files (if you run $ pkgutil --files org.python.Python.PythonFramework-3.4) but doesn't store the absolute paths for that files. 1. Run $ pkgutil --pkgs=.*Python.*3\.4 Here's the expected output org.python.Python.PythonApplications-3.4 org.python.Python.PythonDocumentation-3.4 org.python.Python.PythonFramework-3.4 org.python.Python.PythonInstallPip-3.4 org.python.Python.PythonProfileChanges-3.4 org.python.Python.PythonUnixTools-3.4 2. Run $ pkgutil --pkg-info org.python.Python.PythonFramework-3.4 Here's the output package-id: org.python.Python.PythonFramework-3.4 version: 3.4.1 volume: / location: (null) install-time: 1401373546 Actual Result: The location property is (null) Expected Result: The location property should be '/Library/Frameworks/Python.framework' ---------- assignee: ronaldoussoren components: Installation, Macintosh messages: 219393 nosy: ronaldoussoren, ustinov priority: normal severity: normal status: open title: Installer for mac doesn't store the installation location type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 16:59:38 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Fri, 30 May 2014 14:59:38 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401461978.78.0.840753533844.issue21477@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file35411/htest-docstring-34.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 17:00:50 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Fri, 30 May 2014 15:00:50 +0000 Subject: [issue21477] Idle: improve idle_test.htest In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za> Message-ID: <1401462050.28.0.022792286812.issue21477@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file35412/htest-docstring-27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 17:00:50 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 30 May 2014 15:00:50 +0000 Subject: [issue21613] Installer for mac doesn't store the installation location In-Reply-To: <1401461821.06.0.907126667727.issue21613@psf.upfronthosting.co.za> Message-ID: <1401462050.47.0.47765223074.issue21613@psf.upfronthosting.co.za> Ronald Oussoren added the comment: According to the manpage pkgutil is used with flat packages. The Python installer users older bundle-style packages. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 17:23:25 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 30 May 2014 15:23:25 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401463405.02.0.896422730351.issue21476@psf.upfronthosting.co.za> R. David Murray added the comment: I think the code should be using 'detach' after passing the fp to parser.parse, instead of using 'with'. ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 17:52:31 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 30 May 2014 15:52:31 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1401465151.7.0.797003796551.issue21462@psf.upfronthosting.co.za> Steve Dower added the comment: I can commit it, though I don't know how it'll affect Benjamin's release branch? (Obviously the build will be fine either way - I had the patch applied for 2.7.7rc1.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 17:55:42 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 30 May 2014 15:55:42 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401465342.0.0.411370350512.issue20383@psf.upfronthosting.co.za> Eric Snow added the comment: Yeah, it just looks too complicated to take the ModuleType signature approach, as much as I prefer it. :) I appreciate you taking a look though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 18:15:30 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 30 May 2014 16:15:30 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401466530.14.0.782852790608.issue21476@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the simple patch based on David Murray's thought. ---------- keywords: +patch nosy: +vajrasky Added file: http://bugs.python.org/file35413/bytes_parser_dont_close_file.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 18:28:45 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 30 May 2014 16:28:45 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401467325.62.0.469834075697.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: And another complication is the compatibility hack to set loader when submodule_search_locations is set but loader is not since _NamespaceLoader is not exposed in C without importlib which gets us back into the whole question of whether types should function entirely in isolation from other subsystems of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 18:29:55 2014 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 30 May 2014 16:29:55 +0000 Subject: [issue21608] logging.handlers.HTTPHandler.setFormatter() has no effect In-Reply-To: <1401396195.13.0.00625347928702.issue21608@psf.upfronthosting.co.za> Message-ID: <1401467395.41.0.443495484052.issue21608@psf.upfronthosting.co.za> Vinay Sajip added the comment: As far as POLA is concerned, IMO serializing to the HTTP request format isn't really a text formatting operation in the same way as for most other handlers. The point is, even if you could have a Formatter handle the operation, you can't usefully share this Formatter with other handlers (which you refer to in your initial post), unless you really want to have format lines such as a=b&c=d&e=f output to console or file, say - which is unlikely to be a common requirement. I don't expect to make any changes in this area - as I mentioned earlier, because (a) backward compatibility and (b) IMO it will surprise more people than the current approach (IIRC no one else has raised this or a similar issue in the 10+ years that logging has been in Python). BTW, I am happy to update the documentation for HTTPHandler to indicate that it can't sensibly use a Formatter. I'll do this soon, and that change will close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 18:43:43 2014 From: report at bugs.python.org (Chris Rebert) Date: Fri, 30 May 2014 16:43:43 +0000 Subject: [issue13212] json library is decoding/encoding when it should not In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za> Message-ID: <1401468222.9.0.875258580468.issue13212@psf.upfronthosting.co.za> Chris Rebert added the comment: Okay, so can this issue be closed in light of the existing docs and issue 21514 then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 18:47:28 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 30 May 2014 16:47:28 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401468448.78.0.127673095552.issue20383@psf.upfronthosting.co.za> Eric Snow added the comment: But that part is less of a concern since we don't need namespace packages before or during bootstrapping, and afterward we have access to interp->importlib. Or am I missing something? > which gets us back into the whole question of whether types should > function entirely in isolation from other subsystems of Python. That is a great question, regardless. In part I imagine it depends on the subsystem and how intrinsic it is to the interpreter, which seems like a relatively implementation-agnostic point from a high-level view. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 18:49:08 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 30 May 2014 16:49:08 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1401468548.5.0.305959933962.issue21462@psf.upfronthosting.co.za> Zachary Ware added the comment: Go ahead and commit; it will be up to Benjamin to cherry-pick it to his release branch (or to ask you to do it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 18:58:00 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 16:58:00 +0000 Subject: [issue21561] help() on enum34 enumeration class creates only a dummy documentation In-Reply-To: <1400866031.36.0.493061688069.issue21561@psf.upfronthosting.co.za> Message-ID: <1401469080.03.0.545610269087.issue21561@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Devise a simple test (fail before, work after) that does not require enum34. If this fix is committed, the message could note that the same issue was fixed differently in 3.4 mixed in with other changes. ---------- nosy: +terry.reedy stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 19:00:51 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 17:00:51 +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: <1401469251.35.0.413668606557.issue21568@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 19:10:12 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 17:10:12 +0000 Subject: [issue21569] PEP 466: Python 2.7 What's New preamble changes In-Reply-To: <1400927192.68.0.366242673147.issue21569@psf.upfronthosting.co.za> Message-ID: <1401469812.78.0.920900351285.issue21569@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Did you intend to upload a diff with the current changes? My answers: * Just describe 466. Don't invite trouble. * Move the section to its logical place in temporal order, with a clear link. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 19:33:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 30 May 2014 17:33:05 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401471185.82.0.270184220346.issue21476@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Use try/finally to detach even if an exception is raised during parsing. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 20:02:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 May 2014 18:02:44 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <3ggDC55sn8z7Qht@mail.python.org> Roundup Robot added the comment: New changeset f6e47d27f67a by Steve Dower in branch '2.7': Issue #21462 PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds http://hg.python.org/cpython/rev/f6e47d27f67a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 20:05:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 May 2014 18:05:56 +0000 Subject: [issue21608] logging.handlers.HTTPHandler.setFormatter() has no effect In-Reply-To: <1401396195.13.0.00625347928702.issue21608@psf.upfronthosting.co.za> Message-ID: <3ggDGq41G5z7PG8@mail.python.org> Roundup Robot added the comment: New changeset e5373bfbe76b by Vinay Sajip in branch '2.7': Issue #21608: Updated HTTPHandler documentation. http://hg.python.org/cpython/rev/e5373bfbe76b New changeset 220bed23696e by Vinay Sajip in branch '3.4': Issue #21608: Updated HTTPHandler documentation. http://hg.python.org/cpython/rev/220bed23696e New changeset 69011f6ce573 by Vinay Sajip in branch 'default': Closes #21608: Merged documentation update from 3.4. http://hg.python.org/cpython/rev/69011f6ce573 ---------- nosy: +python-dev resolution: not a bug -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 20:22:47 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 30 May 2014 18:22:47 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1401474167.97.0.163085293225.issue14097@psf.upfronthosting.co.za> Zachary Ware added the comment: How's this for a 2.7 backport? The least direct part of the backport is the section on division; I pretty much had to completely rewrite the paragraph in 2.x terms and I'm not certain that I took the best approach. ---------- stage: commit review -> patch review versions: -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file35414/issue14097-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 20:46:21 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 18:46:21 +0000 Subject: [issue21573] Clean up turtle.py code formatting In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> Message-ID: <1401475581.93.0.219718757138.issue21573@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am glad to see this. Gregor has been inactive for several years, Except for Ned's recent patch for OSX, it has been years since there was a turtle-specific code patch (from hg revision history). Questions: is there project link? are any of the mentors core developers, with commit rights? or would you need commits from someone like me? I have read turtle.py and found that the multiple layers made some things hard to follow. To me, this was a bigger impediment than code formatting. You may want to develop an outline of the layer structure. As you may know, Guido generally discourages pure code cleanups and prefers that they be done when the code is examined for other purposes. I personally think some changes are safe enough if verified by a second person. I looked for and did not fine test/test_turtle. Did I miss something? Turtledemo is a partial substitute, but it might not exercise all turtle functions. If you only apply cleanups to 3.5, subsequent bug fixes for all 3 versions will become much more difficult. The default commit process assumes that maintenance patches merge forward cleanly. I try to keep Idle code the same across versions as much as possible. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 20:55:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 May 2014 18:55:40 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <3ggFN96x97z7SSy@mail.python.org> Roundup Robot added the comment: New changeset b26d021081d2 by Brett Cannon in branch 'default': Issue #20383: Introduce importlib.util.module_from_spec(). http://hg.python.org/cpython/rev/b26d021081d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 20:57:20 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 30 May 2014 18:57:20 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401476240.04.0.718282385613.issue20383@psf.upfronthosting.co.za> Brett Cannon added the comment: After all the various revelations today about how much of a hassle and murky it would be to get types.ModuleType to do what we were after, I went ahead and kept importlib.util.module_from_spec(), but dropped the module argument bit. I also deconstructed _SpecMethods along the way while keeping the abstractions as Eric requested. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 20:58:24 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 18:58:24 +0000 Subject: [issue21577] Help for ImportError should show a more useful signature. In-Reply-To: <1401078448.87.0.796266837202.issue21577@psf.upfronthosting.co.za> Message-ID: <1401476304.57.0.724464177531.issue21577@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Your example in #21578 suggests that **kwargs should be deleted. *args is right. >>> ImportError(3, 'a') ImportError(3, 'a') Should not this be fixed by ArgClinic conversion, and is not there an issue for that for exceptions? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:03:11 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 30 May 2014 19:03:11 +0000 Subject: [issue21500] Make use of the "load_tests" protocol in test_importlib packages In-Reply-To: <1400007358.12.0.940641548905.issue21500@psf.upfronthosting.co.za> Message-ID: <1401476591.38.0.667109677955.issue21500@psf.upfronthosting.co.za> R. David Murray added the comment: Personally I think the fact that this doesn't work by default is a bug in unittest. See issue 15007. Issue 16662 may also be related. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:10:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 19:10:08 +0000 Subject: [issue21582] use support.captured_stdx context managers - test_asyncore In-Reply-To: <1401116386.06.0.283011419126.issue21582@psf.upfronthosting.co.za> Message-ID: <1401477008.33.0.336245136067.issue21582@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since asyncore is depracated, I don't know if tests are being updated, or if this should be closed. ---------- nosy: +josiahcarlson, stutzbach, terry.reedy title: use support.catpured context managers - test_asyncore -> use support.captured_stdx context managers - test_asyncore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:10:44 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 30 May 2014 19:10:44 +0000 Subject: [issue21504] can the subprocess module war using os.wait4 and so return usage? In-Reply-To: <1400035246.64.0.2270855198.issue21504@psf.upfronthosting.co.za> Message-ID: <1401477044.58.0.0638508597034.issue21504@psf.upfronthosting.co.za> R. David Murray added the comment: I think the answer is that if you want that level of control you can't use communicate, you have to implement what you specifically need. I'm going to close this as rejected. It could be reopened if someone can find a way to propose something that makes sense cross-platform. ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:12:34 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 19:12:34 +0000 Subject: [issue21583] use support.captured_stderr context manager - test_logging In-Reply-To: <1401125710.75.0.955154923721.issue21583@psf.upfronthosting.co.za> Message-ID: <1401477154.0.0.897947972669.issue21583@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +vinay.sajip stage: -> patch review title: use support.catpured_stderr context manager - test_logging -> use support.captured_stderr context manager - test_logging type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:33:50 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 19:33:50 +0000 Subject: [issue21591] "exec(a, b, c)" not the same as "exec a in b, c" in nested functions In-Reply-To: <1401266879.61.0.867969486588.issue21591@psf.upfronthosting.co.za> Message-ID: <1401478430.9.0.401705271276.issue21591@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The exception appears to be intentional, though I do not know what a 'qualified' exec would be. But since the tuple form is intended to mimic 3.x exec, and since a reduced version of your example c = ''' def g(): def f(): if True: exec("", {}, {}) ''' compile(c, "", "exec") runs fine in 3.4, I agree that this appears to be a 2.7 compiler bug. ---------- nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, terry.reedy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:43:05 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 30 May 2014 19:43:05 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> Message-ID: <1401478985.52.0.552012917218.issue20383@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for doing that Brett and for accommodating me. :) Also, the various little cleanups are much appreciated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:44:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 19:44:14 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1401479054.58.0.150475851531.issue21592@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To accept contributions, we need a signed (possibly electronically) contribution form. https://www.python.org/psf/contrib/contrib-form/ ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:51:50 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 19:51:50 +0000 Subject: [issue21593] Clarify re.search documentation first match In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za> Message-ID: <1401479510.13.0.832085158443.issue21593@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since I am 99.999% sure that first is intended, I will change 'a location' to 'the first location'. ---------- assignee: docs at python -> terry.reedy nosy: +terry.reedy stage: -> needs patch type: -> enhancement versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:52:44 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 30 May 2014 19:52:44 +0000 Subject: [issue21577] Help for ImportError should show a more useful signature. In-Reply-To: <1401078448.87.0.796266837202.issue21577@psf.upfronthosting.co.za> Message-ID: <1401479564.48.0.235444620622.issue21577@psf.upfronthosting.co.za> Eric Snow added the comment: Yeah, I also noticed that about **kwargs, but only a little while later and didn't get around to making a note here. As to ArgumentClinic, I imagine that this could be fixed when ModuleType (in Objects/moduleobject.c) gets converted to use it. I don't know too much about the limitations though--maybe that's why it wasn't converted already. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:54:39 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 30 May 2014 19:54:39 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1401479679.39.0.979362365316.issue21462@psf.upfronthosting.co.za> Zachary Ware added the comment: Looks like the AMD64 buildbot isn't happy with OpenSSL 1.0.1g: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7/builds/1223/steps/compile/logs/stdio Here's my best stab-in-the-dark guess at fixing what's wrong; I don't have the ability to build x64 2.7 handy. ---------- Added file: http://bugs.python.org/file35415/224ca86e3919_backport.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:55:49 2014 From: report at bugs.python.org (Colin Davidson) Date: Fri, 30 May 2014 19:55:49 +0000 Subject: [issue21614] Case sensitivity problem in multiprocessing. Message-ID: <1401479749.7.0.550679517464.issue21614@psf.upfronthosting.co.za> New submission from Colin Davidson: On windows 7, if a Python app is run (under python 2.7.6) and the invoking filename is capitalized differently from the source file itself, a subsequent attempt to use the multiprocessing module to "fork" a process will fail in the "forking" module. This happens because the fopen at line 1559 in import.c (in the "imp" module find_module method) uses the invoking capitalization, rather than the file capitalization and fails to open the file. The traceback gives lines 380 then 489 in forking.py, but as noted, the problem is in import.c (or in the Python startup, which could convert the capitalization...). ---------- components: Interpreter Core, Windows messages: 219423 nosy: ColinPDavidson priority: normal severity: normal status: open title: Case sensitivity problem in multiprocessing. type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 21:58:06 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 30 May 2014 19:58:06 +0000 Subject: [issue21603] IDLE SaveAs drops the extension in the prompted filename In-Reply-To: <1401349272.89.0.982652468131.issue21603@psf.upfronthosting.co.za> Message-ID: <1401479886.7.0.0929909414483.issue21603@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On Win 7, I also see x.py in the save dialog, both 2.7 and 3.4 as installed. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 22:02:03 2014 From: report at bugs.python.org (Richard s. Gordon) Date: Fri, 30 May 2014 20:02:03 +0000 Subject: [issue21615] Curses bug report for Python 2.7 and Python 3.2 Message-ID: New submission from Richard s. Gordon: Curses bug report for Python 2.7 and Python 3.2 My Python code outputs text properly with xterm and xterm-16color. It does not work properly with xterm-88color and xterm-256color (after defining RGB color pallet) when run on Python-2.7 and Python-3.2 on Cygwin with Windows 7 Pro, Ubuntu Linux 12.04, Mac OS X 10.9.3 and PS-BSD 10. For text output to xterm-88color and xterm-256color Python generates unique colors that are plagued by the wrong color and underline artifacts. xterm-16color xterm-16color xterm-88color xterm-256color ========== ========== ========== =========== Region 1 cyan on black cyan on black cyan on olive with underlines cyan on purple with underlines Region 2 white on black white on black navy on black white on orange Region 3 yellow on black yellow on black magenta on black with underlines navy on black with underlines Some of my test platform terminals (such as iTerm2 on my iMac desktop system running Mac OSX Mavericks 10.9.3) default to xterm-256color and presumably already have Python 2.7.5 built for 256 color. I downloaded and built Python 3.2.2. My Python test code works properly with xterm and xterm-16color. Both display the wrong colors, some with underlines when run with xterm-88color and xterm-256color. Any solutions or suggestions? Richard S. Gordon ---------- messages: 219425 nosy: eclectic9509 priority: normal severity: normal status: open title: Curses bug report for Python 2.7 and Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 22:20:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 May 2014 20:20:52 +0000 Subject: [issue21593] Clarify re.search documentation first match In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za> Message-ID: <3ggHGW1QD2z7Ljp@mail.python.org> Roundup Robot added the comment: New changeset f7bb1d73a341 by Terry Jan Reedy in branch '2.7': Issue #21593: (from StackOverflow) minor doc clarification for re.search. http://hg.python.org/cpython/rev/f7bb1d73a341 New changeset 6013a112aba0 by Terry Jan Reedy in branch '3.4': Issue #21593: (from StackOverflow) minor doc clarification for re.search. http://hg.python.org/cpython/rev/6013a112aba0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 22:46:51 2014 From: report at bugs.python.org (Lita Cho) Date: Fri, 30 May 2014 20:46:51 +0000 Subject: [issue21573] Clean up turtle.py code formatting In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> Message-ID: <1401482811.58.0.970449085174.issue21573@psf.upfronthosting.co.za> Lita Cho added the comment: Hi Terry, > is there project link? are any of the mentors core developers, with > commit rights? or would you need commits from someone like me? I am not 100% sure. Let me ask Jessica, who is my mentor, and get back to you. > I have read turtle.py and found that the multiple layers made some > things hard to follow. To me, this was a bigger impediment than code > formatting. You may want to develop an outline of the layer > structure. There is no project link to Turtle cleanup specifically. But I can definitely try to reorganize the code such that it flows better and it is easier to read. I can add that to the list. > As you may know, Guido generally discourages pure code cleanups and > prefers that they be done when the code is examined for other > purposes. I personally think some changes are safe enough if verified > by a second person. I actually did not know that Guido discourages pure code cleanup. Should I try to find a feature to add? Currently, I am doing all the easy stuff, and making it pep8 compliant and work through linter. I am also trying to delete some of the commented out code. > I looked for and did not fine test/test_turtle. Did I miss something? > Turtledemo is a partial substitute, but it might not exercise all > turtle functions. I actually don't see the Turtle tests as well. Should creating unit tests for turtle.py be a separate ticket? I am currently developing off of 3.4. I will try to run my patch through all the versions of Python 3 to make sure it is a clean fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 30 23:38:24 2014 From: report at bugs.python.org (Matthias Urlichs) Date: Fri, 30 May 2014 21:38:24 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1401485904.11.0.705541989184.issue21306@psf.upfronthosting.co.za> Matthias Urlichs added the comment: Currently (Debian's 2.7.7-rc1 package) hmac.compare_digest accepts two bytestring arguments, or two Unicode stings, but not one bytestring and one unicode. I don't think that's a good idea. ---------- nosy: +smurfix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 00:01:41 2014 From: report at bugs.python.org (Vasilis Vasaitis) Date: Fri, 30 May 2014 22:01:41 +0000 Subject: [issue21616] argparse explodes with nargs='*' and a tuple metavar Message-ID: <1401487300.75.0.673087061626.issue21616@psf.upfronthosting.co.za> New submission from Vasilis Vasaitis: The title says it all really, but to demostrate: Let's say I'm building a program which takes another command as its argument(s) on the command line, to execute it in a special way or whatever. The natural way to do this then would be something like the following: import argparse parser = argparse.ArgumentParser() parser.add_argument('cmd', nargs='*') parser.parse_args() Which gives the following output with -h: usage: nargs.py [-h] [cmd [cmd ...]] positional arguments: cmd optional arguments: -h, --help show this help message and exit Now, let's say I want to have 'command' printed in the help output, but still write the shorter 'cmd' in the code. Naturally I would make use of the metavar feature: import argparse parser = argparse.ArgumentParser() parser.add_argument('cmd', nargs='*', metavar='command') parser.parse_args() So now the help output is: usage: nargs.py [-h] [command [command ...]] positional arguments: command optional arguments: -h, --help show this help message and exit That's better, but I don't really want it to say 'command' twice there, it's more like a command and then its arguments. So what about a tuple instead? import argparse parser = argparse.ArgumentParser() parser.add_argument('cmd', nargs='*', metavar=('command', 'arguments')) parser.parse_args() So let's see what happens now with -h: Traceback (most recent call last): File "/Users/Vasilis/Sources/Tests/nargs.py", line 6, in parser.parse_args() File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1717, in parse_args args, argv = self.parse_known_args(args, namespace) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1749, in parse_known_args namespace, args = self._parse_known_args(args, namespace) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1955, in _parse_known_args start_index = consume_optional(start_index) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1895, in consume_optional take_action(action, args, option_string) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1823, in take_action action(self, namespace, argument_values, option_string) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1016, in __call__ parser.print_help() File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 2348, in print_help self._print_message(self.format_help(), file) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 2325, in format_help formatter.add_arguments(action_group._group_actions) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 272, in add_arguments self.add_argument(action) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 257, in add_argument invocations = [get_invocation(action)] File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 535, in _format_action_invocation metavar, = self._metavar_formatter(action, default)(1) ValueError: too many values to unpack (expected 1) Hm, that didn't go very well. Perhaps I can try with a single element in the tuple, as the exception seems to suggest: import argparse parser = argparse.ArgumentParser() parser.add_argument('cmd', nargs='*', metavar=('command',)) parser.parse_args() Any better? Traceback (most recent call last): File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1334, in add_argument self._get_formatter()._format_args(action, None) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 579, in _format_args result = '[%s [%s ...]]' % get_metavar(2) TypeError: not enough arguments for format string During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/Vasilis/Sources/Tests/nargs.py", line 5, in parser.add_argument('cmd', nargs='*', metavar=('command',)) File "/usr/local/Cellar/python3/3.4.0/Frameworks/Python.framework/Versions/3.4/lib/python3.4/argparse.py", line 1336, in add_argument raise ValueError("length of metavar tuple does not match nargs") ValueError: length of metavar tuple does not match nargs No, not really. So there you have it. I think the two-element-tuple example should do the right thing (print "[command [arguments ...]]"). But if not, at least *some* kind of tuple should work without raising an exception. Apart from 3.4, I see precisely the same behaviour with Python 2.7 too. I haven't tested with any other version I'm afraid. ---------- components: Library (Lib) messages: 219429 nosy: vvas priority: normal severity: normal status: open title: argparse explodes with nargs='*' and a tuple metavar versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 00:02:30 2014 From: report at bugs.python.org (Vasilis Vasaitis) Date: Fri, 30 May 2014 22:02:30 +0000 Subject: [issue21616] argparse explodes with nargs='*' and a tuple metavar In-Reply-To: <1401487300.75.0.673087061626.issue21616@psf.upfronthosting.co.za> Message-ID: <1401487350.73.0.406632178025.issue21616@psf.upfronthosting.co.za> Changes by Vasilis Vasaitis : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 00:41:56 2014 From: report at bugs.python.org (donald petravick) Date: Fri, 30 May 2014 22:41:56 +0000 Subject: [issue21504] can the subprocess module war using os.wait4 and so return usage? In-Reply-To: <1401477044.58.0.0638508597034.issue21504@psf.upfronthosting.co.za> Message-ID: donald petravick added the comment: Ok. I have a subclass with a copied out - then-modified wait method. ?twill do for now. I?m clueless as to what the windows analog of wait4() would be. On 5/30/14, 3:10 PM, "R. David Murray" wrote: > >R. David Murray added the comment: > >I think the answer is that if you want that level of control you can't >use communicate, you have to implement what you specifically need. > >I'm going to close this as rejected. It could be reopened if someone can >find a way to propose something that makes sense cross-platform. > >---------- >nosy: +r.david.murray >resolution: -> rejected >stage: -> resolved >status: open -> closed > >_______________________________________ >Python tracker > >_______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 02:13:26 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 31 May 2014 00:13:26 +0000 Subject: [issue21593] Clarify re.search documentation first match In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za> Message-ID: <1401495206.29.0.448430211473.issue21593@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 02:41:48 2014 From: report at bugs.python.org (Paul Suh) Date: Sat, 31 May 2014 00:41:48 +0000 Subject: [issue1570255] redirected cookies Message-ID: <1401496908.94.0.293024092184.issue1570255@psf.upfronthosting.co.za> Paul Suh added the comment: I found a repeatable, public test case: http://www.macupdate.com/download/26915/ScreenFlow-4.5.1.dmg Using urllib2 with the following code leads to a redirect loop: #!/usr/bin/python import urllib2 h = urllib2.HTTPHandler(debuglevel=1) h2 = urllib2.HTTPSHandler(debuglevel=1) opener = urllib2.build_opener(h) opener2 = urllib2.build_opener(h2) urllib2.install_opener(opener) urllib2.install_opener(opener2) request = urllib2.Request(url="http://www.macupdate.com/download/26915/ScreenFlow-4.5.1.dmg") request.add_header( "User-Agent", "foo" ) url_handle = urllib2.urlopen(request) ---------- nosy: +Paul.Suh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 02:57:57 2014 From: report at bugs.python.org (akira) Date: Sat, 31 May 2014 00:57:57 +0000 Subject: [issue1191964] asynchronous Subprocess Message-ID: <1401497877.81.0.51064678828.issue1191964@psf.upfronthosting.co.za> akira added the comment: > Does anyone have questions, comments, or concerns about the patch? It seems the current API doesn't distinguish between BlockingIOError (temporary error), BrokenPipeError (permanent error) and EOF (permanent non-error condition) -- everything is treated as EOF. Is it intentional? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 03:10:05 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 31 May 2014 01:10:05 +0000 Subject: [issue21516] pathlib.Path(...).is_dir() crashes on some directories (Windows) In-Reply-To: <1400251536.05.0.844143170662.issue21516@psf.upfronthosting.co.za> Message-ID: <1401498605.27.0.205811073742.issue21516@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 03:20:31 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 31 May 2014 01:20:31 +0000 Subject: [issue21569] PEP 466: Python 2.7 What's New preamble changes In-Reply-To: <1401469812.78.0.920900351285.issue21569@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Ah, that *would* explain the lack of comments. I'll upload the missing patch later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 03:21:18 2014 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 31 May 2014 01:21:18 +0000 Subject: [issue21569] PEP 466: Python 2.7 What's New preamble changes In-Reply-To: <1400927192.68.0.366242673147.issue21569@psf.upfronthosting.co.za> Message-ID: <1401499278.54.0.547236784908.issue21569@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 03:24:37 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 31 May 2014 01:24:37 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType In-Reply-To: <1401478985.52.0.552012917218.issue20383@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Another thing to keep in the back of your minds: one of my goals for PEP 432 is to make it possible to have a fully functional embedded interpreter up and running *without* configuring the Python level import system. This is the state the interpreter would be in between the beginning and end of initialisation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 03:31:13 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 31 May 2014 01:31:13 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1401485904.11.0.705541989184.issue21306@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: That restriction is deliberate (and documented). As a 3.x backport, this utility inherits some of Python 3's pedantry about requiring explicit conversions between binary and text data and being consistent as to which domain you're operating in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 03:56:36 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 31 May 2014 01:56:36 +0000 Subject: [issue21617] importlib reload can fail with AttributeError if module removed from sys.path Message-ID: <1401501396.28.0.0719854991231.issue21617@psf.upfronthosting.co.za> New submission from Ned Deily: There are significant differences in behavior between Python 2.7, 3.3, and 3.4 (or current default) when using import reload() while manipulating sys.path. These differences cause unexpected behavior in the "Run Script" command of the TextMate 2 editor's Python bundle. TM2's Python "Run Script" is designed to work with either Python 2 or 2 interpreters. To do things like capture script stdout and stderr, the bundle launches a Python interpreter while prepending a directory with a custom sitecustomize module to sys.path. The TM2 sitecustomize then removes its directory from sys.path and uses reload to attempt to import any existing sitecustomize module. It then proceeds to do its TM2 customizations. In simplified pseudo-code: # TM_DIRECTORY/sitecustomize.py import sys # remove this copy of sitecustomize from import path if "TM_DIRECTORY" in sys.path: sys.path.remove("TM_DIRECTORY") try: import sitecustomize # get module reference if sys.version_info[0] >= 3: from imp import reload reload(sitecustomize) # try to import another # using altered path except ImportError: pass # no other sitecustomize found # do TM2 customizations here # ... this seems to work just fine with Python 2.7. With Python 3.3 the reload causes the originally imported sitecustomize to be used again, regardless of whether another sitecustomize exists on sys.path. For Python 3.4, 1d67eb1df5a9 for Issue19851 changed reloading. Now for 3.4 (and default), if another sitecustomize exists on sys.path, the behavior is as expected as in 2.7: the other sitecustomize is imported by reload and executes. However, if there is no other sitecustomize, 3.4/default now gets an AttributeError exception in reload, rather than the expected ImportError. Enabling PYTHONVERBOSE shows: File "./lib/python3.5/importlib/__init__.py", line 148, in reload _bootstrap._exec(spec, module) File "", line 1083, in _exec AttributeError: 'NoneType' object has no attribute 'name' And this is due to the call in reload() to _bootstrap._find_spec() returning None (Lib/importlib/__init__.py:147), presumably since there no longer is a sitecustomize. It looks like the following patch fixes the problem for this case: diff --git a/Lib/importlib/__init__.py b/Lib/importlib/__init__.py --- a/Lib/importlib/__init__.py +++ b/Lib/importlib/__init__.py @@ -145,6 +145,9 @@ pkgpath = None target = module spec = module.__spec__ = _bootstrap._find_spec(name, pkgpath, target) + if not spec: + msg = "module {} cannot be reloaded" + raise ImportError(msg.format(name), name=name) _bootstrap._exec(spec, module) # The module may have replaced itself in sys.modules! return sys.modules[name] I'm not sure if this is a correct or sufficient change in the general case. http://stackoverflow.com/questions/23962319/error-output-in-textmate-2-using-python-3-4 ---------- files: test_sitecustomize.sh messages: 219436 nosy: brett.cannon, eric.snow, ned.deily priority: normal severity: normal status: open title: importlib reload can fail with AttributeError if module removed from sys.path versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35416/test_sitecustomize.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 04:53:09 2014 From: report at bugs.python.org (Tim Peters) Date: Sat, 31 May 2014 02:53:09 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1401504789.72.0.713917805361.issue21592@psf.upfronthosting.co.za> Tim Peters added the comment: I suggest this needs a measurable goal, like "minimize expected-case time" or "minimize worst-case time". "Use a state of the art implementation" isn't a measurable goal - it's an abstract wish with no measurable merit on its own ;-) Note that I wrote the "median-of-k" code referenced in the first post here (it was in reply to David Eppstein). Even then it was hard to beat sort() + index. It's harder now, and for an important reason: Python's _current_ sort can exploit many kinds of partial order, and can often complete in linear time. This makes picking "typical" input for timing crucial. If you want to skew it to put sort() + index at maximum disadvantage, use only shuffled (random order) pairwise-unequal inputs. But most streams of data do have some kinds of partial order (which is why the newer sort() implementation has been so successful), and "typical" is a much tougher thing to capture than "shuffled". ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 05:02:57 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 31 May 2014 03:02:57 +0000 Subject: [issue21569] PEP 466: Python 2.7 What's New preamble changes In-Reply-To: <1400927192.68.0.366242673147.issue21569@psf.upfronthosting.co.za> Message-ID: <1401505377.81.0.807003030808.issue21569@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- keywords: +patch Added file: http://bugs.python.org/file35417/py27_whats_new_preamble_changes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 06:00:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 31 May 2014 04:00:56 +0000 Subject: [issue21573] Clean up turtle.py code formatting In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> Message-ID: <1401508856.28.0.554243595029.issue21573@psf.upfronthosting.co.za> Terry J. Reedy added the comment: When I re-read the top of the file, I remembered that turtle.py has unique issues in relation to code ownership. (I was once told that Gregor had to approve any substantive code change.) I asked about that and about code cleanups on pydev (thread 'updating turtle.py'). Re your message: I was suggesting 'mapping' the code, not re-structuring it. Testing: A complete 'unit' test would test each function in each layer. A minimal 'unit' test should at least test each top-level function and check response on the canvas. Assuming that one can get to tk root and canvas, some things should be possible. But I don't know what introspection functions a canvas has. An alternative would be to replace the canvas with a mock-canvas with extra introspection added. Another alternative would be a human-verified test, a turtle script that systematically called every function and said that it was doing for a person to verify. "Line width: 1, 2, 3, 5, 8, 12 17, 30" (with a slight pause for each width). Versions: at most 2.7, 3.4, 3.5. The 3.4 and 3.5 turtle code should be close to identical. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 06:04:13 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sat, 31 May 2014 04:04:13 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401509053.59.0.450483811228.issue21476@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Thank you, Serhiy, for the review! Here is the updated patch. ---------- Added file: http://bugs.python.org/file35418/bytes_parser_dont_close_file_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 06:05:54 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sat, 31 May 2014 04:05:54 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1401509154.28.0.00968801862213.issue19145@psf.upfronthosting.co.za> Changes by Vajrasky Kok : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 06:24:41 2014 From: report at bugs.python.org (Steven Stewart-Gallus) Date: Sat, 31 May 2014 04:24:41 +0000 Subject: [issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit Message-ID: <1401510281.2.0.0561893965896.issue21618@psf.upfronthosting.co.za> New submission from Steven Stewart-Gallus: The sysconf(_SC_OPEN_MAX) approach to closing fds is kind of flawed. It is kind of hacky and slow (see http://bugs.python.org/issue1663329). Moreover, this approach is incorrect as fds can be inherited from previous processes that have had higher resource limits. This is especially important because this is a possible security problem. I would recommend using the closefrom system call on BSDs or the /dev/fd directory on BSDs and /proc/self/fd on Linux (remember not to close fds as you read directory entries from the fd directory as that gives weird results because you're concurrently reading and modifying the entries in the directory at the same time). A C program that illustrates the problem of inheriting fds past lowered resource limits is shown below. #include #include #include #include #include #include int main() { struct rlimit const limit = { .rlim_cur = 0, .rlim_max = 0 }; if (-1 == setrlimit(RLIMIT_NOFILE, &limit)) { fprintf(stderr, "error: %s\n", strerror(errno)); exit(EXIT_FAILURE); } puts("Printing to standard output even though the resource limit is lowered past standard output's number!"); return EXIT_SUCCESS; } ---------- messages: 219440 nosy: sstewartgallus priority: normal severity: normal status: open title: POpen does not close fds when fds have been inherited from a process with a higher resource limit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 06:25:06 2014 From: report at bugs.python.org (Steven Stewart-Gallus) Date: Sat, 31 May 2014 04:25:06 +0000 Subject: [issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit In-Reply-To: <1401510281.2.0.0561893965896.issue21618@psf.upfronthosting.co.za> Message-ID: <1401510306.28.0.621519644079.issue21618@psf.upfronthosting.co.za> Changes by Steven Stewart-Gallus : ---------- type: -> security versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 06:51:53 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 31 May 2014 04:51:53 +0000 Subject: [issue21541] Provide configure option --with-ssl for compilation with custom openssl In-Reply-To: <1400593614.19.0.224440922912.issue21541@psf.upfronthosting.co.za> Message-ID: <1401511913.37.0.570496919614.issue21541@psf.upfronthosting.co.za> Ned Deily added the comment: "Isn't Modules/Setup used for builtin modules?" One of the better kept secrets of Python is that Modules/Setup can be used for building shared modules as well. I didn't know that until looking into it recently as a result of RDM's comment. See Issue17095. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 07:06:37 2014 From: report at bugs.python.org (Steven Stewart-Gallus) Date: Sat, 31 May 2014 05:06:37 +0000 Subject: [issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit In-Reply-To: <1401510281.2.0.0561893965896.issue21618@psf.upfronthosting.co.za> Message-ID: <1401512797.48.0.725222589998.issue21618@psf.upfronthosting.co.za> Steven Stewart-Gallus added the comment: Okay here's a stub patch that address FreeBSD, NetBSD and Linux. I'm not sure how to address the other platforms. ---------- keywords: +patch Added file: http://bugs.python.org/file35419/python.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 07:20:46 2014 From: report at bugs.python.org (Steven Stewart-Gallus) Date: Sat, 31 May 2014 05:20:46 +0000 Subject: [issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit In-Reply-To: <1401510281.2.0.0561893965896.issue21618@psf.upfronthosting.co.za> Message-ID: <1401513646.53.0.596359983402.issue21618@psf.upfronthosting.co.za> Steven Stewart-Gallus added the comment: Oh right! I forgot a possible problem with my proposed patch. It is incompatible with Valgrind (see issue https://bugs.kde.org/show_bug.cgi?id=331311). Either this patch won't be applied, Valgrind compatibility is judged not essential or the Valgrind developers will start emulating /proc/self/fd. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 07:34:28 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 31 May 2014 05:34:28 +0000 Subject: [issue21613] Installer for mac doesn't store the installation location In-Reply-To: <1401461821.06.0.907126667727.issue21613@psf.upfronthosting.co.za> Message-ID: <1401514468.42.0.560328976539.issue21613@psf.upfronthosting.co.za> Ned Deily added the comment: Files are recorded during bundle-style installation, too. Without spending a lot of time looking at it right now, I believe the null location reported is a red herring; I think that has to do with packages that allow themselves to be installed in arbitrary locations. The Python installer packages do not allow that. That said, the paths reported by the --files options could be more accurate. I'll see what I can do as part of the conversion to producing flat packages. There are other issues, though. There are files created by the packages' postflight scripts. In particular, the many .pyc and .pyo files are created by compileall during post-installation so these files are not recorded as installed. Thus, you cannot currently depend on the results of --files to uninstall all files. Automated uninstalls have never been supported; it would be nice to do. ---------- assignee: ronaldoussoren -> ned.deily priority: normal -> low versions: +Python 3.5 -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 07:53:16 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 31 May 2014 05:53:16 +0000 Subject: [issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit In-Reply-To: <1401510281.2.0.0561893965896.issue21618@psf.upfronthosting.co.za> Message-ID: <1401515596.12.0.515176977311.issue21618@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +gps, larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 08:48:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 May 2014 06:48:17 +0000 Subject: [issue21572] Use generic license web page rather than requiring release-specific license pages In-Reply-To: <1400972536.12.0.296163327906.issue21572@psf.upfronthosting.co.za> Message-ID: <3ggYBP52bHz7Ljl@mail.python.org> Roundup Robot added the comment: New changeset 605349858156 by Ned Deily in branch '2.7': Issue #21572: Change license command to fallback to generic license URL. http://hg.python.org/cpython/rev/605349858156 New changeset 53fa2c9523d4 by Ned Deily in branch '3.4': Issue #21572: Change license command to fallback to generic license URL. http://hg.python.org/cpython/rev/53fa2c9523d4 New changeset 075c7affc05c by Ned Deily in branch 'default': Issue #21572: Change license command to fallback to generic license URL. http://hg.python.org/cpython/rev/075c7affc05c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 08:52:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 May 2014 06:52:42 +0000 Subject: [issue21572] Use generic license web page rather than requiring release-specific license pages In-Reply-To: <1400972536.12.0.296163327906.issue21572@psf.upfronthosting.co.za> Message-ID: <3ggYHY6lW0z7bkv@mail.python.org> Roundup Robot added the comment: New changeset 151ac5aee7e7 by Ned Deily in branch 'default': Issue #21572: No longer need to create release-specific license page. http://hg.python.org/peps/rev/151ac5aee7e7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 08:53:55 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 31 May 2014 06:53:55 +0000 Subject: [issue21572] Use generic license web page rather than requiring release-specific license pages In-Reply-To: <1400972536.12.0.296163327906.issue21572@psf.upfronthosting.co.za> Message-ID: <1401519235.31.0.592113521784.issue21572@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 09:20:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 May 2014 07:20:03 +0000 Subject: [issue21583] use support.captured_stderr context manager - test_logging In-Reply-To: <1401125710.75.0.955154923721.issue21583@psf.upfronthosting.co.za> Message-ID: <3ggYv40wnbz7bFF@mail.python.org> Roundup Robot added the comment: New changeset f1393e826608 by Vinay Sajip in branch 'default': Closes #21583: Improved test_logging. Thanks to Diana Joan Clarke for the patch. http://hg.python.org/cpython/rev/f1393e826608 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 11:15:27 2014 From: report at bugs.python.org (Thomas Dybdahl Ahle) Date: Sat, 31 May 2014 09:15:27 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1401527727.26.0.430936232383.issue21592@psf.upfronthosting.co.za> Thomas Dybdahl Ahle added the comment: I think "minimize expected-case time" is a good goal. If we wanted "minimize worst-case time" we would have to use k-means rather than quickselect. My trials on random data, where sort arguably has a disadvantage, suggests sorting is about twice as fast for most input sizes. With pypy quick-select is easily 5-10 times faster, which I take as a suggestion that a C-implementation might be worth a try. For designing a realistic test-suite, I suppose we need to look at what tasks medians are commonly used for. I'm thinking median filters from image processing, medians clustering, robust regressing, anything else? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 14:16:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 May 2014 12:16:24 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401538584.85.0.984007959868.issue21476@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please add a test with parse() raising an exception? Yet one nitpick. Instead of fp = openfile('msg_02.txt', 'rb') self.addCleanup(fp.close) ... you can write with openfile('msg_02.txt', 'rb') as fp: ... as in other tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 14:57:05 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 May 2014 12:57:05 +0000 Subject: [issue21619] Cleaning up a subprocess with a broken pipe Message-ID: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za> New submission from Martin Panter: The documentation for the ?subprocess? module says that a ?with? statement will ?wait for? the process, implying that it does not leave a zombie. However this is not the case if there is buffered input data: $ python3 -Wall -bt -q >>> import subprocess >>> with subprocess.Popen(("true",), stdin=subprocess.PIPE, bufsize=-1) as p: ... from time import sleep; sleep(1) # Wait for pipe to be broken ... p.stdin.write(b"buffered data") ... 13 Traceback (most recent call last): File "", line 3, in File "/usr/lib/python3.4/subprocess.py", line 899, in __exit__ self.stdin.close() BrokenPipeError: [Errno 32] Broken pipe >>> # (Hit Ctrl-Z here) [1]+ Stopped python3 -Wall -bt -q [Exit 148] $ ps PID TTY TIME CMD 15867 pts/5 00:00:00 python3 15869 pts/5 00:00:00 true 15873 pts/5 00:00:00 ps 32227 pts/5 00:00:10 bash Similarly, calling Popen.communicate() does not clean the process up either if there is buffered input data and the process has already exited. The documentation does not spell out how a broken pipe is handled in communicate(), but after reading Issue 10963 I see that in many other cases it is meant to be ignored. The best way to clean up a subprocess that I have come up with to close the pipe(s) and call wait() in two separate steps, such as: try: proc.stdin.close() except BrokenPipeError: pass proc.wait() ---------- components: Library (Lib) messages: 219450 nosy: vadmium priority: normal severity: normal status: open title: Cleaning up a subprocess with a broken pipe versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 17:14:57 2014 From: report at bugs.python.org (Donald Stufft) Date: Sat, 31 May 2014 15:14:57 +0000 Subject: [issue21306] PEP 466: backport hmac.compare_digest In-Reply-To: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za> Message-ID: <1401549297.56.0.158750757671.issue21306@psf.upfronthosting.co.za> Donald Stufft added the comment: That's also a security sensitive thing, you don't want to compare two different encoding and have it accidentally fail. Strictly speaking you can only do a constant time comparison on bytes, the fact it accepts unicode at all (even on Python 3.x) is a convenience feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 17:37:30 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sat, 31 May 2014 15:37:30 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401550650.15.0.485727025584.issue21476@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Serhiy, here is the latest patch incorporating your request. ---------- Added file: http://bugs.python.org/file35420/bytes_parser_dont_close_file_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 17:45:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 May 2014 15:45:36 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401551136.49.0.102206722449.issue21476@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, I meant to test parser with invalid message, so that parse() raises an exception, and file shouldn't be closed after this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 17:51:13 2014 From: report at bugs.python.org (Matthew Lauria) Date: Sat, 31 May 2014 15:51:13 +0000 Subject: [issue21620] OrderedDict KeysView set operations not supported Message-ID: <1401551472.98.0.0437808757217.issue21620@psf.upfronthosting.co.za> New submission from Matthew Lauria: I noticed that doing set operations on an OrderedDict KeysView only works when the KeysView is the first input to the expression, and not when it's the second input. This is not the case for dicts. Python 3.4.1 (default, May 31 2014, 11:25:02) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import collections >>> x = collections.OrderedDict() >>> x.keys() - set() set() >>> set() - x.keys() Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for -: 'set' and 'KeysView' >>> y = {} >>> y.keys() - set() set() >>> set() - y.keys() set() ---------- components: Library (Lib) messages: 219454 nosy: Matthew.Lauria, rhettinger priority: normal severity: normal status: open title: OrderedDict KeysView set operations not supported type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:00:29 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 31 May 2014 16:00:29 +0000 Subject: [issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit In-Reply-To: <1401510281.2.0.0561893965896.issue21618@psf.upfronthosting.co.za> Message-ID: <1401552029.44.0.018899591112.issue21618@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Are you aware that the subprocess module does use /proc/self/fd in Python 3.2 and later? The fd closing is not done from Python code. See Modules/_posixsubprocess.c - http://hg.python.org/cpython/file/53fa2c9523d4/Modules/_posixsubprocess.c ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:04:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 May 2014 16:04:05 +0000 Subject: [issue21620] OrderedDict KeysView set operations not supported In-Reply-To: <1401551472.98.0.0437808757217.issue21620@psf.upfronthosting.co.za> Message-ID: <1401552245.63.0.0525493034013.issue21620@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Already fixed in issue8743. ---------- nosy: +serhiy.storchaka resolution: -> out of date status: open -> closed superseder: -> set() operators don't work with collections.Set instances _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:08:39 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 31 May 2014 16:08:39 +0000 Subject: [issue21573] Clean up turtle.py code formatting In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> Message-ID: <1401552519.58.0.481078749847.issue21573@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:14:31 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 31 May 2014 16:14:31 +0000 Subject: [issue21582] use support.captured_stdx context managers - test_asyncore In-Reply-To: <1401116386.06.0.283011419126.issue21582@psf.upfronthosting.co.za> Message-ID: <1401552871.38.0.990905619147.issue21582@psf.upfronthosting.co.za> Ezio Melotti added the comment: The patch includes two sets of changes: 1) uses support.captured_stderr() where appropriate; 2) removes some "from" import and uses support.x instead; The former looks OK to me and could be applied, the latter doesn't look very useful. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:18:20 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 31 May 2014 16:18:20 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1401553100.75.0.46206349129.issue21592@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I have written some proof of concept code here [1], I would appreciate > you commenting on it, before I turn it into a patch, as I haven't > contributed code to Python before. I would encourage you to consult the devguide, prepare a patch, and upload it here so that we can use rietveld to review it and add inline comments. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:21:29 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 31 May 2014 16:21:29 +0000 Subject: [issue21604] Misleading 2to3 fixer name in documentation: standard_error In-Reply-To: <1401352868.06.0.396054178232.issue21604@psf.upfronthosting.co.za> Message-ID: <1401553289.33.0.879911523541.issue21604@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +jesstess stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:23:47 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 31 May 2014 16:23:47 +0000 Subject: [issue21611] int() docstring - unclear what number is In-Reply-To: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za> Message-ID: <1401553427.38.0.327899672919.issue21611@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, zach.ware type: -> enhancement versions: -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:25:32 2014 From: report at bugs.python.org (diana) Date: Sat, 31 May 2014 16:25:32 +0000 Subject: [issue21582] use support.captured_stdx context managers - test_asyncore In-Reply-To: <1401116386.06.0.283011419126.issue21582@psf.upfronthosting.co.za> Message-ID: <1401553532.73.0.707642115828.issue21582@psf.upfronthosting.co.za> diana added the comment: I removed some of the "from" imports and used support.x instead for consistency. "support" was already being imported, and many of the things imported from "support" were already using support.x. I just made them all the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:33:02 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 31 May 2014 16:33:02 +0000 Subject: [issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit In-Reply-To: <1401510281.2.0.0561893965896.issue21618@psf.upfronthosting.co.za> Message-ID: <1401553982.94.0.650998897453.issue21618@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: -gps _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:44:38 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 31 May 2014 16:44:38 +0000 Subject: [issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit In-Reply-To: <1401510281.2.0.0561893965896.issue21618@psf.upfronthosting.co.za> Message-ID: <1401554678.53.0.461309269948.issue21618@psf.upfronthosting.co.za> Gregory P. Smith added the comment: regardless, the current C code for this does limit itself to the sysconf(_SC_OPEN_MAX) max_fd from module import time when closing fds found in /proc/self/fd so this code does still have a bug in that fds higher than that will remain unclosed (at which point your valgrind issue would come into play unless we can detect we are running under valgrind and alter our behavior to obey the max in that case). ---------- assignee: -> gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:50:26 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sat, 31 May 2014 16:50:26 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401555026.67.0.493104497867.issue21476@psf.upfronthosting.co.za> Vajrasky Kok added the comment: The Parse class does not throw exception if given invalid message: Assume /tmp/a.txt contains garbage, such as: "&&&&&" With this code: with open("/tmp/a.txt", "r") as fp: msg = email.parser.Parser().parse(fp) # does not throw exception print(msg) # => &&&&& msg['from'] # => None It is just you can not get useful information, such as msg['to']. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 18:58:51 2014 From: report at bugs.python.org (Jessica McKellar) Date: Sat, 31 May 2014 16:58:51 +0000 Subject: [issue21573] Clean up turtle.py code formatting In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> Message-ID: <1401555531.14.0.686522229444.issue21573@psf.upfronthosting.co.za> Jessica McKellar added the comment: Terry, thank you for all the time you've been putting into the GSoC and OPW tickets. > Questions: is there project link? are any of the mentors core developers, with commit rights? or would you need commits from someone like me? https://wiki.python.org/moin/OPW/2014#Graphical_Python is a broad-strokes outline. As we get further into the internship we'll decide on areas of focus. I'm the main mentor. I don't have commit rights but would be reviewing most of the changes before putting them in the commit review stage. > I looked for and did not fine test/test_turtle. Did I miss something? Turtledemo is a partial substitute, but it might not exercise all turtle functions. You didn't miss anything. :) Part of this internship will be adding unit test coverage. @Lita: I'll take care of creating unit test tickets that split up the work between you and Ingrid. > Testing: A complete 'unit' test would test each function in each layer. A minimal 'unit' test should at least test each top-level function and check response on the canvas. Assuming that one can get to tk root and canvas, some things should be possible. But I don't know what introspection functions a canvas has. An alternative would be to replace the canvas with a mock-canvas with extra introspection added. Another alternative would be a human-verified test, a turtle script that systematically called every function and said that it was doing for a person to verify. "Line width: 1, 2, 3, 5, 8, 12 17, 30" (with a slight pause for each width). Ingrid Cheung (added to the nosy list) is working on unit test scaffolding, inspired by the tkinter tests. I want to make sure there's a clear course of action for Lita on this ticket. If cleanup is controversial, how about rescoping this to points (3) and (4) from the original ticket statement: > 3. Examine commented out code, and either remove it or open a ticket if it represents an issue that should be fixed. > 4. Examine # XXX comments, and either remove them if they are no longer applicable, or open tickets for them if they still represent bugs and then remove them. @Terry, what do you think about that? @Lita, your pep8 and linter work has not been in vain. :) It'll come in handy local to where you fix bugs and add features down the road. ---------- nosy: +ingrid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 20:01:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 May 2014 18:01:48 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <3ggr7Z45J4z7f6c@mail.python.org> Roundup Robot added the comment: New changeset e90024db8d6c by Benjamin Peterson in branch '2.7': openssl requires nasm (#21462) http://hg.python.org/cpython/rev/e90024db8d6c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 20:11:59 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 31 May 2014 18:11:59 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1401479679.39.0.979362365316.issue21462@psf.upfronthosting.co.za> Message-ID: <1401559913.7630.123671693.4DC070F0@webmail.messagingengine.com> Benjamin Peterson added the comment: On Fri, May 30, 2014, at 12:54, Zachary Ware wrote: > > Zachary Ware added the comment: > > Looks like the AMD64 buildbot isn't happy with OpenSSL 1.0.1g: > http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7/builds/1223/steps/compile/logs/stdio > > Here's my best stab-in-the-dark guess at fixing what's wrong; I don't > have the ability to build x64 2.7 handy. Good call. That seems to have satisfied the AMD64 bot (at least in the compile stage). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 20:24:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 May 2014 18:24:33 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <3ggrdr3kp3z7LkH@mail.python.org> Roundup Robot added the comment: New changeset 7095a9bfbe76 by Steve Dower in branch '2.7': Issue #21462 PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds http://hg.python.org/cpython/rev/7095a9bfbe76 New changeset 8e2cda42b466 by Benjamin Peterson in branch '2.7': openssl requires nasm (#21462) http://hg.python.org/cpython/rev/8e2cda42b466 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 20:30:35 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 31 May 2014 18:30:35 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1401561035.84.0.675072869577.issue21462@psf.upfronthosting.co.za> Nick Coghlan added the comment: Will this be in 2.7.7? If so, I'll update the draft What's New changes in issue #21569 accordingly (as well as the implementation status in PEP 466) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 20:31:16 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 31 May 2014 18:31:16 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1401561035.84.0.675072869577.issue21462@psf.upfronthosting.co.za> Message-ID: <1401561074.10418.123675205.2FAA3623@webmail.messagingengine.com> Benjamin Peterson added the comment: Yes. On Sat, May 31, 2014, at 11:30, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > Will this be in 2.7.7? If so, I'll update the draft What's New changes in > issue #21569 accordingly (as well as the implementation status in PEP > 466) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 20:31:39 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 31 May 2014 18:31:39 +0000 Subject: [issue21462] PEP 466: upgrade OpenSSL in the Python 2.7 Windows builds In-Reply-To: <1399637527.05.0.377700852236.issue21462@psf.upfronthosting.co.za> Message-ID: <1401561099.48.0.461434116076.issue21462@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 20:42:36 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 31 May 2014 18:42:36 +0000 Subject: [issue21539] pathlib's Path.mkdir() should allow for "mkdir -p" functionality In-Reply-To: <1400558036.91.0.766972225791.issue21539@psf.upfronthosting.co.za> Message-ID: <1401561756.66.0.0585643862107.issue21539@psf.upfronthosting.co.za> Berker Peksag added the comment: Updated patch. Thank you Barry and Antoine. ---------- stage: -> patch review Added file: http://bugs.python.org/file35421/issue21539_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 21:08:17 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 31 May 2014 19:08:17 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401563297.52.0.505044944303.issue21476@psf.upfronthosting.co.za> R. David Murray added the comment: Right, part of the parser contract is to not throw exceptions. Traditionally, a bug could result in an exception, but not an invalid message. However, using the new email policies, it is possible to *request* that it raise exceptions instead of registering defects. See policy.raise_on_defect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 21:15:46 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 31 May 2014 19:15:46 +0000 Subject: [issue21569] PEP 466: Python 2.7 What's New preamble changes In-Reply-To: <1400927192.68.0.366242673147.issue21569@psf.upfronthosting.co.za> Message-ID: <1401563746.81.0.210072036288.issue21569@psf.upfronthosting.co.za> Nick Coghlan added the comment: New patch, with the new section moved to the end of the file, just before the acknowledgements. It now has subsections for each relevant PEP, as Ezio's comments made me realise that PEP 434 (the IDLE consistency PEP) also deserved a mention. I'm happy with this version, so unless someone spots a glaring error in the next few days, I'll push it live. ---------- Added file: http://bugs.python.org/file35422/py27_whats_new_preamble_changes_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 21:15:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 May 2014 19:15:46 +0000 Subject: [issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse In-Reply-To: <1399863485.87.0.621460999738.issue21476@psf.upfronthosting.co.za> Message-ID: <1401563746.86.0.421096989887.issue21476@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If the parser itself doesn't raise exceptions, we should test with input stream raising an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 22:03:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 31 May 2014 20:03:08 +0000 Subject: [issue21621] Add note to 3.x What's New re Idle changes in bugfix releases Message-ID: <1401566588.31.0.436459410689.issue21621@psf.upfronthosting.co.za> New submission from Terry J. Reedy: In #21569, revising What's New for 2.7, Nick is planning to add the following: +PEP 434: IDLE Enhancement Exception for All Branches +---------------------------------------------------- + +:pep:`434` describes a general exemption for changes made to the IDLE +development environment shipped along with Python. This exemption makes it +possible for the IDLE developers to provide a more consistent user +experience across all supported versions of Python 2 and 3. + +For details of any IDLE changes, refer to the NEWS file for the specific +release. I think the same should be added to What's New 3.4+ so Idle users are warned and informed that there might be otherwise unexpected changes. At minimum, the last phrase should be changed to "refer to the successive Idle sections of the changelog", where changelog' is linked as it is at the top of the file. I am not sure where to put this. The 3.4 What's New has no Idle section. I did not think to write one :-(. Of course, there was almost nothing new since the previous 3.3.x bugfix release. I guess such a section should be a cumulative summary what was added since the previous x.y.0 release, even if all went into one of the bugfix releases, including the pending final maintenance release. ---------- assignee: terry.reedy components: Documentation messages: 219472 nosy: ncoghlan, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Add note to 3.x What's New re Idle changes in bugfix releases type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 22:06:21 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 31 May 2014 20:06:21 +0000 Subject: [issue21569] PEP 466: Python 2.7 What's New preamble changes In-Reply-To: <1400927192.68.0.366242673147.issue21569@psf.upfronthosting.co.za> Message-ID: <1401566781.63.0.0338755404521.issue21569@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think the Idle section is such a great idea I propose to add something similar to future What's New for 3.x. See #21621. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 22:17:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 May 2014 20:17:23 +0000 Subject: [issue21604] Misleading 2to3 fixer name in documentation: standard_error In-Reply-To: <1401352868.06.0.396054178232.issue21604@psf.upfronthosting.co.za> Message-ID: <3ggv802TD0z7LkH@mail.python.org> Roundup Robot added the comment: New changeset 8fa8c290c165 by Benjamin Peterson in branch '2.7': give the correct fixer name (closes #21604) http://hg.python.org/cpython/rev/8fa8c290c165 New changeset 5d21491733d8 by Benjamin Peterson in branch '3.4': give the correct fixer name (closes #21604) http://hg.python.org/cpython/rev/5d21491733d8 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 22:26:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 May 2014 20:26:54 +0000 Subject: [issue21304] PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 In-Reply-To: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za> Message-ID: <3ggvLx73VRz7Ll4@mail.python.org> Roundup Robot added the comment: New changeset e4da3ba9dcac by Benjamin Peterson in branch '2.7': backport hashlib.pbkdf2_hmac per PEP 466 (closes #21304) http://hg.python.org/cpython/rev/e4da3ba9dcac ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 31 23:42:41 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 31 May 2014 21:42:41 +0000 Subject: [issue21573] Clean up turtle.py code formatting In-Reply-To: <1400982505.0.0.749326101789.issue21573@psf.upfronthosting.co.za> Message-ID: <1401572561.53.0.999543160467.issue21573@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I like the proposal and would like to see it happen. My concern is to avoid having interns write patches that get rejected for non-technical reasons. I won't make any specific suggestions until I get more information either from the pydev thread http://thread.gmane.org/gmane.comp.python.devel/147857 or from Gregor. I already emailed him directly, asking him to sign a contributor agreement and settle the matter of turtle maintenance. Lita, please post a summary of the types of issues you have found (at most, say, 20). Some things are no-brainers, like adding missing spaces, as in 'a=3' to 'a = 3' or 'f (a,b = 3)' to 'f(a, b=3)', which also removes extra spaces. Rietveld's within-lines diffs make these easy to check. Other fixes are riskier. ---------- _______________________________________ Python tracker _______________________________________